axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chaddad" <>
Subject Re: Can Handler in requestFlow act as pivot?
Date Mon, 27 Oct 2003 18:20:36 GMT
Hi vance - 

Axis will need to be enhanced to provide the ability to bail out of the request processing

The correct processing model to use is defined in section 12.1.1 Handlers of the JAX-RPC 1.1

rather than changing the method signature of the Axis handler interface, maybe setting a flag
in the global context would suffice.  The doVisiting method of SimpleChain would pick up the
bail-out condition.

Everyplace that calls .invoke on the dispatcher would have to be modified as well so that
the target service endpoint is not invoked. Classes to modify include / and


---------- Original Message ----------------------------------
From: "Vance Maverick" <>
Date:  Mon, 27 Oct 2003 10:20:48 +0100

>[I originally posted this to axis-user, but I didn't get any response
>there.  It does lead to a development question, so it's not strictly
>I'd like to create a Handler in the global requestFlow (or something
>very much like it) which is capable, in certain circumstances, of
>acting as the pivot handler.  Usually, it would examine the request
>and do nothing, letting the request flow continue down to the service
>object in the ordinary way.  Sometimes, though, this Handler would
>decide to supply the response itself.  In that case, I want it to halt
>further processing of the request chain.  In particular, to avoid
>redundant computation, the service object should *not* be invoked if
>the Handler supplies a response.
>Is there something in the ordinary Handler API which permits this?  I
>tried setting the pastPivot property in the MessageContext, but that
>didn't do it.  The service object was still invoked.  (Curiously, the
>ultimate response was the one created by my Handler, not the one from 
>the service object.)
>Finally, if this behavior is not currently available, would it be
>considered compatible with the overall architecture?  If so, I would
>certainly be glad to undertake the work of developing it in the
>appropriate way.
>    Vance
>PS.  Richard Zhu asked essentially the same question a month ago (see
>, but
>the thread trailed off inconclusively.  The only suggestion was to
>provide this behavior at the servlet-engine level (as a filter), which
>would be a burden in our case.  (It would mean that, in order to
>reason about specifics of the service or request, the filter would
>have to do its own SOAP parsing.)

View raw message