Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "Howard M. Lewis Ship" <hlship@comcast.net>
To: <geronimo-dev@incubator.apache.org>
Subject: RE: JMX as a kernel (was: Re: geronimo and avalon?)
Date: Fri, 8 Aug 2003 11:33:28 -0400
Message-ID: <001201c35dc2$6d539a60$fa040a0a@ALMIGHTYBEAST>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <7F6D540A-C99F-11D7-B192-0003934D3EA4@ioshq.com>
Importance: Normal

I'm going to plug HiveMind again here.

Looking over what JBoss has done with JMX as a Microkernel, I have a couple of key issues.

First off, the code abstraction that requires you to invoke methods on MBeans using an interface
like reflection.  Yes, there are workarounds to that (such as using dynamic Proxys) but if a Java
object is invoking a method on another Java object within the same JVM why make it look like some
low-level RPC call?

Second, configuration of MBeans leaves a bit to be desired.  I suppose it works well for simple
properties, but once you get to anything complicated, you start seeing more and more ad-hoc
ugliness.  Among other things, you end up endlessly rehashing the code to translate an MBean name
into an instance that methods can be invoked on.

Intrinsic to HiveMind are concepts adapted from Eclipse Plugins: extension points and extensions.
Extension points define a point where modules can plug into other modules; an extension point
defines a kind of XML schema for contributions.  Extensions are snippets of XML that plug into
extension points.

The end result is something very flexible, and very supportive of a very complex environment, yet
very "lean and mean" at the same time.

http://jakarta.apache.org/commons/sandbox/hivemind

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry


> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com] 
> Sent: Friday, August 08, 2003 8:55 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
> 
> 
> 
> On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote:
> 
> > Why JMX Is Not A Very Good Kernel
> > ------------------
> 
> I'd definitely concur with this. Put it better than I could 
> have done, 
> too :-)
> 
> Note that just because JMX isn't a kernel, doesn't mean that 
> some parts 
> of it can't be configured with JMX on top. It just means that not 
> everything has to be JMX.
> 
> Building a tighter smaller kernel gives me a gut feeling that it will 
> run faster, though I've yet to convert that into measurable 
> figures :-) 
> But reducing (unnecessary) layers is bound to speed it up...
> 
> One fear I have of using JMX as a kernel is that all the intra-kernel 
> messages would be sent using JMX. If JMX isn't used in the 
> kernel, then 
> they can be made more efficient/optimised; but JMX can be put as a 
> layer on top of the features (e.g. EJBs) that need 
> configuring/managing 
> by JMX.
> 
> Definitely vote +1 for not using JMX 'just because'
> 
> Alex.
>