axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: [PATCH] new RPCDispatchHandler feature
Date Tue, 15 May 2001 14:01:17 GMT
Actually, I like the approach that someone (I don't remember who it was)
in the soap-dev mailing list suggested - check to see if the target class
implements a particular interface and if so call some "prep" method
before we call invoke.  This way all of the logic can be kept in one
object and the service provider doesn't need to create new handlers
just one more method.

"Glen Daniels" <> on 05/14/2001 11:40:55 PM

Please respond to

To:   <>
Subject:  Re: [PATCH] new RPCDispatchHandler feature


Sorry for the ridiculously late reply... I like the direction in which this
feature is heading, but I think I'd like it a little better if it were done
slightly differently.  Rather than subclassing RPCDispatchHandler, maybe we
could do it like this:

--- in RPCDispatchHandler.invoke() ---
  String prepName = (String)service.getOption("objectPreparer");
  if (prep != null) {
    Handler prep = (Handler)hr.lookup(prepName);
    msgContext.setProperty("targetObject", obj);
    if (prep != null) prep.invoke(msgContext);
--- end of code ---

In other words, if we have the "objectPreparer" (terrible name, I know)
property set to a handler name, that handler gets to run and do whatever it
wants to the targetObject.  This is very similar, really, it just avoids
subclassing and re-uses the Handler architecture.  This could go beyond
beans, in that you could build per-service Handlers which know how to
manipulate specific classes in interesting ways.  What do you think?

This reminds me of two related issues as well:

We need ways of getting the target object from a Supplier instead of
a new instance each time so we can handle various scoping/persistence

We might want some kind of "marker" interface on RPC objects which allows
to pass in the MessageContext as well as the method arguments to the target
method.  For instance, if we had a method with a single string param, we'd
actually look up method(MessageContext, String) instead of method(String)
the object implemented "SOAPTarget" or some such interface.

Thanks again for the submission!


----- Original Message -----
From: "Morgan Delagrange" <>
To: <>
Sent: Thursday, April 19, 2001 5:18 PM
Subject: [PATCH] new RPCDispatchHandler feature

> Hi all,
> I'd like to propose a patch (attached) to the RPCDispatchHandler.  I've
> added a new method called handleObject, which subclasses may override to
> manipulate the JavaBean before the RPC method is invoked.  This should
> provide more potential configurability to the Axis users.  Here's an
> example of a method that a subclass of RPCDispatchHandler could
> which would give a specialized Bean access to the servlet request and
> response:
>   protected void handleObject(MessageContext reqContext,
>                               Object rpcObject) {
>     PropertyBean bean = (PropertyBean) rpcObject;
>     bean.setProperty(HTTPConstants.MC_HTTP_SERVLET,
>       reqContext.getProperty(HTTPConstants.MC_HTTP_SERVLET));
>     bean.setProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST,
>       reqContext.getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST));
>     bean.setProperty(HTTPConstants.MC_HTTP_SERVLETRESPONSE,
>       reqContext.getProperty(HTTPConstants.MC_HTTP_SERVLETRESPONSE));
>   }
> This is a technique that I've used with Apache-SOAP; I think it would be
> good addition to Axis as well.
> - Morgan

View raw message