Results 1 to 4 of 4

Thread: Web Service Hosting & Exception Propogation

  1. #1
    Join Date
    Mar 2008
    Posts
    11

    Default Web Service Hosting & SI Exception Propagation

    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 at 04:45 PM. Reason: Title wasn't completely accurate

  2. #2
    Join Date
    May 2007
    Location
    Netherlands
    Posts
    614

    Default

    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.

  3. #3
    Join Date
    Mar 2008
    Posts
    11

    Default

    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.


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

  4. #4
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,844

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •