24 messages in org.codehaus.groovy.devRe: [groovy-dev] [Fwd: XML class look...| From | Sent On | Attachments |
|---|---|---|
| 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: | Paul King (pau...@asert.com.au) | |
| Date: | Apr 26, 2008 2:27:58 am | |
| List: | org.codehaus.groovy.dev | |
What is the simplest way to reproduce?
Paul.
Russel Winder wrote:
Jochen,
On Fri, 2008-04-25 at 12:29 +0200, Jochen Theodorou wrote:
[...]
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...
So do all the users of Gant who see it and have no clue as to what the problem is :-(
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.
So what you are saying is that this is a Groovy problem and not a Gant problem. If so then I will transfer the Gant JIRA issue to Groovy -- actually, better still, I will create a new Groovy issue and point the Gant one to it.
If this is the case, it would be a great relief :-)
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
I'm afraid I am not in a position to help here. All I know is that the XML processing classes seem to be a total mess in the combination of Java/Ant/JUnit/Ivy that Gant has and there seems to be no sane control possible from Gant.
What I need is an immediate workaround so that people who use junitreport or ivy:cachepath (actually any Ivy task) in a Gant script do not get this error. I do not get it at all on Ubuntu, but on Mac OS X, Soalris 10 and Windows it is a pandemic problem which makes Gant unusable. This is therefore not a problem, it is a crisis.
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.
I think xml-apis.jar might be a red herring in this case -- but maybe not. The point is that Ant works fine and Gant gets a java.util.LinkageError when trying to do the self same thing. Gant has no classloader tricks, only MOP usage. I only mentioned xml-apis.jar because someone said that if they copied the Ivy version of this jar into a directory so that it got searched first by java on start-up then the problem went away for their use of Ivy in Gant.
The other data point is that for me on Ubuntu xml-apis.jar is in a standard place /usr/share/java and so is possibly in the standard classpath, whereas on Mac OS X and Solaris Ant has it's private copy, there is not a general shared copy.
So perhaps the issue here is that Gant loads all the Ant jars and does this using the Groovy Rootloader because it is a Groovy program. So on Ubuntu this is the same jar as used by java whereas on Mac OS X and Solaris it is not. If this is the case then the only way of properly removing the problem is to recode all of Gant in Java.
I will try the experiment of excluding xml-apis.jar from being included from the Ant directory, but this cannot be a solution. If Ant believes it can and should use xml-apis.jar then Gant has to be able to function with Ant's copy in the classpath.
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.
Pass, I have no idea. What I do know is that Ant uses it and Gant should use what Ant uses to avoid any conflicts with the Ant tasks.
--------------------------------------------------------------------- To unsubscribe from this list, please visit: