commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: New commons subproject vs. Configuration project
Date Tue, 15 Jul 2003 15:35:29 GMT
Any thoughts on a more "structureless" approach where the XML content is 
looser? What your "Configurator" XML file appears to be is a "Composite 
Naming" or "Federated" stategy where there are actually two naming syntaxes:

In a "generic" xml layout one might have:
Properties props = ctx.lookup("/config/properties[@name='mail.settings']");

In a more specific implementation for Configurator you might have:
Properties props = ctx.lookup("mail.settings");

String x = props.get("");

In the generic api you could do things like:
String x = 



So theres actually two namespaces and context implementations, that of 
your properties (xxx.yyy)
and that of your configuration file structure (or XPath).

I think the current strategy of Configurator is to make the file 
structure transparent to the actual properties objects? (I could be 
wrong). This would be a more specific implementation of generic JNDI SPI 
where XML could easily be exposed/manipulated using JXPath.

what do you think?

Matthijs Wensveen wrote:
> I am currently working on a separate site on sourceforge to place all 
> files, documentation and examples, but hopefully we can place it on 
> Apache some day soon.
> This is how it works:
> There is a singleton Context instance that is provided by a Context 
> subclass. Currently there are 2 implementations, StandaloneContext and 
> WebContext, and it will be easy to provide a JNDIContext.
> After initializing, you reference the Context by calling 
> Context.getInstance(). So your calling classes will be unaware of the 
> underlying implementation.
> The Context initialization consists of parsing an XML file and 
> delegating XML Nodes to specific handlers.
> For example, config.xml:
> <?xml version="1.0"?>
> <config>
>    <element-handler 
> class="nl.func.util.context.handlers.PropertiesHandler" 
> root-element="properties" />
>    <properties name="mail.settings">
>        <property key="" value="" />
>        <property key="default.from" value="" />
>        <property key="default.bcc" value="" />
>    </properties>
> </config>
> Now we can initialize a StandaloneContext, for example: (WebContext is 
> usually initialized in web.xml as a ContextListener)
> new StandaloneContext("config.xml"); // this will initialize a singleton 
> Context
> Using the Context instance, you can lookup all configured objects by 
> calling
> Context ctx = Context.getInstance();
> (Properties) mailSettings = ctx.lookup("mail.settings");
> I'll send a link to the sourceforge project as soon as it's there.
> -Matthijs.
> Mark R. Diggory wrote:
>> Wow, I've always wanted a JNDI SPI for XML files! I imagined one day
>> using JXPath as the base for the search/getAttributes/lookup in such a
>> way as to have the XML content be very open and unrestricted and the
>> search filter syntax would be XPath.
>> /* an XmlContext is a DirContext over XML files */
>> javax.naming.xml.XmlContext ctx = new
>> javax.naming.xml.XmlContext(Hashtable env);
>> Element e = (Element)ctx.lookup("/foo/bar[2]");
>> Attributes atts = ctx.getAttributes("/foo/bar");
>> NamingEnumeration enum ="/foo","[bar/@bam =
>> 'boom']",searchControls);
>> while(enum.hasNext()){
>>    Element e = (Element);
>>    ...
>> }
>> I imagined it would also be used to write attributes, elements to create
>> new "subcontexts". Imagine, a fully read/writable Configuration
>> framework... :-)
>> ctx.modifyAttributes("/foo/bar", attrs);
>> ctx.createSubContext("/foo/bar", "bam");
>> ctx.destroySubContext("/foo/bar/bam");
>> I've been hoping for a way to supply a XML Configuration based
>> replacement for our current JNDI based distributed config which uses
>> LDAP servers.
>> Henri's right, there is room in the commons for multiple
>> implementations. I think this really promotes a path of
>> development where really good alternate approaches can exist.
>> Coevolution can often result in better adaptations to an environmental 
>> condition.
>> -Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message