[SWS-850] NoEndpointFoundException swallowed by WebServiceMessageReceiverObjectSupport Created: 26/Sep/13  Updated: 20/Mar/14  Resolved: 03/Feb/14

Status: Resolved
Project: Spring Web Services
Component/s: Core
Affects Version/s: 2.1.3
Fix Version/s: 2.2.RC1

Type: Bug Priority: Minor
Reporter: Jarkko Rantavuori Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Most HTTP level exceptions, such as XML parsing issues, can be handled by writing a custom WebServiceMessageHandlerAdapter that converts them to, for example, SOAP faults. However, NoEndpointFoundException is swallowed by WebServiceMessageReceiverObjectSupport class so that it is not thrown:

catch (NoEndpointFoundException ex) {
if (connection instanceof EndpointAwareWebServiceConnection)

{ ((EndpointAwareWebServiceConnection) connection).endpointNotFound(); }


this is in final method handleConnection(), so it cannot be overridden either. Instead, a handle adapter must re-implement this whole method if NoEndpointFoundException is wanted to be converted to SOAP Fault. Either the exception should be re-thrown or there needs to be an extension point.

Comment by Jarkko Rantavuori [ 26/Sep/13 ]

looks like a simple add of throw at the end of 'catch' would fix this:

        catch (NoEndpointFoundException ex) {
            if (connection instanceof EndpointAwareWebServiceConnection) {
                ((EndpointAwareWebServiceConnection) connection).endpointNotFound();
            throw ex;
Comment by Arjen Poutsma [ 03/Feb/14 ]

I'm afraid that rethrowing the exception is not an option, as that would break a lot of transports. The NoEndpointFoundException is meant to be dealt with by the transport.

That said, I've refactored the code so that the handling of the exception is now in a template method (WebServiceMessageReceiverObjectSupport#handleNoEndpointFoundException), which you can override in your subclass.

Generated at Fri Oct 19 05:50:38 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.