Javawebservice不能与Jdk 6和Jboss 5. x一起工作

Question

我有一个调用部署在JBoss5上的WEB服务的类。我的Java环境是JDK1。6.以下是代码部分：

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;

我在JBOSS_HOME/lib/approved目录中有以下jar。

激活。jar，解析器。jar，序列化程序。jar，staxapi。杰尔，泽兰。jar，xercesImpl。jar，jaxb api。罐子

此Web服务在JBoss4.2.2GA上运行良好，但在JBoss5上中断并抛出以下错误。

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)

任何指针都会派上大用场。

Answer 1

不要将jaxb/jaxws JAR放在认可的目录中——它们应该已经包含在JBoss容器中。可能发生的情况是，您放在认可目录中的jaxb api jar是与JBoss中的jaxb impl jar不同的jaxb版本。

Answer 2

我以前在JBoss上也遇到过很多类似的问题。为简化容器（如Tomcat）构建Web应用程序需要将大量jar文件打包到war中。然而，JBoss已经内置了大量JAR。当相同的类出现在多个JAR中时，类加载器通常会首先找到打包类（通常是实现类，例如jaxb impl，也会加载jaxb api），然后加载内置类（通常是api类，例如内置jaxb api），并尝试将实现对象与内置api一起使用。这将失败，因为它们被认为是来自不同来源的非常不同的类，尽管它们可能完全相同。我甚至看到过错误，说“X类不能转换为X类”，这是非常违反直觉的，直到你理解了原因。

因此，您应该始终避免将内置于JBoss的JAR打包到war中。也许有更好的方法（在这种情况下，我也感兴趣；-），但我们找到的唯一可靠的策略是：

• 检查内置JBoss jar文件，并将它们与打包到war中的jar进行匹配

例如，您可以在maven war插件中使用单独的JBoss maven配置文件和PackageExclude配置选项来排除不必要的war文件。