Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-560

IllegalStateException: Could not find SAAJ on the classpath after upgrading from 1.5.7 to 1.5.8

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 1.5.8
    • Fix Version/s: 1.5.9
    • Component/s: Core
    • Labels:
      None
    • Environment:
      saaj 1.3

      Description

      Seems there is something wrong in fix for SWS-525 (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.

        Issue Links

          Activity

          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Darn, we should fix this asap.

          Show
          arjen.poutsma Arjen Poutsma added a comment - Darn, we should fix this asap.
          Hide
          sslavic Stevo Slavić added a comment -

          Attaching partial fix (org.springframework.ws.spring-ws-core_SWS-560_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 SWS-549 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 ).

          Show
          sslavic Stevo Slavić added a comment - Attaching partial fix (org.springframework.ws.spring-ws-core_ SWS-560 _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 SWS-549 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 ).
          Hide
          sslavic Stevo Slavić added a comment -

          Here's another more complete patch ( org.springframework.ws.spring-ws-core_SWS-560_fix.patch ) which fixes changes made to AbstractWsSecurityInterceptor in SWS-549 (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 SWS-549 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.

          Show
          sslavic Stevo Slavić added a comment - Here's another more complete patch ( org.springframework.ws.spring-ws-core_ SWS-560 _fix.patch ) which fixes changes made to AbstractWsSecurityInterceptor in SWS-549 (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 SWS-549 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.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          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 .

          Show
          arjen.poutsma Arjen Poutsma added a comment - 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 .
          Hide
          rmilstead Bob Milstead added a comment -

          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.

          stack trace

          2009-09-24 17:28:51,897 DEBUG (WebServiceMessageReceiverObjectSupport.java:114) - Accepting incoming [[email protected]079e] 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)

          log

          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.spring[email protected]6a0ee670] maps request to endpoint [[email protected]]
          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#"/>

          Show
          rmilstead Bob Milstead added a comment - 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. stack trace 2009-09-24 17:28:51,897 DEBUG (WebServiceMessageReceiverObjectSupport.java:114) - Accepting incoming [[email protected]079e] 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) log 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.spring[email protected]6a0ee670] maps request to endpoint [[email protected]] 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#"/>
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          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.

          Show
          arjen.poutsma Arjen Poutsma added a comment - 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.
          Hide
          rhax Rahul Priyadarshi added a comment -

          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.

          Show
          rhax Rahul Priyadarshi added a comment - 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.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          @Rahul:

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

          Show
          arjen.poutsma Arjen Poutsma added a comment - @Rahul: Could you try a recent snapshot and see if that works better?
          Hide
          rhax Rahul Priyadarshi added a comment -

          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).......

          Show
          rhax Rahul Priyadarshi added a comment - 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).......
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Closing old issues

          Show
          arjen.poutsma Arjen Poutsma added a comment - Closing old issues

            People

            • Assignee:
              arjen.poutsma Arjen Poutsma
              Reporter:
              sslavic Stevo Slavić
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0d
                0d
                Logged:
                Time Spent - 1.65h
                1.65h