Hi Sreekant,
Please let me correct by myself. ( Some arrows indicate
the wrong directions on the following diagrams.)
I think you don't need any apologies to me, or rather,
I'm delighted that you give me understanding for my opinion.
-- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> --
[Condition]: (*** Please see below with your fixed font ***)
- There're three jax-rpc handler impl; H1, H2, H3
- H1(req) indicates the handleRequest method of H1 instance
- H1(res) indicates the handleResponse method of H1 instance
- The items mentioned above for H1 are same as H2, H3
[*] === Normal sequence ===: JAX-RPC handler Processing Model
[H1(req)]-->[H2(req)]-->[H3(req)]-->[deserializer]---+
|
V
[Eend-point]
|
V
[H1(res)]<--[H2(res)]<--[H3(res)]<--[ serializer ]---+
[*] === Error sequence ===: H2(req) returned "false"
[H1(req)]-->[H2(req)]--(4)-+
| |
<--(1)-----------| |
|(2) |(3) |
V V V
[H1(res)]<--[H2(res)]<--[H3(res)]
(1): H2(req) generates a response msg and the runtime
directly sends back it to the client
*** Currently, I'm not sure this path is needed ***
(2): H1(res) generates a response msg, and after that
the runtime sends back it to the client
(3): H2(res) generates a response msg, and the runtime
invokes the next handler ( handleResponse of H1 )
*** The spec says "It should be the default". ***
(4): H3(res) generates a response msg, and the runtime
invokes the next handler ( handleResponse of H2 )
-- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> --
The default sequence (3) should be handled by the runtime,
but the other cases (1),(2),(4) should be controllable by
the implementer who wants to do customizing, I believe.
In your patch, the runtime can choose the sequence (3)
as "fixed" rule, but there is no way for the implementer
to select sequence (1),(2),(4).
And also, in my "transitional" solution, all handleResponse
methods will be invoked by the runtime as you say, but if the
implementer don't want to do processing at the invoked method
(handleResponse on the handler instance), he will be able to
skip (i.e. control the sequence) by the following logic:
| 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())) {
| // do processing
| } else {
| // don't processing
| }
Please note that the above code is still a sample code.
If you strictly want to follow the spec, we have to define
the additional API as "de-facto" or "spec" and then contribute
it for AXIS.
Best Regards,
Toshiyuki Kimura <[EMAIL PROTECTED]>
R&D Headquarters
NTT DATA Corporation
-----Original Message-----
From: Sreekant Thirunagari [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 9:59 AM
To: [EMAIL PROTECTED]
Subject: Re: Handler chain implementation
Hi Toshiyuki Kimura,
I am sorry i didn't pay attention to complete bug report you pasted.
Yes i agree, mine was just a hard coded intermittent solution.
Correct me if i am wrong, i see that the handler fix you gave sets
a handler class that would generate the response message. despite
of this setting all the handlers in the chain are invoked and it is
left to handler implementer to how the situation is handled. Isn't
it the resposibilty of the runtime system(AXIS) to take care of
what to invoke? this is the reason why i wanted to suggest a change
in HandlerChainImpl class.
Here are few things to be resolved -
1) default - start from the handler that returned false and
go back in chain. how to remember the last handler?
2) what are other non-deafult flows that can be allowed?
- a choice to specify where in the chain processing should start.
- just direct it to a single handler that can generate response
msg and exit from the chain
3) how can user configure the system (deafult or customized)?
Regards,
Sreekant
Toshiyuki Kimura wrote:
> 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
