axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: JAX-RPC Handler Support in Axis
Date Wed, 28 Aug 2002 11:52:49 GMT

Thanks. I was hoping someone would jump in :) Here's my +1 for the changes as long as:

#1: Don't break any of the tests...
#2: We still pass the JAX-RPC TCK...

Also, Can you please send in a patch as follows?

- Get the latest Axis code, make the necessary changes.
- run "cvs diff -u" from the xml-axis/java/ directory, capture the output in say a axis.diff
- Create a zip file with all the new java files and the axis.diff from above.
- Send the zip file to the list.

As soon as i get this update from you, i will try to merge the changes in, run the axis tests
hand it over to russell for jaxrpc tests...Does this sound ok?


--- Greg Truty <> wrote:
> Folks,
> I apologize for the long note... so... if you are not interested in the
> JAX-RPC handler support in Axis... you can stop right here.  I was taking a
> look at our current JAX-RPC handler support in Axis.  To (a) document the
> work and (b) define issues with it. I defined what I believe Axis does,
> defined the issues, and then suggest a solution.
> Dims has added a good portion of the Axis support for Handlers (thanks
> Dims).  However, the support needed for containers (as defined in JSR 109)
> and that required for non-managed environments (as defined in 101) is a bit
> different.  In addition, how this *could* or *should* be reflected in the
> *config.wsdd documents should be addressed as pieces are currently missing.
> One of the reasons I want to suggest this is that if users of Axis wanted
> to stick with spec compliant APIs, this would be a good model to start
> with.
> Axis
> There are 2 ways to configure JAX-RPC Handlers within Axis.
>    1) use the WSDD model, create an instance of a JAX-RPC handler and
>    define the className parameter of the Client Handler to be invoked.
>       <service name="HelloPort" provider="java:RPC">
>             :
>         <requestFlow>
>          <handler type="java:org.apache.axis.handlers.JAXRPCHandler">
>           <parameter name="className" value="samples.jaxrpc.hello.
>       ClientHandler"/>
>           <parameter name="scope" value="session"/>
>          </handler>
>         </requestFlow>
>             :
>    2) use the APIs defined in JAX-RPC to add the handler to the Service
>    object.
>            java.util.List list = helloService.getHandlerRegistry().
>    getHandlerChain(new QName(nameSpaceUri, portName));
>            list.add(new javax.xml.rpc.handler.HandlerInfo(ClientHandler.
>    class,null,null));
> Although 2) is the official API way, it intertwines the programming model
> w/the QOS possibly added by the handlers at a later date.  Therefore, 1) is
> actually a cleaner way (from an application developer standpoint) in that
> out-of-band QOSes can be added w/o affecting the client programming model.
> However, w/the current implementation, there is a caveat w/the current Axis
> design.  In 1) above, the JAX-RPC handlers are added in an slightly bizarre
> fashion, in that the actual JAX-RPC Handler used itself isn't a first class
> WSDD handler, but instead a parameter to an Axis Handler (org.apache.axis.
> handlers.JAXRPCHandler).  Although this allows the JAX-RPC handlers to be
> called in a container-based manner, via something similar to the item
> below...
>     <service name="http://hello.jaxrpc.samples/" provider="java:RPC">
>       :
>      <requestFlow>
>       <handler type="java:org.apache.axis.handlers.JAXRPCHandler">
>        <parameter name="className" value="samples.jaxrpc.hello.
>    ClientHandler"/>
>        <parameter name="scope" value="session"/>
>       </handler>
>      </requestFlow>
>      <responseFlow>
>       <handler type="java:org.apache.axis.handlers.JAXRPCHandler">
>        <parameter name="className" value="samples.jaxrpc.hello.
>    ClientHandler"/>
>        <parameter name="scope" value="session"/>
>       </handler>
>      </responseFlow>
>       :
> ...the creation of the HandlerInfo object defaults to no HandlerConfig
> objects (i.e., the init params) or Headers (the soap-header qname items).
> In looking at the code, it does something like this...
>    public class JAXRPCHandler extends BasicHandler {
>        protected static Log log =
>                LogFactory.getLog(JAXRPCHandler.class.getName());
>        HandlerChainImpl impl = null;
>        public void invoke(MessageContext msgContext) throws AxisFault {
>            log.debug("Enter: JAXRPCHandler::enter invoke");
>            if (impl == null) {
>                String className = (String) getOption("className");
>                impl = new HandlerChainImpl();
>                impl.addNewHandler(className);
>            }
>       :
> Which would create the HandlerChainImpl below...
>    public class HandlerChainImpl extends ArrayList {
>        protected List handlerInfos = new ArrayList();
>        String[] roles = null;
>        public HandlerChainImpl() {
>        }
>        public HandlerChainImpl(List handlerInfos) {
>            this.handlerInfos = handlerInfos;
>            for (int i = 0; i < handlerInfos.size(); i++)
>                add(newHandler(getHandlerInfo(i)));
>        }
>        public void addNewHandler(String className) {
>            try {
>                HandlerInfo handlerInfo = new HandlerInfo(ClassUtils.
>    forName(className), null, null);
>                handlerInfos.add(handlerInfo);
>                add(newHandler(handlerInfo));
>       :
>        }
>    :
> As you can see... the 2 null's passed in don't allow a map to be easily
> created or the list of QNames.  In addition, there are another set of
> Issues I found in trying to figure out out to resolve this.
> Issues:
> 1) HandlerChainImpl doesn't implement JAX-RPC HandlerChain
>    I talked to Rich about this and saw the note from Rich and Dims about
>    this...  My version does implement this.
> 2) JAX-RPC handlers can only configured for the client side
>    Since JAX-RPC is a programming model issue on the client side... Dims
>    only addressed the client side.  It's also only specifiable via
>    configuring the JAX-RPC service.  I added support to allow this and
>    works off the configuration files as well as on the server side.
>    However... there is a problem addressed in item 6 below.
> 3) The AxisEngine implementation is tuned for the client side (it's based
> on a Call object being available).
>     Calls are only available on the client side.  Therefore, I moved the
>    logic for the invoke to AxisClient vs. AxisEngine.
> 4) getPort is required
>    This is more a comment but since getPort is required, we now take
>    advantage of Russell's new code in ServiceLocator is now there to set
>    the WSDDService name (which is the Port).  We have to be aware of what
>    this means in the WAS integration piece.
> 5) invokeJAXRPCHandlers is in the wrong spot on the client.
>    It should be prior to the global handlers but right now it's after.  I
>    suggest actually even prior to the service-specific Axis Handlers.  As
>    such, I think it should also be in the same spot on the server side.
>    For now, I left it where it is (it's called in AxisClient) and recommend
>    we probably move it to the Call object itself.  On the server side, I
>    placed in in JavaProvider (on the invoke).  Again... thinking it should
>    be as close to the target dispatch as possible.  Note, I call these
>    prior to the demarshalling (in case they want to screw w/ the XML
>    message).
> 6) On the client side... we need to discuss the behaviour of JAX-RPC
> handlers configured programmatically and those via the client-config.
> There are merge issues between programmatic and config based items now.
>    Currently, I am using the container config version even if they do so
>    programmatically.  We need to disallow the programmatic version in 109.
>    We should probably ask how we want to deal with this in the Axis non-
>    container managed version.. and keep an eye on the 109 implementation of
>    these items.
> 7) JAX-RPC spec discusses an init(Map) method on the HandlerChain.  I can't
> quite figure out how this should be used.
>    I think we need to go back to the JAX-RPC folks.  Since HandlerInfos
>    (which ARE part of the programming model), take maps, I can't tell how
>    it should be called.  Also, users can't really create the HandlerChain.
>    Only Chains of HandlerInfo objects.  Therefore, I can't quite figure it
>    out.
> Prototype Details
>    1) Created a set of WSDD artifacts to extend to support HandlerInfo and
>    Chains for these HandlerInfo objects.
>    WSDDConstants - added additional constants
>    2) Created a HandlerInfoChainFactory to produce these HandlerInfoChains
>    which will eventually create HandlerChainImpl objects.
>    3) Moved invokeJAXRPCHandlers from AxisEngine to AxisClient (as per
>    above)
>    4) Added Constants for HandlerInfoChain in Constants
=== message truncated ===

> ATTACHMENT part 2 application/zip

Davanum Srinivas -

Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes

View raw message