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:[EMAIL PROTECTED] > Sent: 11 July 2007 23:10 > To: [email protected] > 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 <[EMAIL PROTECTED]> 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
