geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: JMX as a kernel (was: Re: geronimo and avalon?)
Date Fri, 08 Aug 2003 19:05:48 GMT
I think that it would be best for Geronimo not to use JMX as the 
component bus, but use something else and then adapt JMX to it, as we 
must have JMX support.

That said there are so many different component containers out there, 
it is hard to find the one which suites our needs and/or requires the 
least amount of hacking to get it to function.

I have had a look over several containers, HiveMind being one of them, 
though I have not really spent much time looking at the details.

We need something which is small, fast, can plug in any sort of 
component, which will support linking component instances to avoid any 
hard coupling.  It needs to be able to support elba/jboss style 
deployment and class loading semantics.  It needs to be able to be 
adapted to JMX (possibly other protocols like SNMP too).  It would be 
beneficial if it could provide dependency management as well as 
component state management, or at the minimum be easy to provide layers 
on top which can provide this.  It must not impose many restrictions on 
how it can be used, nor should it impose any other application 
functionality short of managing components.

This is just a rough blurb about the requirements for the geronimo 
component container, I will try to write up something more formal and 
drop it into the wiki in the next day or so... along with the system 
loading, configuration and deployment sub-systems.

I believe that the initial geronimo/elba hybrid will probably use JMX, 
as it already works, but we will want to replace this with a more 
robust system as soon as we can sort out how to build it.  Anyways, I 
will put up some wiki docs and then perhaps some of the folks who are 
more knowledgeable about these different containers can comment.  I do 
not want to reinvent the wheel, but if the wheel does not fit the wagon 
then we may just have to make a new one.


PS. Can someone write up something about the current state of the major 
component containers out there with a feature blurb... no soap boxes, 
just the facts jack.

On Friday, August 8, 2003, at 10:33  PM, Howard M. Lewis Ship wrote:

> 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.
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
>> -----Original Message-----
>> From: Alex Blewitt []
>> Sent: Friday, August 08, 2003 8:55 AM
>> To:
>> 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.

View raw message