As it turns out, the solution is to use a JAX-RPC-style handler,
implementing import javax.xml.rpc.handler.Handler. In this interface, the
handleRequest method returns a boolean value indicating whether processing
should continue. For this to be handled correctly, though, you must declare
the handler using the handlerInfoChain syntax:
<service name="EchoService" provider="java:RPC">
<parameter name="className" value="jrh.EchoService"/>
<parameter name="allowedMethods" value="*"/>
<handlerInfoChain>
<handlerInfo classname="jrh.EchoJAXHandler"/>
</handlerInfoChain>
</service>
It is possible to use the same requestFlow syntax as for Axis-style
handlers, but if you do, the return value will be ignored.
Vance
----- Original Message -----
From: "Vance Maverick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 23, 2003 2:47 PM
Subject: Can Handler in requestFlow act as pivot?
> I'd like to create a Handler in the global requestFlow which is capable,
in
> certain circumstances, of acting as the pivot handler. Generally
speaking,
> the response would be generated by the service object, in the ordinary
way:
> but sometimes, this Handler would decide to supply the response itself.
In
> this case, the service object should *not* be invoked. (To avoid
redundant
> computation.)
>
> I tried the naive expedient of setting the pastPivot property in the
> MessageContext, but this didn't quite work. The Handler was able to set a
> Response object, which was indeed propagated back to the client -- but the
> service object was still invoked.
>
> Richard Zhu asked essentially the same question a month ago (see
> http://marc.theaimsgroup.com/?l=axis-user&m=106434049304967&w=2), 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.)
>
> 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....but
that's
> a discussion for the developer list.
>
> Vance
>
>
