java.lang.SecurityException with two conflicting v

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.

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.

Any ideas?

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?

回答1:

Blockquote

java.lang.SecurityException: class "javax.servlet.AsyncContext"'s signer information does not match signer information of other classes in the same package

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.

Add proper dependency
Check with dependency version
Avoid multiple dependency of same jar

javax.servlet
servlet-api 2.5
provided

Only one dependency is needed

回答2:

You shouldn't need to exclude it; any reference to the servlet-api for a project that will be deployed in a container should use <scope>provided</scope> to ensure that only the container's version is present at runtime (how to add the servlet api to my pom.xml).