cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: Issue with the MultipleEndpointObserver
Date Wed, 11 Jul 2007 22:10:25 GMT
Good catch Eoghan.

So I guess my philosophy is this. If we throw a fault before we decide on
the service - which will typically be just after we read the headers, we're
pretty screwed anyway. The incoming message may not have even been a valid
soap message. Given the realm of possible exceptions, there was probably an
IO error. So what we should do there is kind of undefined. T

Maybe we should have some type of default faultobserver for when no service
has been found which simply constructs a fault message and sends it on the
back channel (if there is one).

- Dan

On 7/11/07, Glynn, Eoghan <> wrote:
> Folks,
> We've run into a issue whereby a fault thrown from an implementor is
> just being dropped on the floor, and an empty HTTP response returned to
> the client.
> After digging into it, it turns out that the problem is in the
> MultipleEndpointObserver. Unlike the single-endpoint
> ChainInitiationObserver, the MEO does not call setFaultObserver() on the
> in-interceptor-chain. As a result, predictably, when an exception is
> thrown from any interceptor in the in-chain, there's no fault observer
> available to dispatch a fault response, so the fault is just lost.
> In my case, the fault-throwing interceptor is the
> ServiceInvokerInterceptor, but I guess the same issue would impact on
> any other interceptor in the server-side in-chain.
> I guess the reason for this over-sight is that within MOE.onMessage()
> its not yet clear which of the multiple endpoints maintained by the MOE
> should provide the fault observer to set on the in-chain.
> The obvious fix is to call setFaultObserver() on the
> in-interceptor-chain in
> AbstractEndpointSelectionInterceptor.handleMessage(). However, my
> concern is that there's still a window into the dispatch before the
> endpoint selector interceptor is traversed ... e.g. the
> AttachmentInInterceptor, StaxInInterceptor, ReadHeadersInterceptor ...
> So rather than closing off a big gaping hole, I've just tightened it up
> to a small non-gaping hole :)
> Thoughts?
> /Eoghan
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message