2

I have a project (say myproject) in which I have hosted a CXF RESTful service and CXF WS/SOAP service, and running on JBoss (6.0.0.FINAL). The RESTful interface is used by all of our internal systems, and the SOAP interface is used by the third party systems (as a callback interface)

Following URLs are working fine.

  • REST URL: http://localhost:8080/myproject/internal/someOperation (content-type: application/json and POST body)

  • SOAP WSDL: http://localhost:8080/myproject/cbsoap?wsdl

Now my problem is that actual SOAP calls are not successful. I use SOAPUI to try the SOAP calls but just to able to query the WSDL. I am getting the following error:-

javax.servlet.ServletException: Servlet execution threw an exception
    org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)

root cause

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/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/apache/cxf/jaxb/attachment/JAXBAttachmentUnmarshaller, and its superclass loader (instance of ), have different Class objects for the type r used in the signature
    org.apache.cxf.jaxb.JAXBDataBase.getAttachmentUnmarshaller(JAXBDataBase.java:78)
    org.apache.cxf.jaxb.io.DataReaderImpl.createUnmarshaller(DataReaderImpl.java:123)
    org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:156)
    org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
    org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
    org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
    org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
    org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:209)
    org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:191)
    org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:114)
    org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185)
    org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
    org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:164)
    org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
Krease
  • 15,805
  • 8
  • 54
  • 86
Higher-Kinded Type
  • 1,964
  • 5
  • 27
  • 44
  • This sounds really scary: `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/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/apache/cxf/jaxb/attachment/JAXBAttachmentUnmarshaller, and its superclass loader (instance of ), have different Class objects for the type r used in the signature` – Donal Fellows May 08 '12 at 10:09
  • I mean, different `Class` objects? Definitely sounds like class loader games gone wrong. (Not enough experience with debugging these things to help.) – Donal Fellows May 08 '12 at 10:10
  • My understanding is that the JAXBAttachmentUnmarshaller class is loaded twice (or already), and the getAttachmentAsDataHa‌​ndler method signatures are different. I am not sure if that makes sense. But need to get rid of one of them but don't know which one and how. – Higher-Kinded Type May 08 '12 at 10:26
  • @DonalFellows The issue here is that JBoss comes with Java 6+ and javax.activiation.DataHandler is actually included in standard Java 6. When mixing it with different classloaders there is no way to be able to delegate the EAR/WAR to use it's own `javax.activation.DataHandler` since its a system level class. Hence the LinkageError. If it were a JAR included for JBoss the parent-last mechanism would work. – John Vint May 08 '12 at 18:22
  • @VivekRagunathan The reason why it is probably not JAXBAttachmentUnmarshaller is because JAXBAttachmentUnmarshaller is not a system class (it is not included with the Java runtime) so no LinkageError should occur – John Vint May 08 '12 at 18:24

2 Answers2

6

LinkageError is JBoss is generally caused by your app packaging its own copies of certain libraries that JBoss considers restricted. These are usually things in the java.* and javax.* packages.

Looking at your stack trace, I'd guess that the culprit is javax.activation.DataHandler. Check your app's bundled JAR files, make sure there's nothing like that in them. If there is, then remove it.

It may not be javax.activation.DataHandler, but may be something it in turn depends on.

skaffman
  • 398,947
  • 96
  • 818
  • 769
  • These are the jars in my package lib (WEB-INF\lib). It does not have any javax.* but how do I find which one depends on that? aopalliance-1.0.jar, asm-3.3.jar, commons-logging-1.1.1.jar, cxf-api-2.4.6.jar, cxf-bundle-jaxrs-2.4.6.jar, cxf-common-utilities-2.4.6.jar, cxf-rt-bindings-soap-2.4.6.jar, cxf-rt-bindings-xml-2.4.6.jar, cxf-rt-core-2.4.6.jar, cxf-rt-databinding-jaxb-2.4.6.jar, cxf-rt-frontend-jaxws-2.4.6.jar, cxf-rt-frontend-simple-2.4.6.jar, cxf-rt-transports-common-2.4.6.jar, cxf-rt-transports-http-2.4.6.jar, cxf-rt-ws-addr-2.4.6.jar, cxf-tools-common-2.4.6.jar (continued....) – Higher-Kinded Type May 08 '12 at 12:19
  • (continued....) geronimo-activation_1.1_spec-1.1.jar geronimo-annotation_1.0_spec-1.1.1.jar geronimo-javamail_1.4_spec-1.7.1.jar geronimo-servlet_2.5_spec-1.1.2.jar jettison-1.3.1.jar jetty-continuation-7.4.5.v20110725.jar jetty-http-7.4.5.v20110725.jar jetty-io-7.4.5.v20110725.jar jetty-security-7.4.5.v20110725.jar jetty-util-7.4.5.v20110725.jar jsr311-api-1.1.1.jar log4j-1.2.9.jar neethi-3.0.1.jar slf4j-api-1.6.2.jar spring-aop-3.0.6.RELEASE.jar spring-asm-3.0.6.RELEASE.jar spring-beans-3.0.6.RELEASE.jar spring-context-3.0.5.RELEASE.jar (continued....) – Higher-Kinded Type May 08 '12 at 12:20
  • (continued...) spring-core-3.0.5.RELEASE.jar spring-expression-3.0.6.RELEASE.jar spring-web-3.0.5.RELEASE.jar stax2-api-3.1.1.jar woodstox-core-asl-4.1.1.jar xml-resolver-1.2.jar xmlschema-core-2.0.1.jar – Higher-Kinded Type May 08 '12 at 12:21
  • @VivekRagunathan: Open them all (with a zip tool) and have a look. – skaffman May 08 '12 at 15:02
  • 1
    @VivekRagunathan skaffman is more then likely spot on with this. There is almost certainly a third party library which is including the `javax.activation.DataHandler` class – John Vint May 08 '12 at 18:21
  • I dont see that javax related jar in my lib. Not sure where it is pulling from. – Higher-Kinded Type May 09 '12 at 10:33
  • You can search for classes in JAR files using a simple shell onliner in when in your `WEB-INF/lib` folder: `for x in 'ls' ; do unzip -l $x ; done | egrep 'jar|DataHandler` (just replace `'` with `backtick` around ls); if you are using maven for building and dependency management, you should exclude such libraries (in my case, it was pulled as a dependency of javax.mail) using ``: [maven doc](http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html) – miha Jun 14 '13 at 16:27
0

I finally solved the problem but it is really weird.

  1. I added cxf-rt-frontend-jaxws and cxf-bundle-rs as dependencies and mark some exclusions -> jetty-server, gernomino-servlet.
  2. I had the beans.xml under WEB-INF folder but had to place it under src/main/resources. The beans.xml is expected to be under the classpath, instead of WEB-INF.

Thanks for your responses.

Higher-Kinded Type
  • 1,964
  • 5
  • 27
  • 44