You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Liu, Jervis" <jl...@iona.com> on 2007/01/22 08:15:53 UTC
Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Hi, I would like to summarize what we have been discussed in this thread (including Eoghan's proposal posted last Oct [1]) regarding Interceptor API changes. Any comments would be appreciated.
Currently our Interceptor APIs look like below:
public interface Interceptor<T extends Message> {
void handleMessage(T message) throws Fault;
void handleFault(T message);
}
Also in the interceptor chain, we have a notion of sub-chain or interceptor chain reentrance by calling message.getInterceptorChain().doIntercept(message) or message.getInterceptorChain().doInterceptInSubChain(message).
The main issues we have with the current implementation are:
1. Fault handling. See Eoghag's email [1]
2. Sub-chain reentrance. See previous discussion in this thread.
We propose to change Interceptor API as below:
public interface Interceptor<T extends Message> {
void handleMessage(T message) throws Fault;
void handleFault(T message);
void close(T message);
}
handleFault(T message) method is used to process fault message (which is done by handleMessage() in fault-chain currently).
close(T message) method is called on a reverse direction at the end of interceptor chain or when a fault or exception occurs. Take the fault handling case as an example, below is how handleFault and close work together
when a fault occurs on the in-chain, we unwind the current chain by calling close() on each previously traversed interceptor and then jump to the out-fault-chain, calling handleFault() on each interceptor with the fault message.
Close method is also used to remove the sub-chain reentrance. See the SOAPHandlerInterceptor example I posted previously.
Cheers,
Jervis
[1] http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e
________________________________
From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
Sent: Fri 1/19/2007 6:41 PM
To: cxf-dev@incubator.apache.org
Subject: RE: When should we close the handlers in CXF?
> -----Original Message-----
> From: Liu, Jervis [mailto:jliu@iona.com]
> Sent: 19 January 2007 07:34
> To: cxf-dev@incubator.apache.org; cxf-dev@incubator.apache.org
> Subject: RE: When should we close the handlers in CXF?
>
> Hi,
>
> Did we have any previous discussions on why we wont want a
> JAX-WS like APIs for interceptor chain?
Yes, I've brought this up a few times before, e.g. see point #4 in this
cxf-dev post [1] from Nov 10th last.
My problem with the CXF Interceptor.handleFault() method is that it
actually has semantics closer to the JAX-WS Handler.close(), and is
gratuitously different from the similarly-named Handler.handleFault()
method .
I've argued that is needlessly confusing for developers who use both the
CXF Interceptor and JAX-WS Handler APIs, and we should in fact model the
former on the latter.
> I.e., an Interceptor
> interface should look like below:
>
> public interface Interceptor<T extends Message> {
> void handleMessage(T message) throws Fault;
> void handleFault(T message);
> void close(T message);
> }
If we were to include *both* handleFault() and close() on Interceptor,
then the current Interceptor.handleFault() semantics would have to
change.
My proposal in the above referenced mail was to change handleFault()
semantics as follows:
"[currently] when a fault occurs on the in-chain, we unwind the current
chain by calling
handleFault() on each previously traversed interceptor and then jump to
the out-fault-chain,
calling handleMessage() on each interceptor with the fault message. I'd
propose changing this
to drop the unwind, instead call faultMessage() on each interceptor in
the out-fault-chain."
I suppose the unwind wouldn't be totally dropped, just achieved using
Interceptor.close() instead of handleFault().
> I see the possibility of removing subchains(interceptor chain
> re-entrance) from the interceptor chain by using close
> method. I am not saying sub-chain and the reentrance is that
> bad, but it does bring some confusion to understand the
> interceptor flow and it also brings unnecessary complexity
> such as handling exceptions thrown from a subchain and how to
> return back from subchain. Take the SOAPHandlerInterceptor as
> example, it looks like below now with a close method:
>
> private OutputStream oldStream;
> ......
> public void handleMessage(SoapMessage message) {
> if (getInvoker(message).getProtocolHandlers().isEmpty()) {
> return;
> }
> if (getInvoker(message).isOutbound()) {
> oldStream = message.getContent(OutputStream.class);
> CachedStream cs = new CachedStream();
> message.setContent(OutputStream.class, cs);
> } else {
> .....
> }
> }
>
> public void close(SoapMessage message) {
> if (getInvoker(message).isOutbound()) {
> super.handleMessage(message);
> try {
> CachedStream cs =
> (CachedStream)message.getContent(OutputStream.class);
> // Stream SOAPMessage back to output stream
> if necessary
> SOAPMessage soapMessage =
> message.getContent(SOAPMessage.class);
> if (soapMessage != null) {
> soapMessage.writeTo(oldStream);
> } else {
> cs.flush();
> AbstractCachedOutputStream csnew =
> (AbstractCachedOutputStream) message
> .getContent(OutputStream.class);
> AbstractCachedOutputStream.copyStream(csnew
> .getInputStream(), oldStream, 64 * 1024);
> cs.close();
> }
> oldStream.flush();
> message.setContent(OutputStream.class, oldStream);
> } catch (IOException ioe) {
> throw new SoapFault(new
> org.apache.cxf.common.i18n.Message(
> "SOAPHANDLERINTERCEPTOR_EXCEPTION",
> BUNDLE), ioe,
> message.getVersion().getSender());
> } catch (SOAPException soape) {
> throw new SoapFault(new
> org.apache.cxf.common.i18n.Message(
> "SOAPHANDLERINTERCEPTOR_EXCEPTION",
> BUNDLE), soape,
> message.getVersion().getSender());
> }
> }
> }
>
>
> We can do the same thing for MessageSenderInterceptor,
> StaxOutInteceptor and SoapOutInterceptor etc.
>
> Does this look good to everyone, any thoughts?
Just so I'm sure I understand correctly, are you proposing to use
close() to trigger a jump from the sub-chain back up to the main chain?
If so, where is this jump done currently?
Cheers,
Eoghan
[1]
http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/% <https://bosgate2.iona.com/http/0/mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%>
3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%
3e
> Cheers,
> Jervis
>
> ________________________________
>
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Thu 1/18/2007 9:55 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: When should we close the handlers in CXF?
>
>
>
> I think the registering of actions to be run at the end of
> the chain is good.
>
> Another possibility is to add a close(Message) method to the
> Interceptor which gets called at the end of the chain. If we
> did that I would think we might want to get rid of the
> handleFault method as cleanup could be done in close().
> (Eoghan - I'm actually suggesting we move closer to the
> JAX-WS APIs! ;-))
>
> Thoughts?
>
> - Dan
>
> On 1/18/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Unreal Jiang [mailto:sinbad_jia@yahoo.com]
> > > Sent: 18 January 2007 11:44
> > > To: cxf-dev@incubator.apache.org
> > > Subject: RE: When should we close the handlers in CXF?
> > >
> > > Hi Eoghan,
> > > I think those two approach are work fine.
> > >
> > > The first approach is only for handlers process,
> > > The second approach can do some clean-up works not only for
> > > handlers but interceptors, but if we use runnable object for
> > > TerminalAction, the order of handlers or interceptors
> will be hard
> > > to ensure.
> >
> > In most cases, a FIFO ordering of the terminal actions
> would be fine,
> > i.e. the order in which the terminal actions are executed would
> > reflect the order in which the interceptors were traversed. If you
> > needed more fine-grained control, maybe
> > InterceptorChain.addTerminalAction() could be replaced by
> something like ...
> >
> > interface InterceptorChain {
> > List<Runnbale> getTerminalActions(); }
> >
> > ... so that the code submitting the terminal action could control
> > ordering with respect to previously submitted terminal
> actions. Going
> > even further that this (e.g. something akin to the
> > PhaseInterceptor.getBefore/After() business) would I think
> be overkill
> > without a specific ordering-sensitive usecase.
> >
> > However, a closer look at the JAX-WS HandlerChainInvoker
> code suggests
> > that only one of the LogicalHandlerInterceptor and
> > SOAPHandlerInterceptor will actually need to submit a
> terminal action.
> > So with only a *single* terminal action concerned with closing
> > handlers, ordering shouldn't be an issue here.
> >
> > This is because the same HandlerChainInvoker instance is shared by
> > these two interceptors, and the code that calls
> handleMessage/Fault()
> > on the individual Handlers also adds each of these to a
> separate list
> > (closeHandlers) of handlers for which close() should be called.
> >
> > Only a single call to HandlerChainInvoker.mepComplete() is then
> > actually required to ensure that *all* the traversed handlers are
> > close()d in the correct order.
> >
> > So maybe the simplest approach would be be to submit the terminal
> > action in AbstractJAXWSHandlerInterceptor.getInvoker(), i.e.:
> >
> > protected HandlerChainInvoker getInvoker(final T message) {
> > HandlerChainInvoker invoker =
> > message.getExchange().get(HandlerChainInvoker.class);
> > if (null == invoker) {
> > invoker = new
> HandlerChainInvoker(binding.getHandlerChain(),
> > isOutbound(message));
> > message.getExchange().put(HandlerChainInvoker.class,
> > invoker);
> >
> > // submit a *single* terminal action for entire handler
> > chain
> > message.getInterceptorChain().addTerminalAction(new
> > Runnable() {
> > public void run() {
> > mepComplete(message);
> > }
> > }
> > }
> > //...
> > }
> >
> > Cheers,
> > Eoghan
> >
> > > So I incline to the second approach, but we should use
> some other
> > > way to instead of runnable object.
> > >
> > > Regards
> > > Unreal
> > >
> > > "Liu, Jervis" <jl...@iona.com> wrote:I would vote for the second
> > > approach. When its there, we can probably use the
> similiar approach
> > > to remove the sub-chain (interceptor chain
> > > reentrance) wherever it is possible.
> > >
> > > ________________________________
> > >
> > > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > > Sent: Wed 1/17/2007 9:42 PM
> > > To: cxf-dev@incubator.apache.org
> > > Subject: RE: When should we close the handlers in CXF?
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > > > Sent: 17 January 2007 12:34
> > > > To: cxf-dev@incubator.apache.org
> > > > Subject: RE: When should we close the handlers in CXF?
> > > >
> > > >
> > > > Hi Unreal,
> > > >
> > > > One point to note is that all the other JAX-WS Handler touch
> > > > points are driven through a set of interceptors, each wrapping a
> > > chain of a
> > > > particular Handler type (logical, protocol etc.).
> > > >
> > > > So for example the SOAPHanderInterceptor takes care of
> calling the
> > > > handleMessage/Fault() methods of any SOAPHandlers in the chain.
> > > > Similarly there's a *separate* LogicalHandlerInterceptor that
> > > > traverses the chain of LogicalHandlers. I'm guessing you
> > > already know
> > > > all this ...
> > > >
> > > > But the point is that it would be a good idea to maintain
> > > the pattern
> > > > of wrapper-interceptor calling out to JAX-WS Handler, and
> > > obviously it
> > > > would be badness to for example put this JAXWS-specific
> > > logic into the
> > > > ClientImpl code.
> > > >
> > > > However, because Handler.close() should only be called
> at the very
> > > > *end* of the interceptor chain tarversal, and because
> we currently
> > > > have
> > > > *multiple* interceptors wrapping the JAX-WS Handler chains
> > > of various
> > > > types, the close() call should not be made from within the
> > > > existing wrapper interceptors. Otherwise we'd end up with for
> > > example close()
> > > > called prematurely on the SOAPHandlers *before* the
> > > > LogicalHandlers have even been traversed (inbound on
> the client-side).
> > > >
> > > > So we'd need a *single* new wrapper interceptor, positioned
> > > at the end
> > > > of the in & fault-in interceptor chains, that's responsible for
> > > > calling
> > > > close() on all types of handler. This could be driven via a
> > > > pattern similar to the
> > > > LogicalHandlerInterceptor.onCompletion() method (e.g. the new
> > > > interceptor walks back along the chain to find the
> > > > LogicalHandlerInterceptor & SOAPHandlerInterceptor and calls
> > > > onCompletion() on these).
> > >
> > > On second thoughts, maybe a cleaner may of doing this
> would be allow
> > > an interceptor to register some sort of terminal action with the
> > > InterceptorChain to be executed when the chain traversal is
> > > complete, e.g.
> > >
> > > public interface InterceptorChain {
> > > void addTerminalAction(Runnable r);
> > >
> > > //...
> > > }
> > >
> > > Or alternatively take the Runnable as a return value from
> > > Interceptor.handleMessage/Fault().
> > >
> > > Then in the InterceptorChain impl, run all the
> > > TerminalAction(s) from a finally block, e.g.
> > >
> > > public class PhaseInterceptorChain {
> > > public boolean doIntercept(Message m) {
> > > try {
> > > while (interceptorIterator.hasNext()) {
> > > interceptorIterator.next().handleMessage(m);
> > > }
> > > } finally {
> > > for (Runnable r : terminalActions) {
> > > r.run();
> > > }
> > > }
> > > }
> > > }
> > >
> > > Then for example the
> > > LogicalHandlerInterceptor.handleMessage() would end with
> some logic
> > > like:
> > >
> > > if (isRequestor(message) && (isOneway(message) ||
> > > !isOutbound(message))) {
> > > message.getInterceptorChain().addTerminalAction(new
> Runnable() {
> > > public void run() {
> > > getInvoker(message).mepComplete(message);
> > > }
> > > }
> > > }
> > >
> > > Similarly for SOAPHandlerInterceptor etc.
> > >
> > > Cheers,
> > > Eoghan
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------
> > > Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone
> call rates.
> > >
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com <https://bosgate2.iona.com/http/0/envoisolutions.com>
> <https://bosgate2.iona.com/http/0/envoisolutions.com> |
> http://netzooid.com/blog <https://bosgate2.iona.com/http/0/netzooid.com/blog>
> <https://bosgate2.iona.com/http/0/netzooid.com/blog>
>
>
>
Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should
we close the handlers in CXF?
Posted by Polar Humenn <ph...@iona.com>.
I'm still trying to find out how this interceptor stuff works. So
forgive me if I seem naive. :-[
You say CXF interceptors are stateless. Are you saying that
"statelessness" is a requirement to be a CXF interceptor? Or are you
saying that the processing interceptors that are currently used in CXF
are stateless and that's all that need to be supported?
I can definitely see a use case for CXF interceptors maintaining state.
A simple one is an outbound message counter. The interceptor increments
a counter on handleMessage() assuming the message makes out the end (has
no way of knowing). So the interceptor must decrement its counter on
handleFault() because that tells the interceptor that the message never
made it out the end because of some interceptor downstream in the chain.
So, if I have this right, what you are proposing is to alter the
semantics, and only call this onFinish() method on the unwind chain when
the message makes finally makes it out the end of the chain.
This changes the semantics quite a bit. With the handleFault approach
one can assume that the message will be successful in negotiating the
chain *unless* it is told otherwise, (handleFault), which leads to
optimistic processing. The latter onFinish() approach requires me to
*wait* to see *if* the message was successful, which is a pessimistic,
possibly more expensive approach.
It seems to me, that "fault" processing is the exceptional case, and one
should be able to assume optimistic processing, unless told otherwise.
Thoughts?
The other thing I don't get, is what constitutes an Inbound Fault
Message as opposed to an Inbound Message? Why does this make a
difference in Interceptors of inbound and outbound messages?
Cheers,
-Polar
Dan Diephouse wrote:
> Could I offer just once suggestion? Could we rename the
> postHandleMessage to
> onFinish(Message) or onComplete(Message)?
>
> - Dan
>
> On 2/6/07, Unreal Jiang <si...@yahoo.com> wrote:
>>
>> Hi,
>>
>> Looks like there has no opponent for jervis' proposal, I will
>> create a
>> jira task for this proposal and sign it me.
>>
>> Cheers
>> Unreal
>>
>> "Liu, Jervis" <jl...@iona.com> wrote:
>>
>> ________________________________
>>
>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> Sent: Tue 1/23/2007 1:02 AM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When
>> should we close the handlers in CXF?
>>
>>
>>
>> On 1/22/07, Liu, Jervis wrote:
>> >
>> > Hi, I would like to summarize what we have been discussed in this
>> thread
>> > (including Eoghan's proposal posted last Oct [1]) regarding
>> Interceptor
>> API
>> > changes. Any comments would be appreciated.
>> >
>> > Currently our Interceptor APIs look like below:
>> >
>> > public interface Interceptor {
>> > void handleMessage(T message) throws Fault;
>> > void handleFault(T message);
>> > }
>> >
>> > Also in the interceptor chain, we have a notion of sub-chain or
>> > interceptor chain reentrance by calling message.getInterceptorChain
>> ().doIntercept(message)
>> > or message.getInterceptorChain().doInterceptInSubChain(message).
>> >
>> > The main issues we have with the current implementation are:
>> >
>> > 1. Fault handling. See Eoghag's email [1]
>> >
>> > 2. Sub-chain reentrance. See previous discussion in this thread.
>> >
>> > We propose to change Interceptor API as below:
>> >
>> > public interface Interceptor {
>> > void handleMessage(T message) throws Fault;
>> > void handleFault(T message);
>> > void close(T message);
>> > }
>> >
>> > handleFault(T message) method is used to process fault message
>> (which is
>> > done by handleMessage() in fault-chain currently).
>>
>>
>> > I'm not sure I understand how you want to use this. I guess I could
>> see
>> two
>> > ways
>>
>> > 1. Remove In/OutFault interceptors and call handleFault on the In/Out
>> > interceptors. I don't know that mapping works especially well though.
>> > 2. Don't call handleFault on in/out interceptors, but only on the
>> > in/outFault interceptors - this would mean, for example, that the
>> logic
>> from
>> > Soap11OutFaultInterceptor would be moved from the handleMessage to
>> > handleFault.
>>
>> > Can you be more specific about what you mean?
>>
>>
>> Sorry, after rethinking about this, I've changed my mind slightly, so
>> here
>> is the idea:
>>
>> CXF Interceptor API will be similiar to JAX-WS API, section 9.3.2.1.
>>
>> Throw ProtocolException or a subclass This indicates that normal message
>> processing should cease.
>> Subsequent actions depend on whether the MEP in use requires a
>> response to
>> the message currently
>> being processed or not:
>>
>> Response: Normal message processing stops, fault message processing
>> starts. The message direction
>> is reversed, if the message is not already a fault message then it is
>> replaced with a fault message4,
>> and the runtime invokes handleFault on the next handler or dispatches
>> the
>> message (see
>> section 9.1.2.2) if there are no further handlers.
>>
>> No response: Normal message processing stops, close is called on each
>> previously invoked handler
>> in the chain, the exception is dispatched (see section 9.1.2.3).
>>
>>
>> Throw any other runtime exception This indicates that normal message
>> processing should cease. Subse-
>> quent actions depend on whether the MEP in use includes a response to
>> the
>> message currently being
>> processed or not:
>>
>> Response: Normal message processing stops, close is called on each
>> previously invoked handler in
>> the chain, the message direction is reversed, and the exception is
>> dispatched (see section 9.1.2.3).
>>
>>
>> No response: Normal message processing stops, close is called on each
>> previously invoked handler
>> in the chain, the exception is dispatched (see section 9.1.2.3).
>>
>> However, the difference is CXF interceptors are not designed to hook in
>> user logic as these JAX-WS handlers do, thus handleFault is not needed
>> in CXF interceptors (correct me if I am wrong, but I believe this is
>> the purpose that JAX-WS handlers's handleFault method designed for.
>> I.e, when
>> a known exception - ProtocolException occurs, handleFault() gives
>> handler
>> developer a hook to clean up sth, for example, roll back a transaction,
>> this is different from what close() is supposed to do. The latter is
>> designed to clean things up under a succeeded situation). For any
>> Runtime
>> exceptions thrown by interceptors, we just wrap it as soap exception
>> then
>> dispatch it back calling handleMessage.
>>
>> So here is the change we need to make:
>>
>> 1. Add a postHandleMessage() into Interceptor interface
>>
>> 2. Remove handleFault() method from Interceptor interface. Or we can
>> still keep it for a while until we are absolutely sure we wont need
>> this method, but I presume there is nothing we need to do in this
>> method.
>>
>> 3. We will NOT add a close() method into Interceptor interface, as
>> CXF interceptors are stateless, there is no resources need to be
>> closed.
>>
>> public interface Interceptor {
>> void handleMessage(T message) throws Fault;
>> void postHandleMessage(T message);
>> }
>>
>> When an interceptor chain ends normally, we need to call
>> postHandleMessage() on each previously traversed interceptor in a
>> reversed
>> direction.
>>
>> When a fault occurs on the in-bound chain, an exception will be thrown
>> from the interceptor, after catching the exception in
>> PhaseInterceptorChain, we unwind the current chain by calling
>> postHandleMessage() on each previously traversed interceptor and
>> then jump
>> to the out-fault-chain, calling handleMessage() on each interceptor
>> with
>> the fault message.
>>
>> Any thoughs?
>>
>>
>>
>>
>> > close(T message) method is called on a reverse direction at the end of
>> > interceptor chain or when a fault or exception occurs. Take the fault
>> > handling case as an example, below is how handleFault and close work
>> > together
>>
>>
>> > +1 to close() - Although I think Eoghan has a good point about the
>> ordering
>> > not necessarily being the same. I think we need to do a little bit
>> more
>> > digging before we can know whether or not sub chains can be removed.
>>
>> > when a fault occurs on the in-chain, we unwind the current chain by
>> calling
>> > close() on each previously traversed interceptor and then jump to the
>> > out-fault-chain, calling handleFault() on each interceptor with the
>> fault
>> > message.
>> >
>> > Close method is also used to remove the sub-chain reentrance. See the
>> > SOAPHandlerInterceptor example I posted previously.
>> >
>> > Cheers,
>> > Jervis
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e
>>
>> >
>> >
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>>
>>
>>
>>
>> ---------------------------------
>> Access over 1 million songs - Yahoo! Music Unlimited.
>
>
>
>
Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Posted by Unreal Jiang <si...@yahoo.com>.
LogicalHandlerInterceptor already has a onCompletion() method to do some cleanup work. Maybe we can use it as the cleanup method name.
Unreal
Dan Diephouse <da...@envoisolutions.com> wrote: Could I offer just once suggestion? Could we rename the postHandleMessage to
onFinish(Message) or onComplete(Message)?
- Dan
On 2/6/07, Unreal Jiang wrote:
>
> Hi,
>
> Looks like there has no opponent for jervis' proposal, I will create a
> jira task for this proposal and sign it me.
>
> Cheers
> Unreal
>
> "Liu, Jervis" wrote:
>
> ________________________________
>
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Tue 1/23/2007 1:02 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When
> should we close the handlers in CXF?
>
>
>
> On 1/22/07, Liu, Jervis wrote:
> >
> > Hi, I would like to summarize what we have been discussed in this thread
> > (including Eoghan's proposal posted last Oct [1]) regarding Interceptor
> API
> > changes. Any comments would be appreciated.
> >
> > Currently our Interceptor APIs look like below:
> >
> > public interface Interceptor {
> > void handleMessage(T message) throws Fault;
> > void handleFault(T message);
> > }
> >
> > Also in the interceptor chain, we have a notion of sub-chain or
> > interceptor chain reentrance by calling message.getInterceptorChain
> ().doIntercept(message)
> > or message.getInterceptorChain().doInterceptInSubChain(message).
> >
> > The main issues we have with the current implementation are:
> >
> > 1. Fault handling. See Eoghag's email [1]
> >
> > 2. Sub-chain reentrance. See previous discussion in this thread.
> >
> > We propose to change Interceptor API as below:
> >
> > public interface Interceptor {
> > void handleMessage(T message) throws Fault;
> > void handleFault(T message);
> > void close(T message);
> > }
> >
> > handleFault(T message) method is used to process fault message (which is
> > done by handleMessage() in fault-chain currently).
>
>
> > I'm not sure I understand how you want to use this. I guess I could see
> two
> > ways
>
> > 1. Remove In/OutFault interceptors and call handleFault on the In/Out
> > interceptors. I don't know that mapping works especially well though.
> > 2. Don't call handleFault on in/out interceptors, but only on the
> > in/outFault interceptors - this would mean, for example, that the logic
> from
> > Soap11OutFaultInterceptor would be moved from the handleMessage to
> > handleFault.
>
> > Can you be more specific about what you mean?
>
>
> Sorry, after rethinking about this, I've changed my mind slightly, so here
> is the idea:
>
> CXF Interceptor API will be similiar to JAX-WS API, section 9.3.2.1.
>
> Throw ProtocolException or a subclass This indicates that normal message
> processing should cease.
> Subsequent actions depend on whether the MEP in use requires a response to
> the message currently
> being processed or not:
>
> Response: Normal message processing stops, fault message processing
> starts. The message direction
> is reversed, if the message is not already a fault message then it is
> replaced with a fault message4,
> and the runtime invokes handleFault on the next handler or dispatches the
> message (see
> section 9.1.2.2) if there are no further handlers.
>
> No response: Normal message processing stops, close is called on each
> previously invoked handler
> in the chain, the exception is dispatched (see section 9.1.2.3).
>
>
> Throw any other runtime exception This indicates that normal message
> processing should cease. Subse-
> quent actions depend on whether the MEP in use includes a response to the
> message currently being
> processed or not:
>
> Response: Normal message processing stops, close is called on each
> previously invoked handler in
> the chain, the message direction is reversed, and the exception is
> dispatched (see section 9.1.2.3).
>
>
> No response: Normal message processing stops, close is called on each
> previously invoked handler
> in the chain, the exception is dispatched (see section 9.1.2.3).
>
> However, the difference is CXF interceptors are not designed to hook in
> user logic as these JAX-WS handlers do, thus handleFault is not needed
> in CXF interceptors (correct me if I am wrong, but I believe this is
> the purpose that JAX-WS handlers's handleFault method designed for. I.e, when
> a known exception - ProtocolException occurs, handleFault() gives handler
> developer a hook to clean up sth, for example, roll back a transaction,
> this is different from what close() is supposed to do. The latter is
> designed to clean things up under a succeeded situation). For any Runtime
> exceptions thrown by interceptors, we just wrap it as soap exception then
> dispatch it back calling handleMessage.
>
> So here is the change we need to make:
>
> 1. Add a postHandleMessage() into Interceptor interface
>
> 2. Remove handleFault() method from Interceptor interface. Or we can
> still keep it for a while until we are absolutely sure we wont need
> this method, but I presume there is nothing we need to do in this method.
>
> 3. We will NOT add a close() method into Interceptor interface, as
> CXF interceptors are stateless, there is no resources need to be closed.
>
> public interface Interceptor {
> void handleMessage(T message) throws Fault;
> void postHandleMessage(T message);
> }
>
> When an interceptor chain ends normally, we need to call
> postHandleMessage() on each previously traversed interceptor in a reversed
> direction.
>
> When a fault occurs on the in-bound chain, an exception will be thrown
> from the interceptor, after catching the exception in
> PhaseInterceptorChain, we unwind the current chain by calling
> postHandleMessage() on each previously traversed interceptor and then jump
> to the out-fault-chain, calling handleMessage() on each interceptor with
> the fault message.
>
> Any thoughs?
>
>
>
>
> > close(T message) method is called on a reverse direction at the end of
> > interceptor chain or when a fault or exception occurs. Take the fault
> > handling case as an example, below is how handleFault and close work
> > together
>
>
> > +1 to close() - Although I think Eoghan has a good point about the
> ordering
> > not necessarily being the same. I think we need to do a little bit more
> > digging before we can know whether or not sub chains can be removed.
>
> > when a fault occurs on the in-chain, we unwind the current chain by
> calling
> > close() on each previously traversed interceptor and then jump to the
> > out-fault-chain, calling handleFault() on each interceptor with the
> fault
> > message.
> >
> > Close method is also used to remove the sub-chain reentrance. See the
> > SOAPHandlerInterceptor example I posted previously.
> >
> > Cheers,
> > Jervis
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e
> >
> >
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
>
>
>
>
> ---------------------------------
> Access over 1 million songs - Yahoo! Music Unlimited.
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
---------------------------------
8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.
Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Posted by Dan Diephouse <da...@envoisolutions.com>.
Could I offer just once suggestion? Could we rename the postHandleMessage to
onFinish(Message) or onComplete(Message)?
- Dan
On 2/6/07, Unreal Jiang <si...@yahoo.com> wrote:
>
> Hi,
>
> Looks like there has no opponent for jervis' proposal, I will create a
> jira task for this proposal and sign it me.
>
> Cheers
> Unreal
>
> "Liu, Jervis" <jl...@iona.com> wrote:
>
> ________________________________
>
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Tue 1/23/2007 1:02 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When
> should we close the handlers in CXF?
>
>
>
> On 1/22/07, Liu, Jervis wrote:
> >
> > Hi, I would like to summarize what we have been discussed in this thread
> > (including Eoghan's proposal posted last Oct [1]) regarding Interceptor
> API
> > changes. Any comments would be appreciated.
> >
> > Currently our Interceptor APIs look like below:
> >
> > public interface Interceptor {
> > void handleMessage(T message) throws Fault;
> > void handleFault(T message);
> > }
> >
> > Also in the interceptor chain, we have a notion of sub-chain or
> > interceptor chain reentrance by calling message.getInterceptorChain
> ().doIntercept(message)
> > or message.getInterceptorChain().doInterceptInSubChain(message).
> >
> > The main issues we have with the current implementation are:
> >
> > 1. Fault handling. See Eoghag's email [1]
> >
> > 2. Sub-chain reentrance. See previous discussion in this thread.
> >
> > We propose to change Interceptor API as below:
> >
> > public interface Interceptor {
> > void handleMessage(T message) throws Fault;
> > void handleFault(T message);
> > void close(T message);
> > }
> >
> > handleFault(T message) method is used to process fault message (which is
> > done by handleMessage() in fault-chain currently).
>
>
> > I'm not sure I understand how you want to use this. I guess I could see
> two
> > ways
>
> > 1. Remove In/OutFault interceptors and call handleFault on the In/Out
> > interceptors. I don't know that mapping works especially well though.
> > 2. Don't call handleFault on in/out interceptors, but only on the
> > in/outFault interceptors - this would mean, for example, that the logic
> from
> > Soap11OutFaultInterceptor would be moved from the handleMessage to
> > handleFault.
>
> > Can you be more specific about what you mean?
>
>
> Sorry, after rethinking about this, I've changed my mind slightly, so here
> is the idea:
>
> CXF Interceptor API will be similiar to JAX-WS API, section 9.3.2.1.
>
> Throw ProtocolException or a subclass This indicates that normal message
> processing should cease.
> Subsequent actions depend on whether the MEP in use requires a response to
> the message currently
> being processed or not:
>
> Response: Normal message processing stops, fault message processing
> starts. The message direction
> is reversed, if the message is not already a fault message then it is
> replaced with a fault message4,
> and the runtime invokes handleFault on the next handler or dispatches the
> message (see
> section 9.1.2.2) if there are no further handlers.
>
> No response: Normal message processing stops, close is called on each
> previously invoked handler
> in the chain, the exception is dispatched (see section 9.1.2.3).
>
>
> Throw any other runtime exception This indicates that normal message
> processing should cease. Subse-
> quent actions depend on whether the MEP in use includes a response to the
> message currently being
> processed or not:
>
> Response: Normal message processing stops, close is called on each
> previously invoked handler in
> the chain, the message direction is reversed, and the exception is
> dispatched (see section 9.1.2.3).
>
>
> No response: Normal message processing stops, close is called on each
> previously invoked handler
> in the chain, the exception is dispatched (see section 9.1.2.3).
>
> However, the difference is CXF interceptors are not designed to hook in
> user logic as these JAX-WS handlers do, thus handleFault is not needed
> in CXF interceptors (correct me if I am wrong, but I believe this is
> the purpose that JAX-WS handlers's handleFault method designed for. I.e, when
> a known exception - ProtocolException occurs, handleFault() gives handler
> developer a hook to clean up sth, for example, roll back a transaction,
> this is different from what close() is supposed to do. The latter is
> designed to clean things up under a succeeded situation). For any Runtime
> exceptions thrown by interceptors, we just wrap it as soap exception then
> dispatch it back calling handleMessage.
>
> So here is the change we need to make:
>
> 1. Add a postHandleMessage() into Interceptor interface
>
> 2. Remove handleFault() method from Interceptor interface. Or we can
> still keep it for a while until we are absolutely sure we wont need
> this method, but I presume there is nothing we need to do in this method.
>
> 3. We will NOT add a close() method into Interceptor interface, as
> CXF interceptors are stateless, there is no resources need to be closed.
>
> public interface Interceptor {
> void handleMessage(T message) throws Fault;
> void postHandleMessage(T message);
> }
>
> When an interceptor chain ends normally, we need to call
> postHandleMessage() on each previously traversed interceptor in a reversed
> direction.
>
> When a fault occurs on the in-bound chain, an exception will be thrown
> from the interceptor, after catching the exception in
> PhaseInterceptorChain, we unwind the current chain by calling
> postHandleMessage() on each previously traversed interceptor and then jump
> to the out-fault-chain, calling handleMessage() on each interceptor with
> the fault message.
>
> Any thoughs?
>
>
>
>
> > close(T message) method is called on a reverse direction at the end of
> > interceptor chain or when a fault or exception occurs. Take the fault
> > handling case as an example, below is how handleFault and close work
> > together
>
>
> > +1 to close() - Although I think Eoghan has a good point about the
> ordering
> > not necessarily being the same. I think we need to do a little bit more
> > digging before we can know whether or not sub chains can be removed.
>
> > when a fault occurs on the in-chain, we unwind the current chain by
> calling
> > close() on each previously traversed interceptor and then jump to the
> > out-fault-chain, calling handleFault() on each interceptor with the
> fault
> > message.
> >
> > Close method is also used to remove the sub-chain reentrance. See the
> > SOAPHandlerInterceptor example I posted previously.
> >
> > Cheers,
> > Jervis
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e
> >
> >
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
>
>
>
>
> ---------------------------------
> Access over 1 million songs - Yahoo! Music Unlimited.
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Posted by Unreal Jiang <si...@yahoo.com>.
Hi,
Looks like there has no opponent for jervis' proposal, I will create a jira task for this proposal and sign it me.
Cheers
Unreal
"Liu, Jervis" <jl...@iona.com> wrote:
________________________________
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Tue 1/23/2007 1:02 AM
To: cxf-dev@incubator.apache.org
Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
On 1/22/07, Liu, Jervis wrote:
>
> Hi, I would like to summarize what we have been discussed in this thread
> (including Eoghan's proposal posted last Oct [1]) regarding Interceptor API
> changes. Any comments would be appreciated.
>
> Currently our Interceptor APIs look like below:
>
> public interface Interceptor {
> void handleMessage(T message) throws Fault;
> void handleFault(T message);
> }
>
> Also in the interceptor chain, we have a notion of sub-chain or
> interceptor chain reentrance by calling message.getInterceptorChain().doIntercept(message)
> or message.getInterceptorChain().doInterceptInSubChain(message).
>
> The main issues we have with the current implementation are:
>
> 1. Fault handling. See Eoghag's email [1]
>
> 2. Sub-chain reentrance. See previous discussion in this thread.
>
> We propose to change Interceptor API as below:
>
> public interface Interceptor {
> void handleMessage(T message) throws Fault;
> void handleFault(T message);
> void close(T message);
> }
>
> handleFault(T message) method is used to process fault message (which is
> done by handleMessage() in fault-chain currently).
> I'm not sure I understand how you want to use this. I guess I could see two
> ways
> 1. Remove In/OutFault interceptors and call handleFault on the In/Out
> interceptors. I don't know that mapping works especially well though.
> 2. Don't call handleFault on in/out interceptors, but only on the
> in/outFault interceptors - this would mean, for example, that the logic from
> Soap11OutFaultInterceptor would be moved from the handleMessage to
> handleFault.
> Can you be more specific about what you mean?
Sorry, after rethinking about this, I've changed my mind slightly, so here is the idea:
CXF Interceptor API will be similiar to JAX-WS API, section 9.3.2.1.
Throw ProtocolException or a subclass This indicates that normal message processing should cease.
Subsequent actions depend on whether the MEP in use requires a response to the message currently
being processed or not:
Response: Normal message processing stops, fault message processing starts. The message direction
is reversed, if the message is not already a fault message then it is replaced with a fault message4,
and the runtime invokes handleFault on the next handler or dispatches the message (see
section 9.1.2.2) if there are no further handlers.
No response: Normal message processing stops, close is called on each previously invoked handler
in the chain, the exception is dispatched (see section 9.1.2.3).
Throw any other runtime exception This indicates that normal message processing should cease. Subse-
quent actions depend on whether the MEP in use includes a response to the message currently being
processed or not:
Response: Normal message processing stops, close is called on each previously invoked handler in
the chain, the message direction is reversed, and the exception is dispatched (see section 9.1.2.3).
No response: Normal message processing stops, close is called on each previously invoked handler
in the chain, the exception is dispatched (see section 9.1.2.3).
However, the difference is CXF interceptors are not designed to hook in user logic as these JAX-WS handlers do, thus handleFault is not needed in CXF interceptors (correct me if I am wrong, but I believe this is the purpose that JAX-WS handlers's handleFault method designed for. I.e, when a known exception - ProtocolException occurs, handleFault() gives handler developer a hook to clean up sth, for example, roll back a transaction, this is different from what close() is supposed to do. The latter is designed to clean things up under a succeeded situation). For any Runtime exceptions thrown by interceptors, we just wrap it as soap exception then dispatch it back calling handleMessage.
So here is the change we need to make:
1. Add a postHandleMessage() into Interceptor interface
2. Remove handleFault() method from Interceptor interface. Or we can still keep it for a while until we are absolutely sure we wont need this method, but I presume there is nothing we need to do in this method.
3. We will NOT add a close() method into Interceptor interface, as CXF interceptors are stateless, there is no resources need to be closed.
public interface Interceptor {
void handleMessage(T message) throws Fault;
void postHandleMessage(T message);
}
When an interceptor chain ends normally, we need to call postHandleMessage() on each previously traversed interceptor in a reversed direction.
When a fault occurs on the in-bound chain, an exception will be thrown from the interceptor, after catching the exception in PhaseInterceptorChain, we unwind the current chain by calling postHandleMessage() on each previously traversed interceptor and then jump to the out-fault-chain, calling handleMessage() on each interceptor with the fault message.
Any thoughs?
> close(T message) method is called on a reverse direction at the end of
> interceptor chain or when a fault or exception occurs. Take the fault
> handling case as an example, below is how handleFault and close work
> together
> +1 to close() - Although I think Eoghan has a good point about the ordering
> not necessarily being the same. I think we need to do a little bit more
> digging before we can know whether or not sub chains can be removed.
> when a fault occurs on the in-chain, we unwind the current chain by calling
> close() on each previously traversed interceptor and then jump to the
> out-fault-chain, calling handleFault() on each interceptor with the fault
> message.
>
> Close method is also used to remove the sub-chain reentrance. See the
> SOAPHandlerInterceptor example I posted previously.
>
> Cheers,
> Jervis
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
---------------------------------
Access over 1 million songs - Yahoo! Music Unlimited.
RE: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Posted by "Liu, Jervis" <jl...@iona.com>.
________________________________
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Tue 1/23/2007 1:02 AM
To: cxf-dev@incubator.apache.org
Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
On 1/22/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Hi, I would like to summarize what we have been discussed in this thread
> (including Eoghan's proposal posted last Oct [1]) regarding Interceptor API
> changes. Any comments would be appreciated.
>
> Currently our Interceptor APIs look like below:
>
> public interface Interceptor<T extends Message> {
> void handleMessage(T message) throws Fault;
> void handleFault(T message);
> }
>
> Also in the interceptor chain, we have a notion of sub-chain or
> interceptor chain reentrance by calling message.getInterceptorChain().doIntercept(message)
> or message.getInterceptorChain().doInterceptInSubChain(message).
>
> The main issues we have with the current implementation are:
>
> 1. Fault handling. See Eoghag's email [1]
>
> 2. Sub-chain reentrance. See previous discussion in this thread.
>
> We propose to change Interceptor API as below:
>
> public interface Interceptor<T extends Message> {
> void handleMessage(T message) throws Fault;
> void handleFault(T message);
> void close(T message);
> }
>
> handleFault(T message) method is used to process fault message (which is
> done by handleMessage() in fault-chain currently).
> I'm not sure I understand how you want to use this. I guess I could see two
> ways
> 1. Remove In/OutFault interceptors and call handleFault on the In/Out
> interceptors. I don't know that mapping works especially well though.
> 2. Don't call handleFault on in/out interceptors, but only on the
> in/outFault interceptors - this would mean, for example, that the logic from
> Soap11OutFaultInterceptor would be moved from the handleMessage to
> handleFault.
> Can you be more specific about what you mean?
Sorry, after rethinking about this, I've changed my mind slightly, so here is the idea:
CXF Interceptor API will be similiar to JAX-WS API, section 9.3.2.1.
Throw ProtocolException or a subclass This indicates that normal message processing should cease.
Subsequent actions depend on whether the MEP in use requires a response to the message currently
being processed or not:
Response: Normal message processing stops, fault message processing starts. The message direction
is reversed, if the message is not already a fault message then it is replaced with a fault message4,
and the runtime invokes handleFault on the next handler or dispatches the message (see
section 9.1.2.2) if there are no further handlers.
No response: Normal message processing stops, close is called on each previously invoked handler
in the chain, the exception is dispatched (see section 9.1.2.3).
Throw any other runtime exception This indicates that normal message processing should cease. Subse-
quent actions depend on whether the MEP in use includes a response to the message currently being
processed or not:
Response: Normal message processing stops, close is called on each previously invoked handler in
the chain, the message direction is reversed, and the exception is dispatched (see section 9.1.2.3).
No response: Normal message processing stops, close is called on each previously invoked handler
in the chain, the exception is dispatched (see section 9.1.2.3).
However, the difference is CXF interceptors are not designed to hook in user logic as these JAX-WS handlers do, thus handleFault is not needed in CXF interceptors (correct me if I am wrong, but I believe this is the purpose that JAX-WS handlers's handleFault method designed for. I.e, when a known exception - ProtocolException occurs, handleFault() gives handler developer a hook to clean up sth, for example, roll back a transaction, this is different from what close() is supposed to do. The latter is designed to clean things up under a succeeded situation). For any Runtime exceptions thrown by interceptors, we just wrap it as soap exception then dispatch it back calling handleMessage.
So here is the change we need to make:
1. Add a postHandleMessage() into Interceptor interface
2. Remove handleFault() method from Interceptor interface. Or we can still keep it for a while until we are absolutely sure we wont need this method, but I presume there is nothing we need to do in this method.
3. We will NOT add a close() method into Interceptor interface, as CXF interceptors are stateless, there is no resources need to be closed.
public interface Interceptor<T extends Message> {
void handleMessage(T message) throws Fault;
void postHandleMessage(T message);
}
When an interceptor chain ends normally, we need to call postHandleMessage() on each previously traversed interceptor in a reversed direction.
When a fault occurs on the in-bound chain, an exception will be thrown from the interceptor, after catching the exception in PhaseInterceptorChain, we unwind the current chain by calling postHandleMessage() on each previously traversed interceptor and then jump to the out-fault-chain, calling handleMessage() on each interceptor with the fault message.
Any thoughs?
> close(T message) method is called on a reverse direction at the end of
> interceptor chain or when a fault or exception occurs. Take the fault
> handling case as an example, below is how handleFault and close work
> together
> +1 to close() - Although I think Eoghan has a good point about the ordering
> not necessarily being the same. I think we need to do a little bit more
> digging before we can know whether or not sub chains can be removed.
> when a fault occurs on the in-chain, we unwind the current chain by calling
> close() on each previously traversed interceptor and then jump to the
> out-fault-chain, calling handleFault() on each interceptor with the fault
> message.
>
> Close method is also used to remove the sub-chain reentrance. See the
> SOAPHandlerInterceptor example I posted previously.
>
> Cheers,
> Jervis
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e <https://bosgate2.iona.com/http/0/mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com <https://bosgate2.iona.com/http/0/envoisolutions.com> | http://netzooid.com/blog <https://bosgate2.iona.com/http/0/netzooid.com/blog>
Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 1/22/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Hi, I would like to summarize what we have been discussed in this thread
> (including Eoghan's proposal posted last Oct [1]) regarding Interceptor API
> changes. Any comments would be appreciated.
>
> Currently our Interceptor APIs look like below:
>
> public interface Interceptor<T extends Message> {
> void handleMessage(T message) throws Fault;
> void handleFault(T message);
> }
>
> Also in the interceptor chain, we have a notion of sub-chain or
> interceptor chain reentrance by calling message.getInterceptorChain().doIntercept(message)
> or message.getInterceptorChain().doInterceptInSubChain(message).
>
> The main issues we have with the current implementation are:
>
> 1. Fault handling. See Eoghag's email [1]
>
> 2. Sub-chain reentrance. See previous discussion in this thread.
>
> We propose to change Interceptor API as below:
>
> public interface Interceptor<T extends Message> {
> void handleMessage(T message) throws Fault;
> void handleFault(T message);
> void close(T message);
> }
>
> handleFault(T message) method is used to process fault message (which is
> done by handleMessage() in fault-chain currently).
I'm not sure I understand how you want to use this. I guess I could see two
ways
1. Remove In/OutFault interceptors and call handleFault on the In/Out
interceptors. I don't know that mapping works especially well though.
2. Don't call handleFault on in/out interceptors, but only on the
in/outFault interceptors - this would mean, for example, that the logic from
Soap11OutFaultInterceptor would be moved from the handleMessage to
handleFault.
Can you be more specific about what you mean?
close(T message) method is called on a reverse direction at the end of
> interceptor chain or when a fault or exception occurs. Take the fault
> handling case as an example, below is how handleFault and close work
> together
+1 to close() - Although I think Eoghan has a good point about the ordering
not necessarily being the same. I think we need to do a little bit more
digging before we can know whether or not sub chains can be removed.
when a fault occurs on the in-chain, we unwind the current chain by calling
> close() on each previously traversed interceptor and then jump to the
> out-fault-chain, calling handleFault() on each interceptor with the fault
> message.
>
> Close method is also used to remove the sub-chain reentrance. See the
> SOAPHandlerInterceptor example I posted previously.
>
> Cheers,
> Jervis
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog