tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: [Catalina] Discussion - Component Configuration Strategy
Date Sun, 23 Jan 2000 21:33:50 GMT
+1

arkin

"Craig R. McClanahan" wrote:
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message