One difference is that org.apache.axis.handlers.JAXRPCHandler extends BasicHandler. So it fits into the Handler policy of Axis. And it can be deployed as handler in every chain you want (transport, global, service). With handlers implementing javax.xml.rpc.handler.Handler and deployed in a <handlerInfoChain> I don't know. There may be some restrictions.
Perhaps the following mailinglist-thread can help a bit:
http://marc.theaimsgroup.com/?t=105906906900014&r=1&w=2
Another interesting thing to know is, that the org.apache.axis.handlers.JAXRPCHandler class ignores the return value of the handleRequest and the handleResponse methods (lines 82 and 84 of JAXRPCHandler.java in the axis 1.1).
This implies that you cannot return from a chain without throwing an exception: As the api-docs state for javax.xml.rpc.handler.Handler the return value of the mentioned methods would affect the processing of the chain the handler is part of. Wrapped into the JAXRPCHandler this is no longer valid. So the chain (if not interrupted by an AxisFault) will continue to the Pivot point of the service.
(Someone correct me, if I'm wrong).
What would interest me in this case is if/how a combination of both approaches (<handlerInfoChain> and <requestFlow>, <responseFlow>) works.
cheers, Christoph
Thilo Frotscher wrote:
Hi!
There are two ways how you can deploy a JAX-RPC handler.
1) use <handlerInfoChain> in the service definition 2) wrap it using JAXRPCHandler
What's the difference?
It seems that all handlers that were deployed using handlerInfoChain are called between the global chain and the SOAPService (on the server side), or between the global chain and the Transport Sender (on the client side), respectively. On the other hand, JAXRPCHandler can be deployed in any chain, like a transport specific chain or the global chain. Is this correct?
If yes: why is there <handlerInfoChain> if I can deploy JAX-RPC handlers anywhere I like using JAXRPCHAndler?
Thanks, Thilo
