On Fri, 16 Nov 2001 22:42, Pratik Patel wrote: > Excellent summary Peter - I've added some comments below as I've been > working on a JMX Agent, > and have been thinking about how we can incorporate JMX into Avalon.
kool. > >JMX is an api for managing components. It includes interfaces and rules > > for describing how attributes can be read/writen on components and > > operations performed on them. It also has an interface to describe how > > components can generate periodic events and so forth. > > I am not sure if I would use the word 'component.' The only other term I could think of was Object and that seemed even less appropriate ;) > Sure, you can manage > components as we think of > them in Avalon; JMX seems more geared toward managing larger services, > what we would consider > blocks in Avalon-speak. This is not to say we couldn't use JMX at both > levels (components and > blocks). yep. > >Why use JMX? Mainly as it is a standard. Theres definelty some warts on > > the API but overall it isn't that bad and it is a standard. Quite a few > > application frameworks are working towards being managed by it. IIRC > > there is already a few servlet engines that are manageable by it, ejb > > servers and general application servers. > > Yes, there is some momentum behind JMX already, and yes there are some > problems with the RI. Sun is slow > to release fixes to the RI. Some folks have started an open-source > project for a JMX RI at Sourceforge called > OpenJMX. kool. Didn't know about that. > >Anyways JMX is good because it will have a lot of interoperable servers > >workable via it ;) > > Indeed there are quite a few open and closed source servers which can be > administered by its JMX interface, > even Tomcat 4.x. There are a few issues that need to be resolved when > hooking up disparate servers together > like JNDI discovery of components, etc. yep. > The only question that remains is 'How do we want to use JMX in Avalon?' > This is what I've been > asking myself before embarking on writing some code. So far my feeling > is that we should do it at the block- > level at the moment, and make an MBeanServer as part of the kernel > (Phoenix). agreed. > Blocks should then be forced to implement the MBean interface; I am not sure I agree with that. > accordingly the configuration of > blocks and the startup/shutdown of blocks > be done only via the MBean interfaces. There should also be a 1-1 > correlation of the block xinfo to a block's > exposed management interface. > > Of course, I am still developing this vision, so comments/debate are > most welcome. Well the way I see it is that there is 3 types of information that each Block may want to expose to management. * Firstly there is the standard configuration info. Ideally an XSchema could be exposed and managed by JMX via some method. The JMX would then validate the XML and stuff it back into ConfigurationRepository as necessary. Other standard configuration stuff would include the location to which data is logged and possibly other stuff. * Secondly there is extra interfaces that a Block may *choose* to expose to JMX. Not all services need to be or should be automatically exposed. IMO it should be the block that choose which services it wants to expose via JMX. These could either be directly implemented by the Block or implemented by supporting classes. * Thirdly there is the generic management part (ie startup and shutdown of blocks). However as this ought to be controlled by the Application as a whole this should probably be exposed via an ApplicationMBean rather than a BlockMBean -- Cheers, Pete ---------------------------------------------- Money is how people with no talent keep score. ---------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
