In a "generic" xml layout one might have:
Properties props = ctx.lookup("/config/[EMAIL PROTECTED]'mail.settings']");In a more specific implementation for Configurator you might have:
Properties props = ctx.lookup("mail.settings");String x = props.get("mail.host");
In the generic api you could do things like:
String x = /config/[EMAIL PROTECTED]"mail.settings"]/[EMAIL PROTECTED]"mail.host"]/@value
or
ctx.modifyAttributes("/config/[EMAIL PROTECTED]'mail.settings']/[EMAIL PROTECTED]'mail.host']",attrs);
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? -Mark
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="mail.host" value="mail.planet.nl" /> <property key="default.from" value="[EMAIL PROTECTED]" /> <property key="default.bcc" value="[EMAIL PROTECTED]" /> </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 = ctx.search("/foo","[bar/@bam = 'boom']",searchControls);
while(enum.hasNext()){ Element e = (Element)enum.next(); ... }
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
