Java webservice not working with Jdk 6 and Jboss 5.x

Question

I have a class that invokes a WEB SERVICE deployed on the Jboss 5. And my Java enviornment is JDK1.6. Here is a code portion:

System.setProperty("org.apache.xerces.xni.parser.XMLParserConfiguration","org.apache.xerces.parsers.XIncludeAwareParserConfiguration");
final Document doc = this.generateXMLDoc((List) listData);
final String strXMLData = "TestString";
final String endpointURL = PropertyHandler.getValue("printWebServiceEndPoint");
final TestWebService testWebService = new TestWebService(new URL(endpointURL), new QName( "http://test.webservice.xyz/", "TestWebService"));
final TestService tservice = testWebService.getTestServicePort();
final String msg = tservice.print(strXMLData);
if (msg.equals("Abc"))
{
   return false;
}
return true;

I have following jar in my JBOSS_HOME/lib/endorsed directory.

activation.jar, resolver.jar, serializer.jar, stax-api.jar, xalan.jar, xercesImpl.jar, jaxb-api.jar

This webservice is working fine on JBoss4.2.2GA but its breaking on JBoss 5 and throws error given below.

01:50:46,760 INFO  [STDOUT] ERROR 01:50:46,759 (TestServiceInputXMLParser) - com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl cannot be cas to com.sun.xml.bind.api.JAXBRIContext
java.lang.ClassCastException: com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.bind.api.JAXBRIContext
at org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitializeAccessors(EndpointMetaData.java:665)
at org.jboss.ws.metadata.umdm.EndpointMetaData.initializeInternal(EndpointMetaData.java:545)
at org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitialize(EndpointMetaData.java:533)
at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.rebuildEndpointMetaData(JAXWSClientMetaDataBuilder.java:312)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPortInternal(ServiceDelegateImpl.java:269)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:200)
at javax.xml.ws.Service.getPort(Service.java:99)
at edu.wustl.webservice.catissuecore.test.TestWebService.getTestServicePort(TestWebService.java:50)
at edu.wustl.catissuecore.testservicemodule.TestServiceInputXMLParser.callTestService(TestServiceInputXMLParser.java:81)
at edu.wustl.catissuecore.action.TestAction.executeXSS(TestAction.java:159)
at edu.wustl.common.action.XSSSupportedAction.checkForXSSViolation(XSSSupportedAction.java:170)
at edu.wustl.common.action.XSSSupportedAction.execute(XSSSupportedAction.java:76)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:638)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:444)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:382)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:310)
at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069)
at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:274)
at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455)
at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:320)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.owasp.stinger.StingerFilter.doStinger(StingerFilter.java:365)
at org.owasp.stinger.StingerFilter.doStingerFilter(StingerFilter.java:293)
at org.owasp.stinger.StingerFilter.doFilter(StingerFilter.java:122)

Any pointer will be of great use.

Answer 1

I also had a lot of similar problems with JBoss before. Building your webapp for minimalistic containers e.g. Tomcat requires packing a lot of jar files into your war. However, JBoss already has tons of jars already built in. When the same classes are present in several jars, a classloader usually finds your packed classes first (typically implementation, e.g. jaxb-impl and also loading your jaxb-api), then loads the builtin classes (typically api classes, e.g. builtin jaxb-api) and tries to use your implementation objects with the builtin api. This will fail since they are considered to be very distinct classes from distinct sources despite they may be exactly the same. I've even seen errors stating that "class X cannot be cast to class X" which is very counterintuitive until you understand the reasons.

Consequently, you should always avoid packing jars into your war that are built in to JBoss. Probably there's a better way ( in which case I'm also interested ;-) ), but the only reliable strategy we found was:

• Check builtin JBoss jar files and match them against your jars packed into your war
• In case of a match, exclude the jar from your war
• If matching jars have different versions, change your implementation to use the builtin JBoss version

You can use e.g. a separate JBoss maven profile and the packagingExclude configuration option with the maven-war-plugin to exclude the unnecessary war files.

Answer 2

Don't put jaxb/jaxws jars in the endorsed directory - they should already be included in the JBoss container. What has likely happened is that the jaxb-api jar you put in the endorsed directory is a different version of jaxb from the jaxb-impl jar within JBoss.