tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: TC 6: What needs to be done?
Date Fri, 05 May 2006 16:44:53 GMT
On 5/5/06, Jess Holle <jessh@ptc.com> wrote:
>
> Costin Manolache wrote:
> > On 5/5/06, Jess Holle <jessh@ptc.com> wrote:
> >> Costin Manolache wrote:
> >> > On 5/5/06, Rainer Jung <tomcat-dev@kippdata.de> 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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message