----- Original Message ----- From: "Leo Simons" <[EMAIL PROTECTED]> To: "Avalon Development" <[email protected]> Sent: Friday, September 07, 2001 3:38 AM Subject: RE: JMX and stuff...
> > 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. I saw what you did and I think is really cool! ;) > 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. Definetelly, this is would be a good option, altough I don't know how this will fit with publishing/registering with a SOAP provider. > > > 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. I agree. I still have to look into it more carefully! > 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) cool! Mircea > > Leo, still packing > > > --------------------------------------------------------------------- > 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]
