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. 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 ) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
