[SWS-560] IllegalStateException: Could not find SAAJ on the classpath after upgrading from 1.5.7 to 1.5.8 Created: 27/Aug/09 Updated: 04/May/12 Resolved: 09/Nov/09
|Project:||Spring Web Services|
|Reporter:||Stevo Slavić||Assignee:||Arjen Poutsma|
|Original Estimate:||Not Specified|
Seems there is something wrong in fix for
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
even though saaj api and impl 1.3 are on the path.
|Comment by Arjen Poutsma [ 27/Aug/09 ]|
Darn, we should fix this asap.
|Comment by Stevo Slavić [ 29/Aug/09 ]|
Attaching partial fix (org.springframework.ws.spring-ws-core_
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
|Comment by Stevo Slavić [ 29/Aug/09 ]|
Here's another more complete patch ( org.springframework.ws.spring-ws-core_
To be backward compatible with pre
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.
|Comment by Arjen Poutsma [ 16/Sep/09 ]|
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 .
|Comment by Bob Milstead [ 24/Sep/09 ]|
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.
|Comment by Arjen Poutsma [ 09/Nov/09 ]|
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.
|Comment by Rahul Priyadarshi [ 17/Nov/09 ]|
I noticed that this error emanated from a trivial typo on my part.
and then got exactly the same error,
....SEVERE: Servlet.service() for servlet spring-ws threw exception
and thereafter landed on this page through search engine.
|Comment by Arjen Poutsma [ 17/Nov/09 ]|
Could you try a recent snapshot and see if that works better?
|Comment by Rahul Priyadarshi [ 25/Nov/09 ]|
Sorry for the delay.
...SEVERE: Servlet.service() for servlet spring-ws threw exception
|Comment by Arjen Poutsma [ 04/May/12 ]|
Closing old issues