java Jboss 5、类加载器和多个类实例

Jboss 5, classloader and multiple class instances

提问by Kiva

I had a problem with my application. To resume the problem, I had to do migrate an application from jboss 4 to jboss 5.

我的应用程序有问题。为了解决这个问题，我不得不将一个应用程序从 jboss 4 迁移到 jboss 5。

During the war deployement, I had this error:

在War部署期间，我遇到了这个错误：

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.

经过多次搜索，我发现这个错误在这里是因为我在不同的包中多次使用相同的类。一次在依赖包中（来自我的 pom.xml），一次由 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.

但我不明白为什么这个解决方案有效。我认为在一个应用程序中多次使用同一个类是可行的。我知道这不是一件好事，但是对于 jboss 4，它可以工作。

Someone can explain me why it works with jboss 4 and not with jboss 5.

有人可以解释我为什么它适用于 jboss 4 而不适用于 jboss 5。

Thanks for your explanation :)

谢谢你的解释:)

回答by John Vint

What you are seeing is the effect of an application server loading JBoss' libraries and EAR libraries in separate classloaders

您所看到的是应用服务器在单独的类加载器中加载 JBoss 的库和 EAR 库的效果

You can think of an EAR's class loader hierarchy similar (but not necessarily) to :

您可以将 EAR 的类加载器层次结构视为（但不一定）类似于：

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。

Where war class loader's parent is the ear class loader and so forth.

其中war类加载器的父类是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.

现在，如果 Bootstrap ClasssLoader 加载了一个 jar A 并且 Ear 也与 jar A 一起部署，Bootstrap Class Lodaer 和 Ear Class Loader 将在不同的类加载器中创建两次相同的类。

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).

我会假设（不是 100% 肯定）JBoss 4 没有与 javax/xml/namespace/QName 捆绑在一起。如果这是真的，那么 JBoss 5 更可能是一个不同的、升级的 Java 版本（4 -> 5 或 5 -> 6）。结果（在新的 JBoss 5 中），当您尝试将 javax/xml/namespace/QName 传递到您的一个类时，它期望从耳朵中获取该类。但是，由于类加载器首选项（父类优先等），您从 Bootstrap 类加载器中为其提供了 QName 类。

Since the class types are equal but the class instances are not equal you get a LinkageError

由于类类型相等但类实例不相等，因此您会收到 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.

jtahlborn 指出的类加载行为完全不同。在正常的应用程序中，像 QName 这样的系统类将始终在引导类加载器中查找。在您的错误中，似乎 javax/xml/datatype/DatatypeConstants 正在 org/jboss/classloader/spi/base/BaseClassLoader 中加载。让我们假设那是 EAR 类加载器（或 WAR）。一个快速的谷歌显示它是 xml-apis 家族的一部分，可能是 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.

因此，在您的代码（或位于 EAR 的类加载器中的另一个库代码）中的某个地方需要 DatatypeConstants - 这会强制在 EAR 的类加载器中查找该类。QName 对象的创建虽然从引导类加载器（而不是 EAR）加载了类。如果 QName 类已经被系统初始化（它可能已经初始化），就会发生这种情况。

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 类加载机制加载一个类时，如果启用了 parent-first，初始 DatatypeConstants 将返回父级（引导程序）DatatypeConstants 而不是子级。因此，正如 jtahlborn 指出的那样，您希望这里的孩子的类加载器被忽略。

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 java2ClassLoadingComplianceelement that the jboss configuration has.

就解决方案而言，除非您出于特定原因需要依赖项（例如稍新的版本比当前版本更好），否则我会将其委托给 jboss 的实现。如果不是这种情况，您可以查看class-loading java2ClassLoadingCompliancejboss 配置具有的元素。

回答by Sujith Kasthoori

-verbose:classin VM args will give how the Class is getting loaded. If there is duplicate you can remove the conflicting jar/jars.

-verbose:class在 VM args 中将给出类是如何加载的。如果有重复，您可以删除冲突的 jar/jar。

回答by user3425059

Thank you for the explanation - it was very helpful.

感谢您的解释 - 这非常有帮助。

I learned that this issue is related to a JBoss bug which was fixed in a 5.0.0 release. But even though I am running an older version of JBoss, I still got this error. Anyway, I did extensive research and run maven dependency tree a few times to see where the duplicate definitions are coming from. I was finally able to resolve this error by adding two dependencies - with scope set to provided - to my main pom:
(sun.jaxb-impl 2.1 , javax.jaxb-api 2.2 ) I hope this information helps someone.

我了解到这个问题与 5.0.0 版本中修复的 JBoss 错误有关。但是即使我运行的是旧版本的 JBoss，我仍然遇到此错误。无论如何，我进行了广泛的研究并运行了几次 Maven 依赖关系树，以查看重复定义的来源。我终于能够通过向我的主要 pom 添加两个依赖项（范围设置为提供）来解决此错误：
(sun.jaxb-impl 2.1 , javax.jaxb-api 2.2 ) 我希望这些信息对某人有所帮助。