Announcement Announcement Module
Collapse
No announcement yet.
Web Service Hosting & Exception Propogation Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Web Service Hosting & Exception Propogation

    We have a requirement to host web services over HTTP and JMS and have had success with Spring-WS in the past. A new requirement is to provide pluggable logic to back the various web services. The idea is to consume an external WSDL and hosts its services. My current prototype has a single WS endpoint that accepts/returns DOM objects. I've got the various logic plugins described in terms of Spring Integration and have the endpoint selecting the proper channel needed to route the DOM over to the correct logic plugin (message target). I've even got JAXB transformations happening via a channel interceptor for those plugins that don't wish to work with DOM. The only problem I'm having is getting exceptions that happen in the SI world to return back to the Spring-WS endpoint so that it can be converted into a SOAP fault and returned to the WS caller. Based on experimentation and watching the SI code in the debugger, SI wants to route exceptions to an error channel where you can log things, retry, etc. I've even tried writing a custom ErrorHandler that squirreled away the exception thrown in the logic object into a thread-local that the WS endpoint could examine but that fails because the WS endpoint is not guaranteed to be running on the same thread that the SI message target is. Does anybody have any ideas on what I can try to get an exception thrown from an SI message destination back to the Spring-WS endpoint? My perfect solution allows for both the propagation back to the Spring-WS endpoint as well to the error channel. That way I can use the error channel for auditing purposes and still let the WS caller know that something bad happened during his service invocation.
    Last edited by kurron; Oct 14th, 2008, 05:45 PM. Reason: Title wasn't completely accurate

  • #2
    A solution would be to use direct channels. This resolves the problem of not being in the correct call stack, but robs you of the advantages of asynchronous messaging at the same time. It seems that is what you want and it is even the default in the latest HEAD.

    Comment


    • #3
      So, if I understand you correctly, your suggestion is to couple my custom error handler with endpoints that are accessed via direct channels. The direct channel would ensure that the caller and endpoint run on the same thread, allowing the exchange of the exception to work via the thread local. I'll give that a try. Thanks.


      Originally posted by iwein View Post
      A solution would be to use direct channels. This resolves the problem of not being in the correct call stack, but robs you of the advantages of asynchronous messaging at the same time. It seems that is what you want and it is even the default in the latest HEAD.

      Comment


      • #4
        You may also be interested in this issue: http://jira.springframework.org/browse/INT-301

        That is in progress and should be included in RC1.

        Comment

        Working...
        X