问题描述
我的申请有问题。要恢复这个问题，我必须将应用程序从jboss 4迁移到jboss 5.
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
经过多次搜索，我发现了这个错误在这里，因为我有几次在不同的包中相同的类。一旦进入依赖包（来自我的pom.xml）并且一次由jboss提供。
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.
但我不明白为什么这个解决方案有效。我认为在应用程序中有几次同一个类是有效的。我知道这不是一件好事，但是使用jboss 4，它可以工作。
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.
有人可以解释为什么它适用于jboss 4而不适用于jboss 5.
Someone can explain me why it works with jboss 4 and not with jboss 5.
感谢您的解释：）
推荐答案
您所看到的是效果将JBoss库和EAR库加载到单独的类加载器中的应用程序服务器
What you are seeing is the effect of an application server loading JBoss' libraries and EAR libraries in separate classloaders
您可以将EAR的类加载器层次结构视为类似（但不一定）类似于：
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。
Bootstrap ClassLoader -> System Class Loader -> JBoss System Class Loader -> Ear Class Loader -> War Class Loader.
war类加载器的父级是ear类加载器等等。
Where war class loader's parent is the ear class loader and so forth.
现在，如果Bootstrap ClasssLoader加载了jar A，并且还使用jar A部署了ear，Bootstrap Lodaer类和Ear类加载器将在单独的类加载器中创建两次相同的类。
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.
我认为（不是100％肯定这一点）JBoss 4没有与javax / xml / namespace / QName捆绑在一起。如果这是真的，JBoss 5可能更像是一个不同的，升级的Java版本（4 - > 5或5 - > 6）。因此（使用新的JBoss 5），当您尝试将javax / xml / namespace / QName传递到其中一个类时，它会期待该类。但是你要从Bootstrap类加载器给它QName类，因为类加载器首选项（父类首先等等）。
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).
因为类类型相等但类实例并不等于你得到一个LinkageError
Since the class types are equal but the class instances are not equal you get a LinkageError
编辑：
只有两个解决了两个评论 -
Just two address the two comments -
jtahlborn指出的类加载行为是绝对不同的。在普通应用程序中，将在引导程序类加载器中一致地查找像QName这样的系统类。在您的错误中，看起来好像在org / jboss / classloader / spi / base / BaseClassLoader中加载了javax / xml / datatype / DatatypeConstants。让我们假设这是EAR类加载器（或WAR）。一个快速的谷歌节目，是xml-apis'家族的一部分，可能是jaxp-api。
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.
因此，代码中的某个位置（或位于EAR类加载器中的其他库代码）需要DatatypeConstants - 它强制在EAR的类加载器中查找类。虽然从引导类加载器（而不是EAR）加载了类，但是创建了QName对象。如果QName类已经被系统初始化了，那么就会发生这种情况。它可能有。
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.
你可以想象这不会发生。它实际上看起来像你有父母的最后一个。因为在从JBoss类加载机制加载类时，如果已启用parent-first，则初始DatatypeConstants将返回父级（bootstrap）DatatypeConstants而不是childs。因此，jtahlborn指出你会希望忽略这里的孩子的类加载器。
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.
除了分辨率，除非你因特定原因需要依赖（如略更新的版本比当前更好）我会委托jboss的实现。如果不是这种情况，你可以看一下jboss配置所具有的类加载java2ClassLoadingCompliance 元素。
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.
这篇关于Jboss 5，类加载器和多个类实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！