I have a Linkage error where it seems like Jboss (5.2) provides one version of the class org.apache.cxf.jaxb.attachment.JAXBAttachmentMarchaller
whereas I somewhere provide another implementation of the class. I have searched for the class and it is the maven project cxf-rt-databinding-jaxb
which contains it, so I've excluded that project from my dependency which use Apache CXF, but the error remains.
I don't really understand the error message, especially the part ...have different Class objects for the type shaller.addMtomAttachment(Ljavax/activation/DataHandler; Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
JAXBAttachmentMarchaller
into the project?Please correct me if there is another solution to this problem.
java.lang.LinkageError: loader constraint violation: when resolving overridden method
"org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller
.addMtomAttachment(Ljavax/activation/DataHandler;Ljava/lang/String;
Ljava/lang/String;)Ljava/lang/String;"
the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader)
of the current class, org/apache/cxf/jaxb/attachment/JAXBAttachmentMarshaller,
and its superclass loader (instance of <bootloader>), have different Class objects for
the type shaller.addMtomAttachment(Ljavax/activation/DataHandler; Ljava/lang/String;
Ljava/lang/String;)Ljava/lang/String; used in the signature
at org.apache.cxf.jaxb.JAXBDataBase.getAttachmentMarshaller(JAXBDataBase.java:82)
at org.apache.cxf.jaxb.io.DataWriterImpl.createMarshaller(DataWriterImpl.java:127)
at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleHeaderPart(SoapOutInterceptor.java:242)
at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:164)
at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:81)
at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:61)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
at com.sun.proxy.$Proxy440.getDeviceDetails(Unknown Source)
at com.company.MyMethod(MyClass.java:52)
at org.quartz.core.JobRunShell.run(JobRunShell.java:199)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:546)
How can do I find the dependency that is responsible for packaging JAXBAttachmentMarchaller into the project?
Search on the web of a maven project which bundles the file. For me it was cxf-rt-frontend-jaxws
.
What you need to do is to remove this dependency from the assembly, it must not be included in the WAR/EAR-file since JBoss provides another version of the dependency and there is a conflict.
Look in your pom.xml
for cxf-rt-frontend-jaxws
and make sure it has the tag <scope>provided</scope>
since we want the server to provide the dependency. If you don't have cxf-rt-frontend-jaxws
in your pom.xml
it means that the project is a sub dependency to one of your dependencies. This is tricky to resolve, since the dependency can exist in several sub dependencies. Some people recommend to use mvn dependency:tree
in order to find which projects that are responsible for bundling the dependency in the WAR/EAR-file.
I found the responsible project, which was an in house component, so I could easily add <scope>provided</scope>
to the component to remove cxf-rt-frontend-jaxws*jar
from the WAR/EAR-file. I verified that the dependency was no longer bundled in the WAR-file by extracting it and listing WEB-INF/lib
where it was no longer listed.
If you cannot change the scope, you have must use the exclude-tag to remove it from the assembly.