“从 Oracle 10g 上的 webapp 链接 javax/xml/namespace/QName 类时违反了加载程序约束”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/133993/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
"loader constraints violated when linking javax/xml/namespace/QName class" from webapp on Oracle 10g
提问by alexmcchessers
We have a web application that can be deployed on many application servers, including Oracle 10g. On that platform, however, we are having classpath issues. The webapp uses JAXB 2, but Oracle 10g ships with JAXB 1, and this was causing errors. To get around those we configured Oracle to prefer classes in our webapp, but now we are getting the above error when attempting to instantiate a JAXB context.
我们有一个 Web 应用程序，可以部署在许多应用程序服务器上，包括 Oracle 10g。但是，在该平台上，我们遇到了类路径问题。Web 应用程序使用 JAXB 2，但 Oracle 10g 附带 JAXB 1，这会导致错误。为了解决这些问题，我们将 Oracle 配置为更喜欢我们的 web 应用程序中的类，但是现在我们在尝试实例化 JAXB 上下文时遇到了上述错误。
Looking up the "loader constraints violated" exception - it seems to be thrown when a class that has been loaded with one classloader attempts to access something that is package private in the same package but loaded by a different classloader. I have tried removing any jars in our webapp that include javax.xml.namespace.QName, and have verified that it is the instance included in Oracle that is being picked up, but the error still occurs. Any ideas?
查找“违反加载器约束”异常 - 当已使用一个类加载器加载的类尝试访问同一包中的包私有但由不同的类加载器加载的某些内容时，似乎会抛出该异常。我已尝试删除我们的 web 应用程序中包含 javax.xml.namespace.QName 的所有 jar，并已验证它是包含在 Oracle 中的实例正在被拾取，但错误仍然发生。有任何想法吗？
(This is a follow-on from an earlier questionregarding 10g and JAXB 2.)
回答by Alex Miller
This class is in half the WS Java libraries out there. It's really easy to load it from multiple classloaders and later compare them, causing a LinkageError.
这个类占了 WS Java 库的一半。从多个类加载器加载它并稍后比较它们真的很容易，从而导致 LinkageError。
One effective (but sledgehammer) technique to tracking this down is to modify Classloader from the Java source to dump which jar this particular class is loading from at load time, then prepend your bootclasspath with your modified version:
跟踪此问题的一种有效（但大锤）技术是从 Java 源修改 Classloader 以转储此特定类在加载时从哪个 jar 加载，然后在您的引导类路径之前添加修改后的版本：
-Xbootclasspath/p:/path/to/hackedBin
-Xbootclasspath/p:/path/to/hackedBin
回答by Robert Van Hoose
What version of Java are you using? The newest versions ship with this class in the rt.jar.
您使用的是什么版本的 Java？最新版本在 rt.jar 中随附了此类。
回答by Vladimir Dyuzhev
May be it's completely unrelated, but I remember a problem Weblogic had with the very same class. The reason for the problem was the changed serial id of the class (Sun changed it accidentally). The workaround was to provide a -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 to the JVM.
可能完全不相关，但我记得 Weblogic 在同一个类中遇到的一个问题。问题的原因是更改了类的序列号（Sun 不小心更改了它）。解决方法是向 JVM 提供 -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0。
Could it be the same problem, just misreported? Try it.
会不会是同样的问题，只是误报？尝试一下。
See here: http://forums.bea.com/thread.jspa?threadID=600014563
回答by matt b
Can you just update the JAXB jar under the app server's libfolder?
你可以只更新应用服务器lib文件夹下的 JAXB jar吗？
