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,
SreekantToshiyuki 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
>
> ------------------------------------------------------------------------
> Name: Re_ Stopping the process of invocation by a Handler.eml
> Re_ Stopping the process of invocation by a Handler.eml Type: Internet E-Mail Message (message/rfc822)
> Encoding: 7bit
