tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Holman" <>
Subject Re: [Catalina] Discussion - Component Configuration Strategy
Date Sun, 23 Jan 2000 23:21:23 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.

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.

For example I've used the following interface to represent configuration

public interface PropertyTree {
    String getName();
    String getValue();
    java.util.Enumeration getAttributeNames();
    String getAttribute(String name);
    java.util.Enumeration getChildren();
    java.util.Enumeration getChildren(String filter);
    PropertyTree getFirstChild();
    PropertyTree getFirstChild(String filter);

In the DOM-based implementation a DOMPropertyTree is an adaptor class
wrapping a DOM element. The PropertyTree name corresponds to the tag of the
DOM element, attributes and children map to its attributes and child
elements, and the value maps to the value of the first child text node of
the DOM element. The filter simply selects children with the given tag, but
in an LDAP-based implementation it might perhaps be extended to encompass
LDAP filters.

I could offer some code for a preliminary DOM-based implementation if it
would be of any use.

Hoping this is not too far off the point ...

John Holman

View raw message