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
Henri Yandell wrote:
On Tue, 15 Jul 2003, Matthijs Wensveen wrote:
Our idea was to keep configuration information as centralized as possible. While it is possible to use multiple configuration files, users are encouraged to use only one configuration file. Another difference is that our configurator was meant to look a bit like a JNDI, no matter if there is a real JNDI on the background or just an XML file containing data.
Sounds like my simple-jndi a bit. Although I wrote it to see DataSources outside of containers, I've mainly used it as a configurator.
http://www.osjava.org/simple-jndi/
I think that our configuration system is very useful for the open source community, but I don't know if there is place for two different configuration systems in the Jakarta Commons project. Maybe it's possible to use each others ideas. If anyone is interested, I can provide full source, examples, documentation and javadocs, or just some extra info.
There are no rules at Apache about having to be only one project supplying an implementation. I'd move onto supplying extra info if I were you. Either push up a simple web-site somewhere, or a just a page detailing some examples if you have to worry about legal issues until you've broached things with your company.
Finding a way to work with configuration component is probably the best way [and something I need to do with simple-jndi too] as it stops your codebase being treated as a new project and having to slowly incubate its way into Apache.
Hen
--------------------------------------------------------------------- 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]
