|Russel Winder||Apr 25, 2008 3:15 am|
|Jochen Theodorou||Apr 25, 2008 3:29 am|
|Russel Winder||Apr 26, 2008 12:40 am|
|Paul King||Apr 26, 2008 2:27 am|
|Paul King||Apr 26, 2008 2:47 am|
|Russel Winder||Apr 26, 2008 3:24 am|
|Jochen Theodorou||Apr 26, 2008 4:35 am|
|Russel Winder||Apr 26, 2008 4:46 am|
|Russel Winder||Apr 26, 2008 5:02 am|
|Jochen Theodorou||Apr 26, 2008 5:24 am|
|Paul King||Apr 26, 2008 5:33 pm|
|Jochen Theodorou||Apr 27, 2008 2:10 am|
|Paul King||Apr 27, 2008 4:26 am|
|Russel Winder||Apr 27, 2008 4:30 am|
|Jochen Theodorou||Apr 27, 2008 4:53 am|
|Russel Winder||Apr 27, 2008 5:55 am|
|Jochen Theodorou||Apr 27, 2008 6:24 am|
|Russel Winder||Apr 27, 2008 10:43 am|
|Jochen Theodorou||Apr 27, 2008 12:02 pm|
|Paul King||Apr 27, 2008 4:11 pm|
|Russel Winder||May 1, 2008 2:16 am|
|Jochen Theodorou||May 2, 2008 10:02 am|
|Russel Winder||May 2, 2008 12:07 pm|
|Jochen Theodorou||May 2, 2008 12:51 pm|
|Subject:||Re: [groovy-dev] [Fwd: XML class lookup problem in Gant]|
|From:||Jochen Theodorou (blac...@gmx.org)|
|Date:||Apr 25, 2008 3:29:16 am|
GANT-34 is an example of a java.lang.LinkageError that I have been looking at for a few days and just can't get my head around.
Code that works fine on Ubuntu 7.10, fails on Mac OS X and Solaris 10 with this error. The Mac OS X error message is not very informative:
java.lang.LinkageError: loader constraints violated when linking org/w3c/dom/Node class
Uh.. I hate that one...
the Solaris 10 error message is a little more informative:
java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.apache.xerces.dom.NodeImpl.item(I)Lorg/w3c/dom/Node;" the class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current class, org/apache/xerces/dom/NodeImpl, and the class loader (instance of <bootloader>) for interface org/w3c/dom/NodeList have different Class objects for the type org/w3c/dom/Node used in the signature
nice, I wish messages like these would be the standard.. explaining this error is a bit difficult, because there are different scenarios that can cause this. Now imagine the following scenario.... a class in RootLoader request the loading of a depending class X. This class is not in RootLoader so <bootloader> will do the job. What happens now is that the classloader for X is <bootloader>, but also all classes loaded while loading X will be loaded from <bootloader>... Now the problem is that RootLoader is not doing nothing in this process. Instead RootLoader gets some kiind of entry saying that the classes laoded while loading X are loaded through <bootloader> if now RootLoader tries to load one of these classes itself, then this "table" is checked and it will be seen, that RootLoader is the wrong loader for that class. The result is this LinkageError. Just to say it clearly... that means Node is there two times! And I know one of the xml classes we use has that... if that class wouldn't be there, there would be no problem.
While I not yet know how to "fix" that I see two possible solutions..
1) add to RootLoader what caused the loading of the class through <bootloader>, which would mean you would have to provide alternative XMLParser and use that one instead of using the one from the JDK... which has problems on its own
2) remove the classes that try to load Node from RootLoader and but them in the JVM classpath instead. Or remove Node at last Node from RootLoader
So clearly this is a class lookup problem and there are multiple class loaders involved and rt.jar contains a set of the XML processing classes as do a huge number of other jars in and around the Java world, not least of which is xml-apis.jar.
yes, but xml-apis makes the crucial error of providing an alternative Node class. And if you look at the source you will wonder why this does not cause problems, because the Node class they have is not equal to the one from the JDK. Instead they depend on having their node class loaded before the one from the JDK, and they do depend on having their parser being loaded before the JDK. They even try to recognize the case that the other Node got loaded before their Node and then provide an alternative implementation.... but that does not work with our class loader structure.
And that is as far as I have got -- apart from thinking this is not a Gant problem but a Groovy problem.
One user reported the workaround of putting an additional version of xml-apis.jar into their classpath before running Gant, but this seems like a hack to me. If I could get a handle on the real problem, I can then release Gant 1.2.0 till then I am hesitant.
xml-apis itself is backfiring hack in this case.
--------------------------------------------------------------------- To unsubscribe from this list, please visit: