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]
