|
Replies:
4
-
Last Post:
Mar 28, 2009 6:39 PM
by: Clive Brettingh...
|
|
|
|
|
|
|
Xerces not playing nice with Glassfish / Metro?
Posted:
Mar 25, 2009 9:38 PM
|
|
|
EDIT: Below edit is wrong - Xalan is definitely causing problems.
EDIT: I've replaced all references to the Xerces/Xalan libraries with the equivalent classes in JSE 1.5, and that seems to have solved my problem. I need to keep Xalan around as WSS4J depends on some classes it provides, but Xerces is gone, so that's where I'm laying the blame 
I've got some issues with Xerces / Xalan (I'm not sure which one is causing the issues - I think it's Xerces, but not 100% sure): When I undeploy/redeploy my application from/to Glassfish, I then start getting errors like the following:
com.sun.xml.messaging.saaj.SOAPExceptionImpl: Error during saving a multipart message
at com.sun.xml.messaging.saaj.soap.MessageImpl.saveChanges(MessageImpl.java:1158)
at com.sun.xml.messaging.saaj.soap.MessageImpl.writeTo(MessageImpl.java:1247)
at my.package.name.WebServiceHandlerImpl.handleMessage(WebServiceHandlerImpl.java:191)
at my.package.name.WebServiceHandlerImpl.handleMessage(WebServiceHandlerImpl.java:41)
at com.sun.xml.ws.handler.HandlerProcessor.callHandleMessageReverse(HandlerProcessor.java:336)
at com.sun.xml.ws.handler.HandlerProcessor.callHandlersResponse(HandlerProcessor.java:207)
at com.sun.xml.ws.handler.ServerSOAPHandlerTube.callHandlersOnResponse(ServerSOAPHandlerTube.java:160)
at com.sun.xml.ws.handler.HandlerTube.processResponse(HandlerTube.java:160)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:605)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.JAXWSServlet.doPost(JAXWSServlet.java:176)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to get header stream in saveChanges:
at com.sun.xml.messaging.saaj.soap.MessageImpl.saveChanges(MessageImpl.java:1135)
... 59 more
Caused by: java.io.IOException: org.apache.xml.serializer.ToXMLSAXHandler
at com.sun.xml.messaging.saaj.soap.impl.EnvelopeImpl.output(EnvelopeImpl.java:329)
at com.sun.xml.messaging.saaj.soap.impl.EnvelopeImpl.output(EnvelopeImpl.java:340)
at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.getContentAsStream(SOAPPartImpl.java:336)
at com.sun.xml.messaging.saaj.soap.MessageImpl.getHeaderBytes(MessageImpl.java:979)
at com.sun.xml.messaging.saaj.soap.MessageImpl.saveChanges(MessageImpl.java:1130)
... 59 more
If I then stop/start the server (e.g ./asadmin stop-domain domain1; ./asadmin start-domain domain1) everything then goes back to working until I do redeploy the application.
Importantly, it only seems to be affecting the writeTo method in EnvelopeImpl - the data still gets passed to my implementing class, and soapUI still receives the response. This wouldn't be a major issue except that I'm using SOAPMessageHandlers to implement web service security (Yes, I suspect I could use WSP stuff in the WSDL, but I'm not sure the client is expecting that. This will provide the least surprises to the client. The handlers are configured via handler_chain.xml, which I specify via the @HandlerChain.file annotation on my Web Service class).
A little background: The application is an EAR, consisting of two WARs (one for the main web application, one for the web service). I'm running Glassfish V2 UR2, with a Java version of:
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode, sharing)
I'm running Ubuntu 7.10.
The Xerces JAR is quite old - 2.6.2, as is Xalan - 2.6.0.
I've seen other people getting similar errors, but I don't know how to solve this... I could remove the Xerces/Xalan libs, but what do I replace them with? The JSE 5.0 equivalents from the com.sun.org.apache.xerces.* packages? Worth a shot, I guess. Do recall seeing something that they're rather buggy, but I've got no evidence for that. Anyone able to confirm/deny?
I've also tried moving them into the $GLASSFISH_HOME/lib dir, which seems to solve the problem, but that might create issues elsewhere, so I'm not sure I'm happy with that solution. Also adds slightly more complexity to Glassfish server creation/maintenance.
Part of the problem is that, I guess, they're conflicting with a library or property somewhere in Glassfish. When I load up Glassfish, it does it's various start-up code, and sets the property [javax.xml.parsers.DocumentBuilderFactory] to [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl], but when I redeploy my application (undeploy/deploy), that property is no longer set. This is regardless of whether I've included Xerces/Xalan or not. Is this known behaviour?
After playing around a bit more, I've discovered that I can undeploy/redploy as much as I like, *provided I haven't called the web service* - once I've called the web service, I need to reboot the server after the next redeploy, which implies it's not a problem with Glassfish configuration and Xerces/Xalan configuration, but rather that it's a problem with the way Xerces/Xalan interacts with however EnvelopeImpl.writeTo... I'm assuming this because there's plenty of code that calls into Xerces/Xalan but that doesn't touch the web service. That code also continues to work, regardless of whether the web service is broken or not.
Anyway, any ideas if this is a configuration issue that I can solve relatively easily? Or is this a more deeply ingrained issue that I can't really fix without removing Xerces/Xalan or making changes to Glassfish's configuration?
Finally, I've also got an issue with my web service class - not sure if this is related or not, but it could be:
EDIT: Solved the following problem - just needed to change the <servlet-name> elements to match the name of the implementing class. Didn't solve the above problem 
I've got a WSDL, used wsimport to generate Java classes from it, and then extended the generated interface to create the implementation class. In the Impl class, I set the @WebService annotation, with the property endpointInterface="InterfaceName", and several other attributes. However, when I deploy the application, it informs me that I can't have both @WebService.Name and @WebService.endpointInterface. Ok, fair enough. I removed the @WebService.name attribute, and everything broke - started getting class cast exceptions, which I recall getting before, and result from Glassfish trying to cast it as a Servlet object, rather than handling it as a web service. The @WebService.name attribute in the Interface matches the relevant <servlet-name> attributes in the web.xml file, so I'm a little stumped as to why it thinks that it's a Servlet object and not a web service. Any thoughts? I don't imagine it's related to the above, but I suppose it could be. The WebService deploys and runs just fine, my @HandlerChains are executed, etc, just prints out a stack trace and the message "wsgen failed - proceeding under the assumption that the user packaged all required objects properly" afterwards.
Not sure if that's related to my problem above, or if it's actually a problem in general. Doesn't appear to be, but mentioning it just in case.
Message was edited by: ipsi
27/03/09: Added more information, and supplied fix for a now known to be unrelated problem.
Message was edited by: ipsi
|
|
|
|
|
|
|
Re: Xerces not playing nice with Glassfish / Metro?
Posted:
Mar 25, 2009 9:55 PM
in response to: ipsi
|
|
|
And the error is back. Is it Xerces or Xalan? Or what? I'm so goddamn confused. Or is it actually a bug somewhere? Or an funny interaction between WSS4J and whatever is doing security in Glassfish? Gah. Too many places to be looking for solutions...
|
|
|
|
|
|
|
|
|
Re: Xerces not playing nice with Glassfish / Metro?
Posted:
Mar 25, 2009 10:27 PM
in response to: ipsi
|
|
|
Removed Xalan and I'm pretty sure that's finally fixed it. Unfortunately, it would be a lot of work to remove all references to Xalan from the application, assuming I can find an alternative. *sigh* Why is *nothing* ever simple?
EDIT: Especially given that WSS4J kinda depends on it...
Message was edited by: ipsi
|
|
|
|
|
|
|
|
|
|
|
|
Re: Xerces not playing nice with Glassfish / Metro?
Posted:
Mar 28, 2009 6:39 PM
in response to: ipsi
|
|
|
If your application (or library) uses Xerces directly (rather than
relying of xerces specific features via JAXP, which is bad form) then
you can prevent Xerces interfering with JAXP simply by removing the
service configuration from the Xerces jar (expand jar remove
META-INF/services/javax.xml.parsers.DocumentBuilderFactory &
META-INF/services/javax.xml.parsers.SAXParserFactory, re-jar and use
this version). Similar applies if Xalan is the problem
(META-INF/services/java.xml.transform.TransformerFactory).
JAXP will see the default implementation, and the other code can still
use Xalan/Xerces directly.
Depending on the particular packaging the jar with the services entries
may vary.
(Another, more aggressive, approach is to use system properties or
jaxp.properties to suppress the services lookup for JAXP completely).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net
|
|
|
|
|
java.net RSS
