----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]> To: "Avalon Development" <[email protected]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
