tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [5] Config
Date Fri, 16 Aug 2002 12:06:18 GMT wrote:
> 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 ? 

I love it :)

This really seems to pick the best APIs for the job.
It's a good idea to use JNDI for configuration storing indeed, as it 
allows enterprise scale deployments, and seems generally better suited 
than JMX.


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

View raw message