Hi, 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).
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" ... I guess I was trying to revive the remote management subject which seems to be stalled for a while now. Mircea --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
