axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: [Axis2] Proposal: Extending the handler invocation pattern
Date Fri, 14 Apr 2006 19:13:19 GMT

There are 4 types of flows in Axis2. Have u run into all of them yet?
a module can add handlers in whichever flows it wants to work with.
(As you already know all the data that needs to be shared is in the
context hierarchy.) FWIW, During the various F2F meetings we
speficially walked through WS-RM and WS-Security secnarios...

    * InFlow
    * OutFlow
    * InFaultFlow
    * OutFaultFlow


On 4/14/06, Bill Nagy <> wrote:
> Hi folks,
> I would like to extend the handler invocation pattern (i.e. the points
> at which a particular handler is called to process a given message) so
> that handlers are invoked after the processing of a message has
> finished.  (This would include both termination due to successful
> processing as well as the cases when a fault has caused processing to be
> cut short.)
> Currently, assuming that my understanding of the code is correct,
> handlers are invoked exactly one time during the processing of each
> message.  This is insufficient in cases where the handler/QoS needs to
> perform work after the operation has completed, e.g. if a security
> handler needs to remove context that was attached to the thread during
> execution or if a transaction handler needs to commit a transaction that
> it initiated.  While there are hacks that work around these issues under
> some circumstances, e.g. placing the handlers in an outbound chain, they
> are just that, hacks that only work under certain circumstances.  (They
> won't work, for instance, for one-way operations.)
> I realize that this is a non-trivial change (among other things, it
> involves altering the call path through the runtime as well as
> maintaining extra state about what work has already occurred,) but
> believe that it is the only workable solution.
> I would propose adding a single method to the Handler interface,
> flowComplete(MessageContext messageContext), that would be invoked for
> each handler that had had its invoke(...) method called during the
> processing of the message (with the exception that if a handler threw an
> exception during its execution, its flowComplete(...) method would not
> be called.)  The flowComplete(...) method for each handler would be
> called in the reverse order in which the invoke(...) method was called.
> For example, a flow may look like: securityHandler.invoke(...),
> rmHandler.invoke(...), process message, rmHandler.flowComplete(...),
> securityHandler.flowComplete(...).  If the rmHandler threw an exception
> within its invoke(...) method, then the flow would look like:
> securityHandler.invoke(...), rmHandler.invoke(...),
> securityHandler.flowComplete(...).  (If the flowComplete(...) method
> throws an exception, the rest of the handlers must still have their
> flowComplete(...) methods invoked.)
> Comments/questions?
> -Bill

Davanum Srinivas :

View raw message