You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Mark Petrovic <ms...@gmail.com> on 2006/04/28 21:11:34 UTC

Implementing an init() interface for user Handlers

Good day.  Thank you for a great way to do XMLRPC with Java and servlets.

Regarding this issue

http://mail-archives.apache.org/mod_mbox/ws-xmlrpc-user/200604.mbox/%3c652b9c0b0604232100w27ce22b8u8fcec2d11570367f@mail.gmail.com%3e

The more I think about this erstwhile "user" issue, the more I see value in
entries in XmlRpcServlet.properties implementing a formal interface,
for example, initialization purposes.

Consider a XmlRpcServlet.properties that contains something like this

publicMethod=somepackage.Handler

where somepackage.Handler would implement

public interface UserHandler {
   public void init(HttpServlet s)) {
   }
}

In the XmlRpcServlet servlet init() method, I envision

public class MyServlet extends XmlRpcServlet {

   @Override  // overrides GenericServlet.init()
   public void init(javax.servlet.ServletConfig pConfig) {
      // for example...
      Context initCtx = new InitialContext();
      Context envCtx = (Context)initCtx.lookup("java:comp/env");
      dataSource = (DataSource )envCtx.lookup("jdbc/myapp");
      pConfig.getServletContext().setAttribute("ds",dataSource);

      UserHandler h = this.getUserHandler("publicMethod");
      h.init(this);
   }

}

With a real Handler instance doing some housekeeping like

public class Handler implements UserHandler {
   private org.apache.log4j.Logger LOG;
   private DataSource ds;

   public void init(HttpServlet srv) {
      ServletContext ctx = srv.getServletContext();
      ds = (DataSource) ctx.getAttribute("ds");
      LOG = Logger.getLogger(this.getClass());  // needs state put in the VM
by srv.init()
   }

   //...
}

The theory being that Handler needs a deterministic way to init
prior to connections being served.  Moreover, Handler is likely to do
real work on things like databases, so it needs a structured, central
place to acquire those resources.  That someplace would in this case be
the XmlRpcServlet instance.

PropertyHandlerMapping.java would have to be modified, for example, to stash
away
the handler instance

final Object o;
try {
   o = c.newInstance();
   userMap.put(key,o);
} catch (InstantiationException e) {
   // ...
}

where userMap is a Hashmap that resides in PropertyHandlerMapping.java
or its parent class.  Other minor mods would have to be affected, but I
think
those are obvious to this audience.  Most notably, perhaps, is that
MyServlet would need
a way to access userMap.

Just some thoughts.

Thanks.



--
Mark
AE6RT

Re: Implementing an init() interface for user Handlers

Posted by Jochen Wiedmann <jo...@gmail.com>.
Hello, Mark,

Mark Petrovic wrote:

> I have implemented this in the latest source tree.  The readership may find
> it of interest
> 
> http://petrovic.org/content/xmlrpc3/

personally, I find it convenient and useful, if handler objects may be
POJO's. However, I can see the advantages of your approach.

To support both, I have opened the creation of handler objects in the
PropertyHandlerMapping and added an entry to the FAQ, which demonstrates how
your use case can easily be resolved by subclassing the XmlRpcServlet.


Jochen

Re: Implementing an init() interface for user Handlers

Posted by Mark Petrovic <ms...@gmail.com>.
Good morning.

I have implemented this in the latest source tree.  The readership may find
it of interest

http://petrovic.org/content/xmlrpc3/



On 4/28/06, Mark Petrovic <ms...@gmail.com> wrote:
>
> Good day.  Thank you for a great way to do XMLRPC with Java and servlets.
>
> Regarding this issue
>
>
> http://mail-archives.apache.org/mod_mbox/ws-xmlrpc-user/200604.mbox/%3c652b9c0b0604232100w27ce22b8u8fcec2d11570367f@mail.gmail.com%3e
>
> The more I think about this erstwhile "user" issue, the more I see value
> in
> entries in XmlRpcServlet.properties implementing a formal interface,
> for example, initialization purposes.
>
> Consider a XmlRpcServlet.properties that contains something like this
>
> publicMethod=somepackage.Handler
>
> where somepackage.Handler would implement
>
> public interface UserHandler {
>    public void init(HttpServlet s)) {
>    }
> }
>
> In the XmlRpcServlet servlet init() method, I envision
>
> public class MyServlet extends XmlRpcServlet {
>
>    @Override  // overrides GenericServlet.init()
>    public void init(javax.servlet.ServletConfig pConfig) {
>       // for example...
>       Context initCtx = new InitialContext();
>       Context envCtx = (Context)initCtx.lookup("java:comp/env");
>       dataSource = (DataSource )envCtx.lookup("jdbc/myapp");
>       pConfig.getServletContext().setAttribute("ds",dataSource);
>
>       UserHandler h = this.getUserHandler("publicMethod");
>       h.init(this);
>    }
>
> }
>
> With a real Handler instance doing some housekeeping like
>
> public class Handler implements UserHandler {
>    private org.apache.log4j.Logger LOG;
>    private DataSource ds;
>
>    public void init(HttpServlet srv) {
>       ServletContext ctx = srv.getServletContext();
>       ds = (DataSource) ctx.getAttribute("ds");
>       LOG = Logger.getLogger(this.getClass());  // needs state put in the
> VM by srv.init()
>    }
>
>    //...
> }
>
> The theory being that Handler needs a deterministic way to init
> prior to connections being served.  Moreover, Handler is likely to do
> real work on things like databases, so it needs a structured, central
> place to acquire those resources.  That someplace would in this case be
> the XmlRpcServlet instance.
>
> PropertyHandlerMapping.java would have to be modified, for example, to
> stash away
> the handler instance
>
> final Object o;
> try {
>    o = c.newInstance();
>    userMap.put(key,o);
> } catch (InstantiationException e) {
>    // ...
> }
>
> where userMap is a Hashmap that resides in PropertyHandlerMapping.java
> or its parent class.  Other minor mods would have to be affected, but I
> think
> those are obvious to this audience.  Most notably, perhaps, is that
> MyServlet would need
> a way to access userMap.
>
> Just some thoughts.
>
> Thanks.
>
>
>
> --
> Mark
> AE6RT
>



--
Mark
AE6RT