IllegalStateException: Could not find SAAJ on the classpath after upgrading from 1.5.7 to 1.5.8 [SWS-560]

[gregturn]

Stevo Slavić opened SWS-560 and commented

Seems there is something wrong in fix for #650 (r1427 on svn), saaj version doesn't get resolved well in case where a SOAP message's envelope has a body with elements that reference a non-declared namespace/prefix like in following:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
soapenv:Header/
soapenv:Body
ndns:DoSomethingRequest/
</soapenv:Body>
</soapenv:Envelope>

Such messages would previously (with SWS 1.5.7) result in SOAP Fault with Server faultcode and faultstring:

Could not access envelope: Unable to create envelope from given source: ; nested exception is com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:

while now (with SWS 1.5.8) a HTTP error 500 is returned with following stack trace:

java.lang.IllegalStateException: Could not find SAAJ on the classpath
at org.springframework.ws.soap.saaj.SaajSoapMessage.getImplementation(SaajSoapMessage.java:261)
at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:84)
at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:70)
at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:168)
at org.springframework.ws.transport.AbstractWebServiceConnection.receive(AbstractWebServiceConnection.java:86)
at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:86)
at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57)
at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:230)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)

even though saaj api and impl 1.3 are on the path.

---

Affects: 1.5.8

Attachments:

• org.springframework.ws.spring-ws-core_SWS-560_fix.patch (17.07 kB)
• org.springframework.ws.spring-ws-core_SWS-560_partial-fix.patch (3.71 kB)

Issue Links:

• Refactored SaajSoapMessage getImplementation() method hides root cause problems [SWS-569] #690 Refactored SaajSoapMessage getImplementation() method hides root cause problems
  ("is duplicated by")

1 votes, 3 watchers

[gregturn]

Arjen Poutsma commented

Darn, we should fix this asap.

[gregturn]

Stevo Slavić commented

Attaching partial fix (org.springframework.ws.spring-ws-core_#683_partial-fix.patch), which makes SaajSoapMessageException to be thrown, with appropriate error message, from SaajUtils.getSaajVersion(SOAPMessage soapMessage) method if envelope could not be accessed. Unit test included.

Still missing is part where instead of HTTP 500 error a SOAPFault should be returned - couldn't yet find which change made the difference.

In between the 1.5.7 and 1.5.8 versions AbstractWsSecurityInterceptor got new EndpointExceptionResolver exceptionResolver property (as part of resolving #673 issue). Not sure if that change is related to this issue, but shouldn't AbstractWsSecurityInterceptor have some sort of a collection with all exception resolvers instead of just one (like in org.springframework.ws.server.MessageDispatcher), to give all the exception resolvers chance to try to resolve the exception in order they were configured? Similarly to MessagesDispatcher these exception resolvers should probably be automatically picked up ( @Autowired anyone :) ).

[gregturn]

Stevo Slavić commented

Here's another more complete patch ( org.springframework.ws.spring-ws-core_#683_fix.patch ) which fixes changes made to AbstractWsSecurityInterceptor in #673 (only single endpointExceptionResolver could be bound, and it had to be manually injected to AbstractWSSecurityInterceptor implementation, and there wasn't a way to have simple validation exception handling get triggered at all (resulting in HTTP 500 instead of SOAPFault in case when sole injected endpoint exception resolver didn't resolve exception and in case there was no endpoint exception resolver configured to the AbstractWSSecurityInterceptor).

To be backward compatible with pre #673 behavior, additional parameter useEndpointExceptionResolvers has been added to AbstractWsSecurityInterceptor which defaults to false, thus by default using simple validation exception handling, but allowing use of endpoint exception resolvers to be configured - all endpoint exception resolvers are "autowired" to AbstractWSSecurityInterceptor, but different ones can be injected manually through configuration.

To solve issue where invalid message results in HTTP 500 instead of SOAPFault, I've adjusted WebServiceMessageReceiverObjectSupport.handleConnection method - if any unhandled exception is thrown during handling connection reception (like SaajSoapMessageException when trying to construct SaajSoapMessage), that exception would previously not get handled and only a HTTP 500 error would get returned; now with the patch soap fault with client/sender code is returned, and exception's message is used as fault string (just like in resolving validation exception). This part of the patch should probably be redone better.

Patch includes some javadoc comment typo fixes as well.

[gregturn]

Arjen Poutsma commented

Thanks for the patches! Most appreciated!

I'm not entirely sure whether autodetection of exception resolvers for the security interceptor is such a good idea. The main reason for putting that behavior in the MessageDispatcher(Servlet) is that you typically don't configure the dispatcher explicitly, and hence they need to be detected. The interceptor, on the other hand, is always configured explicitly, so I see no harm in configuring the resolvers for it manually. Getting rid of the autodetection also removes the need of the "useEndpointExceptionResolvers" property, if I understand correctly.

Do you see my point? And if so, could you change your patch? I could do it too, of course, but I want to make sure you agree first :).

[gregturn]

Bob Milstead commented

I tried 1.5.9-SNAPSHOT today and still have a problem similar to this. The interesting thing is that it works fine when I deploy to a tomcat on my development box, but when I check the same project into svn and it gets built and deployed by hudson, the stack trace below is generated on the server. Let me know if I can provide additional information, log files, configuration files, etc that may help you.

Note that I am using <property name="validationActions" value="Signature Timestamp Encrypt" /> I do have the complete round trip working in my development environment. This stack trace is masking whatever my real problem is in the alternate deployment environment.

I am also including a bit of my log showing the message sent from the same client to the deployment that works, so you can see the soap header.

2009-09-24 17:28:51,897 DEBUG (WebServiceMessageReceiverObjectSupport.java:114) - Accepting incoming [org.springframework.ws.transport.http.HttpServletConnection@2abd079e] to [http://desmond.hrworx.com:8380/formworx-ws/processService]
2009-09-24 17:28:51,923 TRACE (SaajUtils.java:189) - SOAPElement [com.sun.xml.internal.messaging.saaj.soap.ver1_1.Envelope1_1Impl] implements SAAJ 1.3
2009-09-24 17:28:51,927 DEBUG (FrameworkServlet.java:588) - Could not complete request
java.lang.IllegalStateException: Could not find SAAJ on the classpath
	at org.springframework.ws.soap.saaj.SaajSoapMessage.getImplementation(SaajSoapMessage.java:261)
	at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:84)
	at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:70)
	at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:168)
	at org.springframework.ws.transport.AbstractWebServiceConnection.receive(AbstractWebServiceConnection.java:86)
	at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:86)
	at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57)
	at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:230)

2009-09-24 16:29:28,123 TRACE (MessageDispatcher.java:163) - 
Received request [<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<SOAP-ENV:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" 
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="8978AAD679C263ABE212538313676254" 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

...

</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></SOAP-ENV:Body></SOAP-ENV:Envelope>]
2009-09-24 16:29:28,193 TRACE (SaajUtils.java:189) - SOAPElement [com.sun.xml.internal.messaging.saaj.soap.ver1_1.Header1_1Impl] implements SAAJ 1.3
2009-09-24 16:29:28,230 TRACE (SaajUtils.java:189) - SOAPElement [com.sun.xml.internal.messaging.saaj.soap.ver1_1.HeaderElement1_1Impl] implements SAAJ 1.3
2009-09-24 16:29:28,234 DEBUG (AbstractAddressingEndpointMapping.java:177) - Request [SaajSoapMessage {http://www.w3.org/2001/04/xmlenc#}EncryptedData] uses [WS-Addressing 1.0]
2009-09-24 16:29:28,284 DEBUG (AbstractActionEndpointMapping.java:95) - Looking up endpoint for action [http://hrworx.com/TaskList]
2009-09-24 16:29:28,289 DEBUG (MessageDispatcher.java:251) - Endpoint mapping [org.springframework.ws.soap.addressing.server.SimpleActionEndpointMapping@6a0ee670] maps request to endpoint [com.hrworx.formworx.ws.endpoint.TaskListEndpoint@15e3752b]
2009-09-24 16:29:28,290 DEBUG (SoapMessageDispatcher.java:119) - Handling MustUnderstand header {http://www.w3.org/2005/08/addressing}To
2009-09-24 16:29:28,291 DEBUG (Wss4jSecurityInterceptor.java:500) - Validating message [SaajSoapMessage {http://www.w3.org/2001/04/xmlenc#}EncryptedData] with actions [Signature Timestamp Encrypt]
2009-09-24 16:29:29,944 TRACE (SaajUtils.java:189) - SOAPElement [com.sun.xml.internal.messaging.saaj.soap.ver1_1.Body1_1Impl] implements SAAJ 1.3
2009-09-24 16:29:29,945 DEBUG (AbstractLoggingInterceptor.java:160) - 
Request: <xml-fragment xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>

[gregturn]

Arjen Poutsma commented

Applied the patch, thanks! Also kudos for finding and fixing those typos in the code and javadoc.

I did not apply the change to WebServiceMessageReceiverObjectSupport, since that would have made the transport layer SOAP-specific, which it currently isn't. I also did not apply the detection of EndpointExceptionResolvers to AbstractWsSecurityInterceptor, for reasons explained above.

[gregturn]

Rahul Priyadarshi commented

I noticed that this error emanated from a trivial typo on my part.
I had declared an element in my xsd with spaces in the beginning of its name attribute declaration.
like : <element name= " annoyingElement" type="string"/>

and then got exactly the same error,

....SEVERE: Servlet.service() for servlet spring-ws threw exception
java.lang.IllegalStateException: Could not find SAAJ on the classpath
at org.springframework.ws.soap.saaj.SaajSoapMessage.getImplementation(SaajSoapMessage.java:261)
at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:84)
at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:70)............

and thereafter landed on this page through search engine.
I've verified and replicated the error so i'm sure abt it now.

[gregturn]

Arjen Poutsma commented

@Rahul:

Could you try a recent snapshot and see if that works better?

[gregturn]

Rahul Priyadarshi commented

Sorry for the delay.
I did try the snapshot.It now has a better error reporting.
Replicating the faulty namespace declaration and making the service call throws a clearer error description :

...SEVERE: Servlet.service() for servlet spring-ws threw exception
org.xml.sax.SAXParseException: The content of elements must consist of well-formed character data or markup.
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1231)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333).......

[gregturn]

Arjen Poutsma commented

Closing old issues