[EMAIL PROTECTED] wrote: > The basic idea is to use a 2-layer configuration mechansim, > with a pluggable repository for preferene storage and > JMX-based component configuration. > > For config storage, we should be able to use: > - current XML files ( with few minor changes in the 3-4 classes > that deal with reading config ) > - JNDI - for config stored in a directory service ( ldap, > active directory, nds, etc). > - JDK1.4 preference API, if running in JDK1.4 ( that means > registry on windows, well-defined xml files on unix ). > - registry - using jk2 native calls > - if tomcat is embeded in another application, the application-specific > config repository. > > > The config layer will be similar with the JDK1.4 preferences (which > we can't use directly - we still have to support older versions ), > and will be mostly independent of tomcat ( eventually move to > commons - but after we get it stable and to do what we need in tomcat). > > There are few big benefits in this: > - better scalability ( with directory services, in case of large site ). > - consistent configuration with the applications embeding tomcat. > - consistent configuration with the OS ( i.e. registry can be used > on windows, etc ). > - simpler API for configuration ( the XmlMapper/Digester are still > a bit tricky, and is very difficult to make changes ) > - allow us to capture what the user directly changes - the current > mechanism for saving will just read all the properties from all beans. > - we'll be able to use a single config storage/format for all > components ( instead of server.xml, policy, jk2.properites, user.xml,etc) > > The implementation will actually use the same mechanism as today - > except that instead of reading the XML file and using XmlMapper/Digester, > we'll get the data from the repository.
That seems like a very good idea to me. In Tomcat 4.1, there's currently a big difference configuration-wise when you embed Tomcat when compared to when you run it standalone; I think this is a problem. Another problem of the current config mechanism is that it is hardcoded for the digester, and is therefore is limited. The mechanisms to save back the configuration are also hackish and limited. > In addition, any change will be made via the configurator and JMX, > and will be recorded and saved ( with a bit of work it is even > possible to save the xml files preserving the comments and with > the same structure, and only what is modified will be written ). > > > > The second layer will be based on the JMX patterns - and will not require > any change in the current code. The configurator will just set > the attributes and create the components - using either direct > introspection or JMX. > > As more components will be JMX-instrumented, we should be able to use > the new configuration to setup those components as well ( log4j for > example ) - without any special change in the code. > > There is nothing very new in this proposal - having pluggable config > has been a goal since tomcat3.0, and the proposal itself will change > very little as code. A basic implementation of this model is already > part of mod_jk2 ( in jk_config.c - the java version will follow, > if we agree on this proposal :-). > > Both layers will be based on existing standards and common patterns. > JMX ( and the current java bean patterns ) are clearly the best way to > configure components, and JNDI/prefs provide an excelent API > for storing config data ( and XML can use that easily ) +1. This looks like a welcome step forward, and is well worth the effort. I don't see anything in the proposal which mentions removing the current configuration mechanisms; would you leave it there for compatibility ? Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
