tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: a few comments
Date Tue, 19 Oct 1999 19:44:35 GMT
"Anil K. Vijendran" wrote:

> Jan-Henrik Haukeland wrote:
> > Another thing, it would have been greate if we could use something
> > similar to Craig's LifeCycle interface (from JSERV1_1DEV), such a
> > design makes it easier to manage pluggable components like a Loader
> > and Logger (and so on).
> This sounds interesting. Can you explain more? Thanks.

I can take a crack at this one.

The JSERV1_1DEV architecture was based on making nearly every piece of the servlet
container a plug-replaceable component.  The configuration file allowed you to select
a particular Java class to implement your context, your virtual host, your session
manager (so you could plug in session persistence, for example), and so on.  Even the
Valves that were added (similar in concept to Interceptors in Tomcat) could be
selected dynamically at configure time.

The challenge in all of these cases was to conveniently initialize all these
components.  Constructors with arguments were out, because I wanted to use
Class.newInstance() to create them.  Hence, I needed a common interface that made
initialization easy.  While I was at it, we added generalized "start" and "stop" calls
as well, so that a component could do graceful startup and shutdown too.  The result
is an interface called Lifecycle, with three methods:

public interface Lifecycle {

    public void configure(Properties props, String prefix)
        throws LifecycleException;

    public void start() throws LifecycleException;

    public void stop() throws LifecycleException;


The general model for instantiating a new object went like this:

* Identify the class name of the implementation class
  (from a config parameter or default setting)

* Create a new instance of that class.

* If the implementation class is an instance of
  Lifecycle, call it's configure method and pass
  on a Properties object and a property name
  prefix.  (In a Tomcat based implementation
  this would probably be an XMLTree of the
  portion of the configuration that is relevant
  to this component).

The configure() method  is conceptually similar to the init() method of a servlet, and
stop() is conceptually similar to destroy().  I separated the "start processing
requests" method from initialization because I liked the ability to reconfigure by
doing:  stop(), configure(), start() -- they probably don't really have to be

This model proved to be quite flexible and easy to understand, and I would recommend
it highly for Tomcat components.  However, we should also examine the current state of
the Avalon framework (on the site), which was not fleshed out in
nearly the current level of detail when I needed LIfecycle.  Avalon's "block" concept
is supposed to include lifecycle type support and a bunch of other things.

Craig McClanahan

View raw message