bug5863bis.txt
[YANGIDE-10] java.lang.ClassNotFoundException: org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor$YangProvider at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) Created: 09/May/16 Updated: 19/Oct/17 |
|
| Status: | Confirmed |
| Project: | yangide |
| Component/s: | General |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Michael Vorburger | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Attachments: |
bug5863bis.txt
|
| External issue ID: | 5863 |
| Description |
| Comments |
| Comment by David M. Karr [ 09/May/16 ] |
|
I don't know if I've seen this exact error, but it's certainly similar to other issues I've seen before. I note that these samples are using Beryllium artifacts. I had a lot of trouble finding the "version dependency matrix" just for the three related artifacts used in these Yang projects. |
| Comment by Michael Vorburger [ 10/May/16 ] |
|
Hm, now I cannot reproduce the problem above anymore.. could have just been due to a stale local workspace, and recent automatic rebuild made things consistent again, so gone?! I'm closing this as RESOLVED WORKSFORME; let's re-open if anyone bunmps into above again. > I note that these samples are using Beryllium artifacts. I've cleaned them up in proposed new change https://git.opendaylight.org/gerrit/38628 - merge? |
| Comment by Michael Vorburger [ 10/May/16 ] |
|
Ha, that didn't take long, I've just hit it again, not identical, but similar enough, I'm reasonably sure that this is the same root cause as initial above, see attachment. |
| Comment by Michael Vorburger [ 10/May/16 ] |
|
Attachment bug5863bis.txt has been added with description: NoClassDefFoundError from Eclipse Error Log |
| Comment by Michael Vorburger [ 10/May/16 ] |
|
This time I had a closer look, and it's of course not a trivial typo or something (how could it be in Java..) - a quick verification of the NoClassDefFoundError class org/opendaylight/yangtools/yang/parser/stmt/reactor/ModifierImpl shows that IS of course in one of the JARs listed: jar -tf /home/vorburger/.m2/repository/org/opendaylight/yangtools/yang-parser-impl/1.0.0-SNAPSHOT/yang-parser-impl-1.0.0-SNAPSHOT.jar | grep org/opendaylight/yangtools/yang/parser/stmt/reactor/ModifierImpl Curious. I do have one somewhat vague suspicion though, which is more of a hunch than something I "prove" at this stage: The org.opendaylight.yangide.m2e.yang plugin is more than just a "normal" M2E Configurator.. not only does it seem to delegate code generation to yangtools via the Classpath of the yang-maven-plugin (NOT yangide.m2e.yang Eclipse plugin!), as any "normal" M2E Configurator would, but it also seems to do some yang model validation by calling THE SAME kind of yangtools code, but that through it's dependency to yangide.ui & yangide.core (which depends on yangide.yangparser, which bundles copies of the yangtools JARs). To me this seems dangerous, and possibly the root cause of this (only occasionally happening) problem? BTW: I'm assuming a strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy in Maven, which I'm not an expert of, means that it should first load classes from the Classpath of the yang-maven-plugin, and so in theory not get confused, but in practice... looks like this does not (always) work? What to do? a) Make yangide.m2e.yang completely separate from yangide.ui, yangide.core & yangide.yangparser? And run the validation.. from another separate Builder than the M2E one, in yangide.core? |
| Comment by Michael Vorburger [ 11/May/16 ] |
|
Some notes for future digging: 1. NoClassDefFoundError can be because of problem in static, but normally there should be an ExceptionInInitializerError.. so set breakpoint in all 3 constructors of ExceptionInInitializerError to see if any. 2. SelfFirstStrategy.loadClass breakpoint could be interesting to debug the actual ClassLoader(s) it really tried 3. yangtools/mdsal ClassLoaderUtils ClassLoader and Thread setContextClassLoader magic - bug there? |
| Comment by Michael Vorburger [ 11/May/16 ] |
|
> 3. yangtools/mdsal ClassLoaderUtils ClassLoader and Thread setContextClassLoader magic - bug there? Unlikely, seems safe; see analysis in |
| Comment by David M. Karr [ 11/May/16 ] |
|
Have you attempted to change the versions to match what the YangIDE generates in a new project? From what I'm seeing here, this is still using Beryllium. |
| Comment by Michael Vorburger [ 11/May/16 ] |
|
> Have you attempted to change the versions to match what the YangIDE generates in a new project? Yes in https://git.opendaylight.org/gerrit/38628 (see above) I've changed 0.8.0-Beryllium to 1.0.0-SNAPSHOT. See the attached 2nd occurrence of this problem, there are no "0.8.0-Beryllium" there anymore. |
| Comment by David M. Karr [ 11/May/16 ] |
|
So what happens when you use the plugin to create a Yang project? Do you get the same error? |
| Comment by Michael Vorburger [ 11/May/16 ] |
|
> So what happens when you use the plugin to create a Yang project? oh hang on, we were not talking about the same thing, you mean File > New > Project > YANG.. I just discovered that now. I have not changed anything related to that (and it was already at non-Beryllium). Above (x2) is when using yangide on yangide/samples/yang-module1 & module2. > Do you get the same error? This error happens occasionally (twice to me), and I don't have steps to reproduce. The File > New > Project > YANG & yangide/samples/yang-module1 & module2 both look like the have a very similar structure, so I assume it can happen in either. |
| Comment by David M. Karr [ 12/May/16 ] |
|
I have a feeling what we will find is that this error only happens when importing these projects without creating it as a Yang Project. If that's the case, we should prevent this error from happening, but we would do that by ensuring that the Yang editing facilities are not available for Yang files not in a "Yang Project". In addition, we should implement the "Yang Nature", which can be added to an imported project after creation, to get Yang editing facilities without creating a "Yang Project". |