and have been thinking about how we can incorporate JMX into Avalon.
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.' 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).
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.
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.
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). Blocks should then be forced
to implement the MBean interface; 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.
cheers Pratik
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
