You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Guillaume Sauthier <Gu...@objectweb.org> on 2004/11/29 15:55:41 UTC

Incorrect support of JaxRpc Handler LifeCycle/Flow ?

Hi all,

I have a simple Client that uses JaxRpc Handler and I found that init 
and destroy methods are invoked twice for each handler !
Here is the current behavior :
init(HandlerInfo), handleRequest(MessageContext), destroy()
--> service invokation
init(HandlerInfo), handleResponse(MessageContext), destroy()

Shouldn't it be as the following ? :
init(HandlerInfo), handleRequest(MessageContext)
--> service invokation
handleResponse(MessageContext), destroy()

See JAXRPC 1.1 §12.1.4 : the sames instances are used for request and 
response handling ...

regards
Guillaume

Re: Incorrect support of JaxRpc Handler LifeCycle/Flow ?

Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Another info :
in the server side, Handlers are invoked as I expected :)
Why this behavior is not identical in client side ?

regrads
Guillaume

Ias wrote:

>Hi Guillaume,
>
>  
>
>>Hi all,
>>
>>I have a simple Client that uses JaxRpc Handler and I found 
>>that init and destroy methods are invoked twice for each handler !
>>Here is the current behavior :
>>init(HandlerInfo), handleRequest(MessageContext), destroy()
>>--> service invokation
>>init(HandlerInfo), handleResponse(MessageContext), destroy()
>>
>>Shouldn't it be as the following ? :
>>init(HandlerInfo), handleRequest(MessageContext)
>>--> service invokation
>>handleResponse(MessageContext), destroy()
>>
>>See JAXRPC 1.1 §12.1.4 : the sames instances are used for 
>>request and response handling ...
>>
>>    
>>
>
>Do you indicate
>
>In this example, three Handler instances H1, H2 and H3 are registered (in
>this order) in a
>single HandlerChain instance that is used for both request and response
>processing.
>
>? This excerpt is from "Example", not a requirement of JAX-RPC 1.1.
>Moreover, the example is about not Handler but HandlerChain. Regarding
>Handler, please refer to section 12.4 in the spec. In particular, 
>
>Once the Handler instance is created and initialized (and is in the Ready
>state), the
>JAX-RPC runtime system may invoke the different handle method multiple
>times.
>
>Therefore, a Handler instance can be shared in handleRequest and
>handlResponse as you pointed out, but that's not required.In other words,
>Axis' style, init-handle(Request or Response)-destroy is also right
>according to the spec. 
>
>Regards,
>
>Ias 
>
>  
>
>>regards
>>Guillaume
>>
>>    
>>
>
>  
>


RE: Incorrect support of JaxRpc Handler LifeCycle/Flow ?

Posted by Ias <ia...@hotmail.com>.
Hi Guillaume,

> Hi all,
> 
> I have a simple Client that uses JaxRpc Handler and I found 
> that init and destroy methods are invoked twice for each handler !
> Here is the current behavior :
> init(HandlerInfo), handleRequest(MessageContext), destroy()
> --> service invokation
> init(HandlerInfo), handleResponse(MessageContext), destroy()
> 
> Shouldn't it be as the following ? :
> init(HandlerInfo), handleRequest(MessageContext)
> --> service invokation
> handleResponse(MessageContext), destroy()
> 
> See JAXRPC 1.1 §12.1.4 : the sames instances are used for 
> request and response handling ...
> 

Do you indicate

In this example, three Handler instances H1, H2 and H3 are registered (in
this order) in a
single HandlerChain instance that is used for both request and response
processing.

? This excerpt is from "Example", not a requirement of JAX-RPC 1.1.
Moreover, the example is about not Handler but HandlerChain. Regarding
Handler, please refer to section 12.4 in the spec. In particular, 

Once the Handler instance is created and initialized (and is in the Ready
state), the
JAX-RPC runtime system may invoke the different handle method multiple
times.

Therefore, a Handler instance can be shared in handleRequest and
handlResponse as you pointed out, but that's not required.In other words,
Axis' style, init-handle(Request or Response)-destroy is also right
according to the spec. 

Regards,

Ias 

> regards
> Guillaume
>