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
> > certain decisions have been taken and also I checked out the to-do list
> > 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
> > would like to have (and work on of course).
> woohoo.
> > What strike me about JMX management is that in Avalon the configuration
> > a hierarchical structure (and that's really sweet) but with JMX you can
> > change only properties, which have a flat structure. Another thing is,
> > 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
> > pattern (Leo Simon already said this) in order to change the
> > values but this will brake the Avalon framework contracts (I think!).
> > the idea that came to me (might be a childish one) was to somehow ???
> > available for management the values stored in the
> > in a structured fashion, in this way when some value was changed by the
> > agent the reconfigure(...) method will be called on the blocks
> > Reconfigurable. This will work well also if the SystemManager will use
> > to manage the blocks.
> > The existing mechanism in Phoenix for registering blocks allows only
> > actions (not values/properties) to be made available for management:
> > "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).


> So Type 1 (kernel et al) management can be done via normal JMX mechanisms.
> 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

> while
> Type 2 (Blocks et al) is different altogether. For Type 2 management there
> 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

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.


> 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
> 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

View raw message