avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mircea Toma" <mirceat...@home.com>
Subject Re: JMX and stuff...
Date Sat, 08 Sep 2001 19:10:39 GMT

----- Original Message -----
From: "Peter Donald" <donaldp@apache.org>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Sent: Friday, September 07, 2001 11:37 PM
Subject: Re: JMX and stuff...


> Hiya,
>
> On Fri, 7 Sep 2001 15:44, Mircea Toma wrote:
> > I was browsing through the mailing-list archive trying to find reasons
why
> > certain decisions have been taken and also I checked out the to-do list
to
> > see which are the overlaps between Avalon needs and my needs. The
> > conclusion was that remote management (JMX), hot deploy (preferably with
> > remote loading of blocks) and LogKit new management are the things that
I
> > would like to have (and work on of course).
>
> woohoo.
>
> > What strike me about JMX management is that in Avalon the configuration
has
> > a hierarchical structure (and that's really sweet) but with JMX you can
> > change only properties, which have a flat structure. Another thing is,
if
> > the blocks made available for management will have very little things to
> > act on (only the methods that have no args or with primitive arguments).
> > Right now this can be changed only by making the block follow the
JavaBean
> > pattern (Leo Simon already said this) in order to change the
configuration
> > values but this will brake the Avalon framework contracts (I think!).
So,
> > the idea that came to me (might be a childish one) was to somehow ???
make
> > available for management the values stored in the
ConfigurationRepository
> > in a structured fashion, in this way when some value was changed by the
> > agent the reconfigure(...) method will be called on the blocks
implementing
> > Reconfigurable. This will work well also if the SystemManager will use
JNDI
> > to manage the blocks.
> > The existing mechanism in Phoenix for registering blocks allows only
> > actions (not values/properties) to be made available for management:
like
> > "start", "stop", "deploy", "undeploy" ...
>
> Well I guess there are two types of "management" in Phoenix. One is
> management of the embeddor, deployer, kernel, installer etc. Another is
> management of Application components (ie Blocks).

true!

>
> So Type 1 (kernel et al) management can be done via normal JMX mechanisms.
It
> includes the actions you list above (ie start/stop/deploy/undeploy/etc)

This is my opinion too! There are some problems still with the methods that
don't have 'primitive'/'primitive wrapper' arguments, like the "deploy" for
example.

> while
> Type 2 (Blocks et al) is different altogether. For Type 2 management there
is
> essentially two facets - management of Configuration tree and management
of a
> custom management interface that a Block can choose to export.

.. the problem is how to do it:
1) manage the Configuration trees that are stored in the repository
2) something that Leo recommended, having a DynamicMBean that takes the
Block, its manageable interfaces and its Configuration

Solution 1, which I prefer is separating the "configuration" management from
the "action" management. For the "action" management the implementation is
there (Leo's JMX stuff). The "configuration" management can be done by
changing the configuration trees stored in the Repository, the Block-s that
will implement Reconfigurable interface will receive automatically the new
configuration (assuming that the "monitor" package will be used). This will
be consistent with one of to-do points (altough, true for any type of
persistence mechanism):
"- A standard reconfiguration system. This may require the building of
FileMonitors that will read a file when it is changed. Any kind of block or
component that extends the Reconfigurable interface gets sent the new
configuration."


Solution 2, will make the Block manageable as a unit which may be more
compatible with the JMX style of managing MBean-s. This solution will lack
the reuse of functionality that first solution would have. Also if the
"action" management solution is different (like SOAP) the "configuration"
management won't make to much sense.


Mircea

> ie A Block may
> choose to export an interface that allows actions to be triggered by
> management. (ie a Logging daemon may have a "Rotate Now" actions that
rotates
> all logs now and resets the timers).
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------
> "Only two things are infinite, the universe and
> human stupidity, and I'm not sure about the
> former." -Albert Einstein
> -----------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>


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


Mime
View raw message