Jboss 5, classloader and multiple class instances

up vote3down votefavorite 2

I had a problem with my application. To resume the problem, I had to do migrate an application from jboss 4 to jboss 5. During the war deployement, I had this error: java.lang.LinkageError: loader constraint violation: when resolving field "DATETIME" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the referring class, javax/xml/datatype/DatatypeConstants, and the class loader (instance of <bootloader>) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type After many searchs, I found this error was here because I had several time the same class in differents packages. Once in a dependency package (from my pom.xml) and once provided by jboss. So, to resolve this problem, I have give a scope "provided" for my dependency. But I don't understand why this solution works. I thought it works to have several time the same class in an application. I know it's not a good thing, but with jboss 4, it's work. Someone can explain me why it works with jboss 4 and not with jboss 5. Thanks for your explanation :) java jboss dependencies share|improve this question asked Apr 12 '11 at 15:58 Kiva 1,40862449

What is the class that is repeated? What packages is it repeated into? –  Vitalij Zadneprovskij Feb 22 '13 at 16:19 add comment

2 Answers

activeoldestvotes

up vote8down voteaccepted

What you are seeing is the effect of an application server loading JBoss' libraries and EAR libraries in separate classloaders You can think of an EAR's class loader hierarchy similar (but not necessarily) to : Bootstrap ClassLoader -> System Class Loader -> JBoss System Class Loader -> Ear Class Loader -> War Class Loader. Where war class loader's parent is the ear class loader and so forth. Now if Bootstrap ClasssLoader has a jar A loaded and the ear is also being deployed with jar A, Bootstrap Class Lodaer and Ear Class Loader will have the same class created twice in separate class loaders. I would assume (not 100% sure of this) that JBoss 4 didnt come bundled with javax/xml/namespace/QName. If that is true JBoss 5 is more then likely a different, upgraded, version of Java (4 -> 5 or 5 -> 6). As a result (with the new JBoss 5), when you try to pass javax/xml/namespace/QName into one of your classes, it is expecting the class from the ear. However you are giving it the QName class from the Bootstrap classloader because of the classloader preferences (parent first and so forth). Since the class types are equal but the class instances are not equal you get a LinkageError Edit: Just two address the two comments - The class loading behavior as jtahlborn noted is deffinitely different. In normal applications, the system classes like QName will be consistently looked for in the bootstrap classloader. In your error it looks as if javax/xml/datatype/DatatypeConstants is being loaded in org/jboss/classloader/spi/base/BaseClassLoader. Lets assume thats the EAR classloader (or WAR). A quick google shows that is part of the xml-apis' family and possibly jaxp-api. So somewhere in your code (or another libraries code located in the EAR's class loader) needed DatatypeConstants - which forced the lookup of the class in the EAR's classloader. The creation of the QName object though loaded the class from the bootstrap classloader (instead of the EAR). This would happen if the QName class has already been initialized by the system, which it probably has. This as you can imagine isn't suppose to happen. It actually looks like you have parent-last. Because when loading a class off the JBoss class loading mechanism, had parent-first been enabled, the initial DatatypeConstants would have returned the parent's (bootstrap) DatatypeConstants and not the childs. So as jtahlborn noted you would want the children's classloader here to be ignored. As far as the resolution goes, unless you need the dependencies for a specific reason (like a slightly newer version is better then the current) I would delegate to the jboss's implementation. If thats not the case, you can take a look at the class-loading java2ClassLoadingCompliance element that the jboss configuration has. share|improve this answer edited Apr 12 '11 at 19:37 answered Apr 12 '11 at 16:15 John Vint 17.6k22044

i think this is close, but not entirely correct. generally, war classloaders are setup to prefer loading from the child. otherwise, you would never see a conflict, as the version of the class in the war would be ignored. you are right that the most likely problem is a difference in the java version (i doubt jboss includes the jaxb classes). – jtahlborn Apr 12 '11 at 16:20 What I have learned with upgrading websphere and weblogic to newer versions (which included newer versions of Java) is that the java runtimes included its own javax/xml/namespace/QName and related libraries. This is what I think is the issue with the OP. And yes you are correct default configuration usually is to assume parent-last. –  John Vint Apr 12 '11 at 16:22  you should clarify that the classloading behavior is different in this scenario, as that is what is confusing the OP. in "normal" java applications, duplicate classes included in a child classloader are ignored. –  jtahlborn Apr 12 '11 at 16:27 How do you do to setup the configuration at parent-last ? –  Kiva Apr 12 '11 at 18:14 about your edit. In fact, I had tried the class loader java2ClassLoadingCompliance but with this, I had a new error about logger configuration. And finally, it's better to use the jboss default comportment for my application. Thanks a lot for your very complete explanation :) –  Kiva Apr 12 '11 at 21:49 add comment

up vote1down vote	-verbose:class in VM args will give how the Class is getting loaded. If there is duplicate you can remove the conflicting jar/jars. share|improve this answer edited Oct 5 '12 at 12:16 Sumit Singh 7,42921946 answered Aug 10 '12 at 20:30 Sujith Kasthoori 111
	add comment