OK, you have done a nice simple Web service client, it runs fine in your tests, you bung it on JBoss and when ever you trigger it you get something like this
java.lang.LinkageError: loader constraint violation: when resolving method “javax.xml.ws.Service.(Ljava/net/URL;Ljavax/xml/namespace/QName;)V” the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the current class, com/sun/j2ee/blueprints/opc/powebservice/XYZService, and the class loader (instance of ) for resolved class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature
You might miss the “loader constraint violation” part and think that its to do with the QName, or that your @WebServiceRef annotation is not working, well don’t bother, you have a clashing .Jar library, and its most likely going to be “stax-api” (which Jboss loads before you even get there with your app), so you will want to looking in your Lib directory ( which will be in the “WEB-INF” directory in your war file or build target directory ) of your packaged app to see if the little devil is in there, if you’re dealing with your libs manually then you are going to just have to remember why you put it there (although http://www.findjar.com/ can be a lot of help there), if you are using maven then the following command will tell what jar’s come from which libs
mvn dependency:tree
This gives you the following kind of display
[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.firstbest:fbs-mobile-proxy:war:0.1
[INFO] +- asm:asm:jar:3.3:compile
[INFO] +- org.apache.ant:ant:jar:1.7.0:compile
[INFO] ' - org.apache.ant:ant-launcher:jar:1.7.0:compile
[INFO] +- com.sun.jersey:jersey-servlet:jar:1.12:compile
[INFO] ' - com.sun.jersey:jersey-server:jar:1.12:compile
[INFO] +- com.sun.jersey:jersey-json:jar:1.12:compile
[INFO] ' +- org.codehaus.jettison:jettison:jar:1.1:compile
[INFO] ' ' - stax:stax-api:jar:1.0.1:compile
[INFO] ' +- com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile (version managed from
2.2.3-1)
[INFO] ' ' - javax.xml.bind:jaxb-api:jar:2.1:compile
[INFO] ' ' - javax.activation:activation:jar:1.1:compile
[INFO] ' +- org.codehaus.jackson:jackson-core-asl:jar:1.9.2:compile
[INFO] ' +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.2:compile
[INFO] ' +- org.codehaus.jackson:jackson-jaxrs:jar:1.9.2:compile
[INFO] ' +- org.codehaus.jackson:jackson-xc:jar:1.9.2:compile
[INFO] ' - com.sun.jersey:jersey-core:jar:1.12:compile
[INFO] +- log4j:log4j:jar:1.2.16:compile
[INFO] +- junit:junit:jar:4.10:test
[INFO] ' - org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] +- taglibs:standard:jar:1.1.2:compile
[INFO] +- org.apache.ws.commons:ws-commons-util:jar:1.0.1:compile
[INFO] ' - xml-apis:xml-apis:jar:2.0.2:compile (version managed from 1.0.b2)
[INFO] - org.apache.neethi:neethi:jar:3.0.1:compile
[INFO] +- wsdl4j:wsdl4j:jar:1.6.2:compile
[INFO] - org.codehaus.woodstox:woodstox-core-asl:jar:4.0.8:compile
[INFO] - org.codehaus.woodstox:stax2-api:jar:3.0.2:compile
You will now need to put in exclusions in your pom.xml to stop the jars that you don’t want from being loaded in, here is an example
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-servlet</artifactId>
<version>1.12</version>
<exclusions>
<exclusion>
<artifactId>stax-api</artifactId>
<groupId>javax.xml.stream</groupId>
</exclusion>
</exclusions>
</dependency>
You might have to add a number of these and check the dependency:tree each time to make sure another does not pop in, in order to get them all.
This SHOULD fix your problem, but sometimes you either want your version of the Jar file to be on the server or you simply cant seem to get rid of a jar field in your build, you can tell jboss to use your jars over its own one by adding a jboss-classloading.xml file in src/main/webapp/WEB-INF directory. and adding the following lines to it.
<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
export-all="NON_EMPTY"
import-all="true"
parent-first="false">
</classloading>
That should sort it out.
Old Comments
————
##### Ben Poole(23/04/2012 23:11:54 GDT)
This sort of shyte is why we love Java so.
No. Really.
##### Mark Myers(12/05/2012 13:23:16 GDT)
tell me about it
