Hi Sreekant,
Sure. The spec. says "In the default processing model,
the respose handler chain starts processing from the same
Handler instance (that returned false) and goes backward
in the execution sequence".
However, please pay attention to one key word, "default"
in the above sentence. I mean that the behavior should be
configurable, and the spec highly recommend the setting
to the runtime (AXIS) for the initial value; i.e. default.
In my personal point of view, your patch is one of hard-
coded architecture. So, there is no way for an implementer
to change the starting point of response flow, and it won't
be welcomed.
As my "transitional" solution, I controll the sequence
in each handler implementations by using MessageContext.
The following is the sample of jax-rpc handler impl.;
-- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> --
public boolean handleRequest(
javax.xml.rpc.handler.MessageContext context) {
// **** if you want to return false ****:
// set the class name of the handler implementation:
context.setProperty("HandlerFault", this.getClass().getName());
return false;
}
public boolean handleResponse(
javax.xml.rpc.handler.MessageContext context) {
// get the state (class name was set or not) from MsgCtx:
String name = (String)context.getProperty("HandlerFault");
// if the handleRequest of this instance returned "false":
if (name != null && name instanceof String
&& name.equals(this.getClass().getName())) {
// create a response message:
:
:
} else {
:
:
}
return true;
}
-- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> --
Best Regards,
Toshiyuki Kimura <[EMAIL PROTECTED]>
R&D Headquarters
NTT DATA Corporation
-----Original Message-----
From: Sreekant Thirunagari [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 25, 2003 7:45 AM
To: [EMAIL PROTECTED]
Subject: Re: Handler chain implementation
Hi Toshiyuki Kimura,
About the bug (15478) you filed on handler chain impl..
In the fix you presented it will avoid the target end point
invocation but the response chain is starts from the beginning
as configured. According to jax-rpc spec the default processing
model should start from the same handler that returned false
and goes backward. It is similar with handleFault method also...
the response chain starts from the handler that throws SOAPFault
and goes back.
I want to suggest a small change in org.apache.axis.handlers.
HandlerChainImpl class to maintain an index of last handler
invoked into handlerInfo list and in case of blocked flow it can
use this index to traverse back.. the change would be ..
introduce the index variable, set it in handleRequest and use it
in handleResponse, handleFault. In case of normal processing it
would traverse entire list and in case of blocked flow it would
traverse back from the point of block.
protected int lastHandlerIndex = 0;
public boolean handleRequest(MessageContext _context) {
SOAPMessageContext context = (SOAPMessageContext) _context;
boolean processFault = false;
for (int i = 0; i < size(); i++) {
Handler currentHandler = getHandlerInstance(i);
lastHandlerIndex = i;
.
.
}
}
public boolean handleResponse(MessageContext context) {
//for (int i = size() - 1; i >= 0; i--){
for (int i = lastHandlerIndex; i >= 0; i--){
Handler currentHandler = getHandlerInstance(i);
.
.
}
Please let me know your commnets.
Regards,
Sreekant
Sreekant Thirunagari wrote:
Thanks Kimura. I was contemplating to file a bug on this,
but wanted to confirm with the group first. Now that the thing is
filed can we push anyone to fix it? I think the fix you proposed
should solve the problem.
I have one more question abt pivot handler. I tried to replace
pivot handler(provider) with jax-rpc handler but it fails.. it
gives me an error at
--> org.apache.axis.deployment.wsdd.providers.WSDDHandlerProvider.
newProviderInstance(WSDDHandlerProvider.java:91)
because it has the following check
if (!(Handler.class.isAssignableFrom(_class))) {
throw new ConfigurationException(Messages.getMessage(
"badHandlerClass00", _class.getName()));
}
This makes it clear that the pivot handler should implement
axis handler interface. I couldn't find anything specific abt
pivot handler in jax-rpc spec. Only that it says request handler
chain is invoked before dispatching RPC request to target service
endpoint implementation. Does the pivot handler fall into the
JAX-RPC runtime system(AXIS) specific implemenation to dispatch
the RPC call and doesn't need to follow the jax-rpc handler
interface??
Regards,
Sreekant
Toshiyuki Kimura wrote:
> Hi Sreekant,
>
> You're right. AXIS has a problem on JAX-RPC handler impl.
> Please see attached. I think RC1 also doesn't cover it yet.
> I reported it as "Major bug", but it seems that the bug isn't
> a high priority problem on the list of active bugs.
>
> Best Regards,
>
> Toshiyuki Kimura <[EMAIL PROTECTED]>
> R&D Headquarters
> NTT DATA Corporation
>
> -----Original Message-----
> From: Sreekant Thirunagari [mailto:[EMAIL PROTECTED]
> Sent: Saturday, February 22, 2003 3:50 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Handler chain implementation
>
> Thanks for the response Ricky. I haven't tried throwing an exception, but
i
> guess then it would go into handleFault not handleResponse. I have looked
at
> your earlier posting "Handler Chain Limitations". According to jax-rpc
spec
> handlers return boolean response to chain invoker indicating the success
or
> failure of handler invocation unlike the AXIS implementation where it is
> void
> invoke(..) and the only way to get output from invoke is to throw
exception.
> Does this mean that AXIS doesn't follow JAX-RPC spec on handler chains? I
> have a situation where i have to stick to jax-rpc interfaces and jax-rpc
> does
> provide control over handler chain flow which is an elegant way of
handling
> the scenario instead of throwing an exception
>
> Regards,
> Sreekant
>
> Ricky Ho wrote:
>
> > Few months ago, I run into the same issue when I try to implement a
cache
> > handler. The answer I got back from Steve is the only way to stop the
> > handler passing on the request is to throw an exception, in that case a
> > SOAP Fault is send back to client.
> >
> > I guess this behavior is still the same now.
> >
> > Rgds, Ricky
> >
> > At 10:40 AM 2/21/2003 -0500, Sreekant Thirunagari wrote:
> > >Hi all,
> > > I started studying axis recently and have done some work on it.
I
> > >am having problems with handler chain management. According to my
> > >understanding of the jax-rpc spec we can block the handler chain flow
at
> > >
> > >any point and return from that point provided that the appropriate
> > >SoapMessageContext is provided. The runtime system should be
responsible
> > >
> > >for invoking the response handlers.
> > > My problem is i have a chain of handlers and i need to block the
> > >request flow at runtime on certain conditions evaluated in
handleRequest
> > >
> > >method. Correct me if i am wrong.. according to my understanding if you
> > >return a false from handleRequest request handler chain is blocked and
> > >target service endpoint should not be invoked.. and response handler
> > >chain should start processing (should it start from the same handler
> > >that returned false???). I see that axis does return from request
> > >handler chain but it still invokes the target service endpoint and
> > >starts the response chain as configured. Can any one please explain me
> > >is this the expected behaviour, did i miss anything or is it a problem
> > >with axis handler chain implementation.
> > >
> > >Regards,
> > >Sreekant
