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