Costin Manolache wrote: > 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 ).
+1. > Remy - what's the status of the new mapper and the server.xml jndi > provider ? I didn't start yet :-( I was kept busy with moving into my new place + the 4.1.x releases and related security issues. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
