geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Remijan <remi...@ncsa.uiuc.edu>
Subject RE: JMX as a kernel (was: Re: geronimo and avalon?)
Date Fri, 08 Aug 2003 15:50:50 GMT
I completely agree with configuring MBeans becomes ad-hoc ugliness.  JBoss 
has done a good job trying to clean up the server's configuration files but 
they are still difficult.  The main problem is that MBeans configurations 
do not need to adhear to a DTD or Schema.  That makes it very difficult to 
find out what can be put in the configuration file in the first place.

Mike


At 11:33 AM 8/8/2003 -0400, 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.
>
>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.
> >



Mime
View raw message