cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Issue with the MultipleEndpointObserver
Date Thu, 12 Jul 2007 08:39:01 GMT


OK, yeah I see the point about not even knowing that we've received a
valid SOAP message, so I guess it may not even make sense to respond
with a SOAP fault.

Reminds me of some WCF behaviour that seemed odd to me when I saw it
first ... for certain error scenarios, WCF just throws up its hands and
responds with a HTTP 400 containing a snippet of HTML in the payload
(e.g. "<h1>Bad Request (Invalid Header Name)</h1>"). Sortta implying
that HTML is like a canonical format to fallback on when the intended
MEP protocol isn't clear.

/Eoghan

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 11 July 2007 23:10
> To: cxf-dev@incubator.apache.org
> Subject: Re: Issue with the MultipleEndpointObserver
> 
> 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).
> 
> Thoughts?
> - Dan
> 
> On 7/11/07, Glynn, Eoghan <eoghan.glynn@iona.com> 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
> http://envoisolutions.com | http://netzooid.com/blog
> 

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message