avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pratik Patel <prpa...@metalab.unc.edu>
Subject Re: [RT] Avalon Developer Tools
Date Fri, 16 Nov 2001 11:42:30 GMT
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.

>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

>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

>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.


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message