带有两个冲突版本的javax.servlet.servlet-api jar的java.lang.SecurityException [英] java.lang.SecurityException with two conflicting versions of javax.servlet.servlet-api jars
问题描述
我正在努力解决我无法解决的Java / Maven / Jetty问题。
我有一个正确启动的Java Jetty服务器但是一旦向它发送HTTP请求，它就会中止显示这个堆栈跟踪：
I'm struggling with a Java/Maven/Jetty problem that I can't solve. I have a Java Jetty server that starts up correctly but as soon as an HTTP request is sent to it, it aborts showing this stacktrace:
2013-09-30 08:40:24,534 [qtp297240915-11 Selector0] WARN org.eclipse.jetty.io.nio - java.lang.SecurityException: class "javax.servlet.AsyncContext"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:806) ~[na:1.6.0_37]
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487) ~[na:1.6.0_37]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:625) ~[na:1.6.0_37]
at java.lang.ClassLoader.defineClass(ClassLoader.java:615) ~[na:1.6.0_37]
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) ~[na:1.6.0_37]
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) ~[na:1.6.0_37]
at java.net.URLClassLoader.access$000(URLClassLoader.java:58) ~[na:1.6.0_37]
at java.net.URLClassLoader$1.run(URLClassLoader.java:197) ~[na:1.6.0_37]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.6.0_37]
at java.net.URLClassLoader.findClass(URLClassLoader.java:190) ~[na:1.6.0_37]
at java.lang.ClassLoader.loadClass(ClassLoader.java:306) ~[na:1.6.0_37]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) ~[na:1.6.0_37]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_37]
at org.eclipse.jetty.server.AbstractHttpConnection.<init>(AbstractHttpConnection.java:157) ~[jetty-server-8.1.9.v20130131.jar:8.1.9.v20130131]
at org.eclipse.jetty.server.AsyncHttpConnection.<init>(AsyncHttpConnection.java:50) ~[jetty-server-8.1.9.v20130131.jar:8.1.9.v20130131]
at org.eclipse.jetty.server.nio.SelectChannelConnector.newConnection(SelectChannelConnector.java:285) ~[jetty-server-8.1.9.v20130131.jar:8.1.9.v20130131]
at org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager.newConnection(SelectChannelConnector.java:325) ~[jetty-server-8.1.9.v20130131.jar:8.1.9.v20130131]
at org.eclipse.jetty.server.nio.SelectChannelConnector.newEndPoint(SelectChannelConnector.java:272) ~[jetty-server-8.1.9.v20130131.jar:8.1.9.v20130131]
at org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager.newEndPoint(SelectChannelConnector.java:331) ~[jetty-server-8.1.9.v20130131.jar:8.1.9.v20130131]
at org.eclipse.jetty.io.nio.SelectorManager$SelectSet.createEndPoint(SelectorManager.java:836) ~[jetty-io-7.6.5.v20120716.jar:7.6.5.v20120716]
at org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:491) ~[jetty-io-7.6.5.v20120716.jar:7.6.5.v20120716]
at org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:285) [jetty-io-7.6.5.v20120716.jar:7.6.5.v20120716]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) [jetty-util-8.1.3.v20120416.jar:8.1.3.v20120416]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) [jetty-util-8.1.3.v20120416.jar:8.1.3.v20120416]
at java.lang.Thread.run(Thread.java:662) [na:1.6.0_37]
<显然，包含在运行它的罐子里有一些奇怪的东西，在谷歌我可以找到一些参考这个问题，但没有明确的解决方案。
Clearly there is something odd going on within the jars included to run it, and in Google I could find some references to this problem but without a clear solution.
无论如何，最奇怪的是同一个应用程序在另一台机器上运行完美。为了确保两者之间没有差异，我将项目目录（包括编译类，maven依赖项jar，配置文件等）从运行正常的机器复制到另一台运行不正常的机器。错误不断出现。
我还删除了机器的maven本地缓存（〜/ .m2 /），尽管它无关紧要。这两台机器的Java和Maven版本是相同的。
Anyway, the strangest thing is that the same application runs perfectly in another machine. To make sure that there were no differences between the two, I copied the directory of the project (including compiled classes, the maven dependencies jars, configuration files, etc) from the machine where it runs fine to the other where it doesn't. The error keeps showing up. I've also deleted the maven local cache for the machine (~/.m2/), although it shouldn't matter. Java and Maven versions are the same in the two machines.
显然，两者之间必须有一些环境差异，但我不知道我应该在哪里看除了我刚刚提到的方面之外。
Clearly, there has to be some environment difference among the two but I don't know where else I should look for apart from the aspects I've just mentioned.
任何想法？
EDIT ：该项目包括两个相互冲突的javax.servlet.servlet-api版本。从pom中排除旧版本修复了该问题。
无论哪种方式，我仍然有一个谜，为什么在一台机器上，虽然两个罐子都加载了（用lsof双重检查），服务器运行得很好。也许考虑了类加载器的顺序？
EDIT: The project was including two conflicting versions of javax.servlet.servlet-api. Excluded the older one from the pom fixed the issue. Either way, it remains to me a mystery why in one machine although both the jars were loaded (double checked with lsof) the server was running just fine. Maybe the order of the class loader was taken into consideration?
推荐答案
Blockquote
Blockquote
java.lang.SecurityException：类javax.servlet.AsyncContext的签名者信息与同一包中其他类的签名者信息不匹配
我的项目中也抛出了此异常。最后我找到了解决方案。由于使用不同版本引用相同的依赖项而引发的异常。所以java代码签名搞砸了依赖。
This Exception thrown in my project too. At last i find out the solution. The exception thrown because of referring same dependency with different version. So the java code signature mess up with the dependency.
- 添加适当的依赖
- 检查依赖性版本
- 避免同一jar的多重依赖
javax。 servlet
servlet-api 2.5
提供
javax.servlet
servlet-api 2.5
provided
只有一个依赖项是需要
这篇关于带有两个冲突版本的javax.servlet.servlet-api jar的java.lang.SecurityException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
