On 5/5/06, Jess Holle <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote: > On 5/5/06, Jess Holle <[EMAIL PROTECTED]> wrote: >> Costin Manolache wrote: >> > On 5/5/06, Rainer Jung <[EMAIL PROTECTED]> wrote: >> >> 1) Configuration Management >> >> =========================== >> >> >> >> My impreesion is, that to much configuration is hard-coded in RuleSet >> >> classes. Of course everyone can easily add properties to existing >> >> components, but adding subcomponents nedds changes in core RuleSet >> >> classes. Am I wrong? Should we change that to allow more complex >> >> subsystems handling their configuration rules independently of the >> core? >> >> One such example is the current stable clusster module. >> > IMO the entire server.xml and RuleSet should be deprecated, and >> replaced >> > with JMX. We could keep current server.xml around, for compat - but at >> > least not >> > extend it. >> > >> > Even the very limited MLET syntax can support most of our needs. >> > >> > RuleSets are just a way to set attributes ( == jmx setters ) and >> > define hierarchy >> > of componets ( == can be done based on JMX names, in a more dynamic >> way ) >> I'd generally tend to agree, but suggest that thought be given not just >> on elegant configuration but also on the ability to change things via >> JMX and then *save* the results as an updated configuration. > 'save' is on my list for about 2 years now :-) > > But this would be the second step - after we use JMX to set up tomcat > instead > of server.xml. I just bring it up as I have completed a JMX framework for our use with round trip persistence to XML. The biggest limitation in my case is that the configuration files are not (nearly) so elegant as something like Spring's -- though they're rather similar to a point (I use Java's built-in XMLEncoder/XMLDecoder stuff). This is primarily so that the original configuration file can be reproduced reliably with very little persistence architecture on my part. Trying to provide the richness of something like Spring and provide round-trip saving would seem to be the holy grail -- and possibly just as unattainable. > My old plan was to use something like MLET, and DOM to read/save ( so > most of comments/structure is preserved ). Use of XMLEncoder/XMLDecoder allows persistence of arbitrarily complex substructures, which is nice. The result is not extraordinarily reader-friendly, but it is quite general.
AFAIK XMLEncoder/XMLDecoder will save all the attributes, and lose comments in the round trip. With DOM - you have a good round trip, and if all config happens via JMX, you know what attributes have changed. Apple and Mozilla configs are the models I'm considering, even if some of the structure is lost in the round trip, I think having only the modified elements is essential. I don't think you can do this with XMLEncoder, and our server.xml saving doesn't seem to support this either. Costin
