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