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 R J Scheuerle Jr <sc...@us.ibm.com> on 2002/08/28 16:59:40 UTC
Re: JAX-RPC Handler Support in Axis
Damian +1
Rich Scheuerle
IBM WebSphere & Axis Web Services Development
512-838-5115 (IBM TL 678-5115)
Davanum Srinivas
<di...@yahoo.com> To: axis-dev@xml.apache.org
cc:
08/28/2002 09:55 Subject: Re: JAX-RPC Handler Support in Axis
AM
Please respond to
axis-dev
Greg,
Checked in. Please cross-check. How about some testcases? doc updates? :)
Russell, Sam,
Can you please run the JAXRPC TCK tests and let Greg and me know if you see
problems?
Notes:
- Fixed the EngineConfigurationFactoryFinder problem.
- cleaned up the imports in the new java files from Greg.
- added a few entries in the properties files that were missing.
- run "ant clean all-tests"
Thanks,
dims
--- Greg Truty <gt...@us.ibm.com> wrote:
>
>
>
>
> Dims,
>
> I was only a few days off so the upgrade was simple.
> 1) I can't run all-tests but I can do the functional tests due to the
> following error (Richard Sitze will look into it when he get's in)
>
> <failure message="File: C:
>
\axis\0828\java\src\org\apache\axis\configuration\EngineConfigurationFactoryFinder.
> java: Unexpected: log\.(info|warn|error|fatal)[ \t]*\((?![ \t]
*JavaUtils\.
> getMessage)
> " type="junit.framework.AssertionFailedError">junit.framework.
> AssertionFailedError: File: C:
>
\axis\0828\java\src\org\apache\axis\configuration\EngineConfigurationFactoryFinder.
> java: Unexpected: log\.(info|warn|error|fatal)[ \t]*\((?![ \t]
*JavaUtils\.
> getMessage)
> at test.utils.TestSrcContent.testSourceFiles(TestSrcContent.java:
73)
>
> 2) fully agree (are you going to do this or should I ask Russell?)
>
> Here is the .zip file as you requests...
> (See attached file: handler.zip)
>
> Regards... Greg
>
> Greg Truty
> WebSphere Architecture/Development, IBM Austin
> EMail: gtruty@us.ibm.com (Internal)
> gtruty@ibmusm26
> Phone: (ext) (512) 838-2828 (Tie) 678-
2828
>
>
>
>
> Davanum Srinivas
>
> <di...@yahoo.com> To: axis-dev@xml.
apache.org
>
> cc:
>
> 08/28/2002 07:52 Subject: Re: JAX-RPC
Handler Support in Axis
>
> AM
>
> Please respond
>
> to axis-dev
>
>
>
>
>
>
>
> Greg,
>
> 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 file.
> - 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 and
> hand it over to russell for jaxrpc tests...Does this sound ok?
>
> Thanks,
> dims
>
>
> --- Greg Truty <gt...@us.ibm.com> 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;
>
=== message truncated ===
> ATTACHMENT part 2 application/zip name=handler.zip
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com