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 Thu, 20 Jan 2000 20:01:59 GMT
I have one point to make. The fact that Tomcat is using DOM is an
implementation decision, not a design decision. Tomcat can be upgraded
tomorrow to use SAX, for example. It doesn't make sense, but it can be
done.

For that reason I like tha Ant model better. I just created a new
TaskDef without asking myself whether Ant is using DOM or SAX and
whether that would change tomorrow. For all I care it might switch to
non-XML documents or remote objects.

arkin


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

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Mime
View raw message