Few weeks ago we discussed about using a JNDI layer to abstract the config data storage.
In addition JNDI is already used to abstract the resource storage ( the files served by tomcat ). I played a bit with the existing code, and I have few proposals: 1. Consistent use of Name methods. As you know, Strings are not the best solution for a server env. Using Name will allow various optimizations and a more efficient implementation. For non-performance critical operations the String variant can be used ( by client ), but our code should be Name based. 2. ServerName. That will be the recommended Name implementation to be used. It'll add support for MessageBytes and notes ( i.e. we can associate an int id to the name - for faster lookups, like notes work in 33). In particular, this should be eventually integrated with the mapper (i.e we need similar parse/lookup methods ). ( that's long term, for now we can just use CompositeName ) 3. BaseDirContext. The goal is to make it easier to write jndi providers - I would like to make it a non-abstract class, throwing UnsuportedException for most operations and providing defaults wherever possible. The attribute operations will be delegated to a simple setAttribute( name, value ), getAttribute(name) ( instead of the Attributes / Attribute / etc ), A provider will just have to override 2-3 methods. 4. Cache. I already did some refactorings in the current code to make the caching that is curently done for files useable for any kind of Context ( i.e. config, ldap, etc ). I think we should use this instead ( when it's stable ). 5. URL-type. For easier access, I would like to use the patterns for url-type names for all drivers - that would make it very easy to use the naming layer from ant or other programs ( so tomcat contexts can be used independently ). 6. XML contexts. For config drivers, the easiest solution would be to just use DOM internally, combined with jxpath or something like that. However in some cases we need to provide a different 'view' of the data - for example when we use introspection to configure components with a different model ( like XmlMapper/Digester are doing ). Of course, this now has to be 2 way ( read/write ). I would also like to make it file-configurable ( instead of API-based, like in xml mapper ). Remy - what's the status of the new mapper and the server.xml jndi provider ? -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
