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