tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject PROPOSAL: 5.0 configuration
Date Mon, 01 Jul 2002 22:07:38 GMT

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 )


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message