Re: PROPOSAL: 5.0 configuration
[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]
Re: PROPOSAL: 5.0 configuration
On Tue, 2 Jul 2002, Remy Maucherat wrote: [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. 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. Saving the configuration is what got me started. Beeing able to integrate configuration for multiple 'domains' ( tomcat, jk, logging, etc ) was the other big itch. +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 ? I think learned something in the last years :-) No, I plan to minimize the changes ( hopefully none will be required in existing code ), and I'll certainly not touch the existing config mechanism. Tomcat already follow the right patterns ( i.e. beans, setters, etc ), and all components are also JMX enabled now - so no changes in tomcat are needed. This will happen in util, as a new package - most likely an API based on util.prefs and an implementation based on code in jk2. When ready I'll first enable jk to use it, then probably I'll have to make few minor changes in Startup/Main. An intersting point - JMX has a nice notification mechanism. There are few problems - the attribute change notification is optional - but since we 'instrument' using modeler and dynamic mbeans we can intercept all the config changes done directly by JMX and persist them too. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PROPOSAL: 5.0 configuration
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]
