> 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).
cool. > 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!). not entirely true. What you can do is provide what is called a DynamicMBean for a Component (or any object) to describe in "JMX vocabulary" how to use the component. The code in org.apache.jmx.introspector is almost finished, and will in fact generate a DynamicMBean exposing all public methods and properties. It would be smart to (for example) subclass the DynamicMBeanFactory to create a DynamicMBeanBlockFactory that exposes all available methods for the block and also looks at the configuration of the block. In the end, everything _not_ defined in code but only in the contracts should be accessible using a method on an MBean as well. > 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. Would be an option. I am worried however that when you flatten the hierarchy in some way, things will get messier and thus even more complicated to follow. This is probably easier to do than dynamic introspection, though. > I guess I was trying to revive the remote management subject > which seems to > be stalled for a while now. Yup. My fault (no time). Good luck with it! (and in case anyone wonders: I have no problems with people throwing away all the current code and starting from fresh) Leo, still packing --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
