jetty 6.1 & jdk 6: Linkage error

The maven jetty plugin includes the jetty plus functionality, which includes a dependency on the activation.jar, where the DataHandler class is located.

Usually this type of error is caused by having multiple copies of the same jar in different classloaders or even in the same classloader. However, I don't quite see how changing between jdk1.5 and jdk1.6 could cause this.

Can you run with "mvn -X jetty:run" and search for all occurences of the activation jar?

regards
Jan

I ran mvn -X jetty:run > mvn.out and attached that file to this issue.

The problem, by what I can figure out is that jdk 1.6 began including some jar files that had not been in the jdk before. Such as activation.jar, jaxb-api.jar, jaxws-api.jar, and so on. I suspect that the version in the rt.jar conflicts somehow with the one in activation.jar.

I got a similar problem and I it's related to this issue. I am also developing WS with attachment and I am trying to use jetty for the unit tests with no success. Also i am using jdk 1.6.

I am launching jetty embeded with the cargo maven plugin as you can see below

<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<wait>false</wait>
<container>
<containerId>jetty6x</containerId>
<type>embedded</type>
</container>
</configuration>
<dependencies>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>servlet-api-2.5</artifactId>
<version>6.1.5</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>undeploy-and-deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
<goal>deploy</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>

</plugin>

The applcation deployes well, but when i invoke the services i get the following stacktrace.
Any idea would be very helpful.

java.lang.LinkageError: loader constraint violation: when resolving overridden method "org.apache.cxf.jaxb.attachment.JAXBAttachmentUnmarshaller.getAttachmentAsDataHandler(Ljava/lang/String;)Ljavax/activation/DataHandler;" the class loader (instance of org/mortbay/jetty/webapp/WebAppClassLoader) of the current class, org/apache/cxf/jaxb/attachment/JAXBAttachmentUnmarshaller, and its superclass loader (instance of <bootloader>), have different Class objects for the type javax/activation/DataHandler used in the signature
at org.apache.cxf.jaxb.JAXBDataBase.getAttachmentUnmarshaller(JAXBDataBase.java:79)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:64)
at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:102)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:214)
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:151)
at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
at org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

Regards.

Hi Ricard,

Not sure specifically about the cargo plugin, but in general I would try to define a profile in the pom for jdk1.6 and try to exclude the activation.jar from the jetty dependencies.

cheers
Jan

Unfortunately, Gunnar Morlings solution has no effect in my situation, and I did not find a way to remove activation 1.1 from jetty's classpath. I tried excluding it from jetty-naming and jetty-plus in the plugin dependencies as well.

The thing is, Gunnars solution will only affect what is added to the war. But activation 1.1 is pulled in by the dependencies of the jetty plugin somehow.

Usecase:

maven-jaxws-plugin
Use the samples wsgen and wsimport/url included in the src/it folder
Wsgen creates a war that runs and shows the endpoints when started with mvn jetty:run

Made a main class in wsimport that invokes the webservice.

I am running JDK 1.6_07, tried jetty 1.6.0, 1.7.05, maven 2.0.9.

Any ideas?

Best regards

if someone could attach a test project that shows what is going on I'll take a stab at resolving it

moving fix version to 6.1.16 in the mean time

I think here is the solution. It is mandatory not to use geronimo-activation.jar along with JDK-1.6. If you have to support both JDK-1.5 and JDK-1.6, JARs marked with [6] in WHICH_JARS should be in system classpath along with JDK-1.5.

I have run the jetty 6.1.15 maven plugin under jdk 1.5 and under jdk 1.6 using mvn -X jetty:run.

When running under jdk1.5, I can see that the activation.jar is pulled onto the classpath. However, under jdk1.6, the activation.jar is NOT on the classpath. This is as expected, as there is a <profile> in the jetty plus naming module that selectively puts activation.jar on the classpath depending on the jdk being used.

So, as far as I can determine, things are working exactly as expected and desired. At this point, if activation.jar is on the classpath, I can't see that it is because of the maven jetty plugin.

If someone is still experiencing a problem under 6.1.15, can they please run with "mvn -X jetty:run" and post the "pluginArtifacts" from the output.

thanks
Jan

Hi ricard, I understand you use CXF. Could you remove these JARs from your WAR deployment? If your problem goes away this way, then there is nothing to do with Jetty side. You can find this list in apache-cxf-2.1.3/lib/WHICH_JARS.

• geronimo-activation.jar (Or the Sun equivalent) [6]
• geronimo-annotation.jar (Or the Sun equivalent) [6]
• geronimo-javamail.jar (Or the Sun equivalent) [6]
• geronimo-stax-api.jar (Or the Sun equivalent) [6]
• jaxb-api.jar [6]
• wstx-asl.jar [6]
• geronimo-ws-metadata.jar [6]
• geronimo-jaxws_2.1_spec-1.0.jar (Or the Sun equivalent) [6]
• saaj-api.jar [6]
• saaj-impl.jar [6]

I'm going to close this issue for now, as nobody has come back with any evidence of a jetty problem, so it looks like a configuration issue to me. Please reopen if you can demonstrate a problem that needs fixing.

I'm not absolutly sure about that but I think the problem does not come from Jetty but javax.mail.

On my project all the Maven projects have a dependency on log4j-1.2.15.jar, and log4j depends on javax.mail (version 1.4).

In the javax.mail:mail-1.4.pom file we can find:
<dependencies>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1</version>
</dependency>
</dependencies>

But this shouldn't be done with the JDK1.6, so to solve the problem juste add an exclusion on javax.mail or log4j:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>$

</version>
<type>jar</type>
<scope>runtime</scope>
<exclusions>
<!--
Because the JDK1.6 already include the Java Activation API,
otherwise this could generate ClassLoading en Linkage errors
-->
<exclusion>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
</exclusion>
</exclusions>
</dependency>

Hope this help.

Baptiste

Java 1.6 already provide feature of Activation.jar.
so remove Activation.jar from your project lib dir or Server