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]>
