What about: C) The outMessage/outgoing chain gets created once we know we have an output message?
Otherwise I would prefer B. - Dan On 3/15/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
Hi Ajay, I also found it confusing having the OutgoingChainSetupInterceptor running in the PRE_LOGICAL phase. If the response has to be sent before this phase is entered (e.g. as a result of a JAX-WS protocol handler killing the dispatch), then the relevant interceptor has to take responsibility for setting up the outgoing chain anyway. The confusion is only deepened by the AbstractServerFactoryBean adding this interceptor to the normal *in* chain, but also the fault *out* chain. So it would seem more logical to either: A) set up the out-chain before even the first interceptor in the in-chain is traversed, e.g. in the ChainInitiationObserver.onMessage() B) leave to the POST_INVOKE phase as you suggest so that there is no confusion, i.e. so every in-interceptor knows it must take explicit responsibility for setting up the out-chain if it needs to send a 'premature' response. Contrast with the current scenario whereby the in-interceptor would only need to do the out-chain setup if it runs in a phase before PRE_LOGICAL, or even more error-prone if its in PRE_LOGICAL phase itself but doesn't call addAfter(OutgoingChainSetupInterceptor.class). Cheers, Eoghan > -----Original Message----- > From: Paibir, Ajay [mailto:[EMAIL PROTECTED] > Sent: 15 March 2007 15:35 > To: [email protected] > Subject: RE: Why is OutgoingChainSetupInterceptor in inbound chain ? > > > Dan > > If a inbound interceptor wants to change the flow from > inbound to outbound or operate on outbound message/chain then > it has to take explicit responsibility of setting up the > outbound message and chain. > Why do it before hand when it is not known if the outbound > message is normal repsonse or fault? > Also it is puzzling that out chain/message were created in > PRE_LOGICAL not as early as Protocol Phases or ChainObserver. > > The use case was to include only interceptor operating b/w > Phase.PRE_LOGICAL to Phase.INVOKE in inbound and on outbound > include interceptor from Phase.SETUP to Phase.POST_LOGICAL. > And my custom interceptor will setup the outbound chain in > POST_INVOKE phase. But what I observed was the outgoing chain > was already evaluated in the inbound side. > > Ajay > > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 15 March 2007 14:57 > To: [email protected] > Subject: Re: Why is OutgoingChainSetupInterceptor in inbound chain ? > > I think the point of puttoing the > outgoingchainsetupinterceptor early in the inbound chain is > to create an out message and outgoing chain asap. > This allows further interceptors to operate on that > message/chain if they wanted to. > > Whats your use case for changing it? > > - Dan > > On 3/15/07, Paibir, Ajay <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I noticed the OutgoingChainSetupInterceptor is part of the inbound > > interceptor chain operating in the PRE_LOGICAL phase. It does the > > following things > > a) Sets up the outbound message before even the message is > dispatched > > to the implementor. > > b) Copy Message properties from inbound to outbound message > > c) Sets up the outbound interceptor chain. > > d) Sets up outbound fault message. > > > > I think a) and c) are done in a eager manner and should be deferred > > further down the inbound chain or if possible to start of outbound > > chain. > > > > So i am proposing to move (a),(b) to > ServiceInvokeInterceptor and (c) > > > to OutgoingChainInterceptor which intiates the outbound > chain. Leave > > the > > (d) to the fault observer namely OutFaultChainInitiatorObserver. > > > > Thus eliminating OutgoingChainSetupInterceptor. > > > > Any suggestions, comments? I volunteer to do the changes if > it makes > > sense. > > > > Regards > > Ajay > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
