After a lot of thinking and searching, I found a solution that I think will work well. If you like it - I'll need some help from Remy to implement it. If you don't like it - I'm waiting for a better one...
There are 3 major parts: 1. Config storage. Currently that's server.xml. 2. Configuring various components ( runtime config, init, etc ). That's done using digester/introspection in 4.x ( init ) and JMX ( at runtime ) 3. Saving config. That's done via introspecting life objects and generating server.xml in 4.x What I'm proposing is a pluggable config storage, using JNDI API for storage and JMX ( and introspection ) for runtime changes. For API - my initial approach was to create a clone of 1.4 prefs. I think a much better solution is to use JNDI as API. We already depend on JNDI, and JNDI is available to all VMs - including in GCJ, kaffe. The interface is mature, flexible and well known. In addition it is very easy to create wrappers to jdk1.4 prefs and back - so both 'flavors' can be used. The data will be organized to follow the JMX naming hierarchy ( after reorganizing the naming schema ): each tomcat component that is configurable will have a JMX name and associated attributes, and those will be stored in the directory. An ObjectName will be a jndi Name. We'll automatically gain access to all 'stores' that jndi supports - ldap, directory servers, etc. There are also file providers implementing standard xml formats ( or ldif ?). An additional format to support may be the jboss-style <mbean> - which may be syntactically closer to the jmx-based runtime. The second layer will be a wrapper that can use either introspection or JMX, possibly an extension of modeler. We'll have a clear distinction between 'persistent' config and 'runtime' config. JMX was not designed for storage ( even if it has the optional load/store methods ), and it is useful to be able to choose between making changes in the running server ( some may be temporary ) and making changes in the persistent store. Using notifications it is possible to propagate any change via JMX to the store - but that should be optional ( i.e. you could choose to not change the store, but only the runtime ). Any operation ( reload, etc ) will be done via JMX - only setting attributes is important for config. It is possible to also use DirContext to represent 'life' objects - and use the same API to set attributes on the persistent and life sub-trees. ( with JMX or introspection underneath ). There are few (major) issues with JMX - I don't know how well it will scale, giving the huge number of objects it involves. One way to solve this is to use mx4j internals - for example to delay some of the introspection, optimize some lookups, etc. Right now the JNDI model seems better suited for a large number of objects ( if we start representing each servlet as an mbean - for example to collect time information ). But overall JMX is the right way to go about configuring and operating on live objects, and JNDI is (IMO) the right way to go about storing hierarchical and config data. What do you think ? Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
