(Breathing a sigh of relief that I don't actually have to *implement* this stuff, but hoping to contribute a little anyway :-)
On Thu, 15 Aug 2002 [EMAIL PROTECTED] wrote: > Date: Thu, 15 Aug 2002 15:50:00 -0700 (PDT) > From: [EMAIL PROTECTED] > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: List Tomcat-Dev <[EMAIL PROTECTED]> > Subject: [5] Config > > 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. Thinking outside the box a little, what would be the implications of prereq'ing JDK 1.4 as the minimum for Tomcat 5? Then, we could consider using prefs directly instead of via wrappers. > 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. > Using DirContext instead of just Context would also let us think about a storage format with fewer objects in it -- one per managed object instead of one per property -- because we could use JNDI attributes for the individual properties themselves. Such an entry maps pretty directly to *being* an MBean as well ... it might be possible to kill two birds with one stone here. > 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. Some utility methods that perform direct conversion between the structured name types would be well worth it performance-wise. We don't want to be dealing with the String versions of these names any more than we'd have to. > > 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 ). > Note that this would need to include configuration changes the component does for itself (i.e. calculate the work directory path if one hasn't been explicitly configured), not just those performed by external management tools. > Any operation ( reload, etc ) will be done via JMX - only > setting attributes is important for config. > While on that topic, it would be useful for some managed objects to support two "instances" of a component in memory simultaneously -- for example, when upgrading a webapp you often want to leave the old version running (and accepting requests) until the new version has been fully initialized and is ready to start accepting requests. > 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 ). > Yep :-) > 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. > Part of the motivation for JMX in the first place was to support the ability to have external management apps be able to talk with it. If we didn't need that, we wouldn't really need it -- we could just use JNDI to represent the internal component hierarchy (extending the way Catalina already represents a webapp's static resources as a JNDI context). One avenue to consider if the number of MBeans becomes an issue (I'm not sure that it really is -- we've got an instance of the real component class per component anyway) is to make MBeans only for coarse grained things, and represent fine-grained things as attributes of the coarse grained MBeans. Conceptually, this is the same sort of design choice you make with entity EJBs about how fine grained you get. It's not necessarily an all-or-nothing decision. > > What do you think ? > > Costin > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
