Re: [PATCH] new RPCDispatchHandler feature

[Glen Daniels <gd...@macromedia.com>]

Morgan:

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 the
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 getting
a new instance each time so we can handle various scoping/persistence
options.

We might want some kind of "marker" interface on RPC objects which allows us
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) IF
the object implemented "SOAPTarget" or some such interface.

Thanks again for the submission!

--Glen

----- Original Message -----
From: "Morgan Delagrange" <mo...@apache.org>
To: <ax...@xml.apache.org>
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 implement,
> 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 a
> good addition to Axis as well.
>
> - Morgan
>
>
>