avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W." <davew...@optonline.net>
Subject Re: More configurable SystemManager.
Date Fri, 06 Sep 2002 03:04:48 GMT
> Separated configuration is so complicate.
> Configuration is just for SystemManager's configuration.

I decided to think.  Some of my thoughts are below if you care to read them.
Phoenix could, in theory, configure everything using the <mbean> format and
JMX (at least if it required all Blocks to be MBeans).  It would probably
even be a more flexible solution, although more verbose.  But currently it
has it's own configuration format, and the two are in direct competition.
In my opinion, keeping them separate would allow greater flexibility in the
future -- although I'm not really in a position at the moment to judge the
direction of the project ;).

I'd be content, in the short term at least, to see more descriptive versions
of the same thing (i.e. instead of <manager-adaptor-port>number</...> to
configure the http adaptor, <http-adaptor><port>number</port></...>)
JMX configuration is given full consideration.

I'm not really very passionate about the issue, though -- just very bored

David Weitzman

Some thoughts, which may be self-contradictory and unrelated:

Thought 1)

Services like the HTTP and RMI are not directly dependant on SystemManager,
nor vice versa.  The need for them to be associated is that there is no
other way to register MBeans at the moment.

Thought 2)

The things currently managed by SystemManager come with the Phoenix
binaries, and aren't going to gain any new functionality between releases,
so dynamic configuration isn't strictly-speaking necessary.  A simple but
expressive and complete custom configuration would be more concise and
require less knowledge of the inner workings of the services being
configured, but would require modification any time new ways to access JMX
are added..

Thought 3)

Since the <mbean> format already exists and can be implemented without
relying on any particular JMX vendor, directly using DOM would make an
implementation reusable outside of Avalon (which may not matter).

Thought 4)

Phoenix does not currently provide a configuration method that allows the
user to execute/make available arbitrary JMX-compliant beans. That is
precisely the problem that the <mbean> format is designed to solve.  That
format is actually directly competing with Phoenix's own methods of
configuration, just without inherent support for features like the Avalon
lifecycle (which could easily be made available).  It is a separate and
complete solution -- why make it dependant on Phoenix configuration files?

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message