tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: [Catalina] Discussion - Component Configuration Strategy
Date Sun, 23 Jan 2000 23:53:11 GMT
John Holman wrote:

> > One aspect of the proposed architecture is certain to engender further
> > discussion -- the use of the org.w3c.dom "Node" interface as the means
> > by which components receive their component configuration information.
>
> As well as the general strategy for configuration there is still this issue
> of the API for accessing  the configuration data itself. Rather than using
> the DOM directly (as e.g. in Craig's original proposal) I'd suggest a
> simpler interface that is oriented more towards representing configuration
> data (as opposed to documents) and which should be as well suited to an
> implementation based on say LDAP or properties files as it is to XML.  These
> advantages of abstraction and simplification should outweigh any
> disadvantage of introducing an additional layer - especially since
> performance is not really an issue in this context.
>

The current (non-Catalina) version of Tomcat has a very similar data object to
your PropertyTree already defined-- org.apache.tomcat.util.XMLTree -- that was
(and might still be?) used for pretty much this purpose.

However, having listened to the interesting discussion on this topic so far,
I'm actually coming to a different, and somewhat radical (appropriate, I guess,
for a "revolution" :-) viewpoint -- there should be no such thing as a
"configuration data API"  because the needs of different deployment scenarios
are quite different from each other.  Let me articulate a few principles that I
think make sense (some already mentioned by others, and some that I'm pulling
out of what has been said), and lets's see what we all think.  For each
principle, there are some corresponding implications:

(1) Components should be configured from the "outside", not the "inside".

    Implication:  There should not be a configure(ConfigData data) method
    signature at all.  Instead, the component should be configured by
    property setting of publicly accessible properties.

    Implication:  The outside environment is free to access or represent
    configuration data in any manner that it sees fit.  For example, an
    environment parsing an XML configuration via SAX events could
    fire property changes directly at the appropriate times, instead of
    having to build up a complete data object.  The same concept applies
    when reading configuration data from a database or directory server.

    Implication:  You need not go to the work of creating Java classes
    for configuration data (either customized, like the current
    org.apache.tomcat.deployment family, or general purpose)
    unless you need it for some other reason.

(2) Components need to know when the outside environment thinks
     configuration has been completed (so that the component can be
     used), and when the outside environment wants to shut them down.

    Implication:  Method signatures for these "life cycle" events are useful.
    Catalina uses the start() and stop() methods of the Lifecycle interface
    for this purpose.

(3) Components should support dynamic configuration changes on the
     fly, to the maximum degree feasible.

    Implication:  In general, no new method signatures are required, because
    reconfiguration is normally done by changing the values of existing
    properties.

    Implication:  The property setter methods need to be aware when
    they are being called at initialization time, versus at run time.  Keeping
    track of the current lifecycle state (see #2 above) makes this easy.

    Implication:  Components should be able to reject property changes
    that are not feasible to implement dynamically, by throwing
    IllegalStateException.

    Implication:  From the "outside" viewpoint, dynamic reconfiguration
    changes are done by setXxxx calls on the component itself, since
    no extenral "configuration data" object can be assumed to exist
    (see #1 above).

(4) Persistent storage of configuration information, including the current
     configuration state when dynamic changes are made, is very useful.

    Implication:  It might be possible for an outside agent to examine the
    current state of all configured components, and synthesize the
    persistent form of the configuration information that would reproduce
    the current state.  In such cases, no extra effort inside the components
    is required.

    Implication:  In some environments, a data object really is maintained
    to represent the current configuration data, and it would be useful for
    changes made dynamically (see #3 above) to be recognized in "real" time.

    Fortunately, the JavaBeans property change design pattern makes
    this quite easy to implement -- interested configuration objects can
    register themselves to receive property change events.  Components
    should implement appropriate property change event generation into
    their setXxx methods to facilitate this.

I think this approach deals with most of the negative consequences of the
various approaches we've been discussing.  How does it sound?

Craig McClanahan



Mime
View raw message