tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject [Catalina] Discussion - Component Configuration Strategy
Date Thu, 20 Jan 2000 07:04:18 GMT
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.
This choice was made initially for the following reasons:

* Any deployment of Tomcat is going to need to
  parse "web.xml" files anyway, so it is essentially
  certain to have the DOM classes, and an appropriate
  XML parser, hanging around.

* The approach to this taken sometimes in the current
  Tomcat code (convert the DOM to an implementation
  of org.apache.tomcat.util.XmlTree) seems like overkill
  for something that is used one time.

* The DOM elegantly reflects the hierarchical nature of
  component organization within a Tomcat deployment.
  As an example of this, see the "server.xml" file in the
  top level ("proposals/catalina") directory -- it illustrates
  how components in the new proposal nest themselves.
  It would be desireable (IMHO) that any configuration
  mechanism we actually build be able to parse and
  process such a configuration file -- at least until we
  have tools that hide the actual server.xml syntax.

* Configuration is only one of the issues involved -- the
  start/stop functionality is also important (although you can
  modify the configuration mechanism without giving this up).

Counter-arguments and alternative suggestions that have been expressed
so far include:

* It is not particularly elegant to make the core components
  of Tomcat dependent upon an external package like the
  DOM classes.

* Any XML parsing required can be done external to the
  core, and components should be able to be configured
  by these external mechanisms in a more typical JavaBeans
  fashion.

* Consider using introspection to identify the properties
  that can be set from the configuration, in a manner similar
  to what Ant does when configuring tasks.  (I'm very +1
  on doing this).

* Consider using the Configurable interface (and possibly
  others like Block as well) from the Avalon framework.
  I'd really appreciate some comments from people more
  familiar with Avalon on how applicable it might be here.

What do we all think?  How should Catalina components be configured?

Craig McClanahan



Mime
View raw message