tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ludovic Claude>
Subject Re: [Catalina] Discussion - Component Configuration Strategy
Date Sun, 23 Jan 2000 23:53:54 GMT
That looks a lot like the Configuration interface defined in Avalon. Why not
just use it, it's there
and Avalon does already a great job on loading configurations.
It's already loading xml configurations, and could in my opinion do much more,
like loading configurations
from LDAP or from the Windows registry.

Ludovic Claude.

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.
> For example I've used the following interface to represent configuration
> data
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Web Site Watchers Ltd
212 Piccadilly,
London W1V 9LD

Telephone: +44 (0)171 917 6255
Fax: +44 (0)171 439 0262

View raw message