Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
From: Hiram Chirino <hiram@coredevelopers.net>
To: geronimo-dev@incubator.apache.org
In-Reply-To: <5249B90B-C9D3-11D7-9516-000A9566A360@coredevelopers.net>
References: <5249B90B-C9D3-11D7-9516-000A9566A360@coredevelopers.net>
Content-Type: text/plain
Message-Id: <1060578607.23471.102.camel@localhost.localdomain>
Mime-Version: 1.0
Date: 11 Aug 2003 01:10:07 -0400
Content-Transfer-Encoding: 7bit

Having developed a few Eclipse plugins, I can attest that Eclipse has a
great plugin system.  

It has a great classloader structure.  I can deploy a plugin and have
it's classloader "import" classes from other plugins.  I can use a set
of filters to define which classes of a plugin are allowed to be
"imported" by other plugins.  

It's deployment registry allows you to lazy load the plugin classes.  No
need to activate a plugin until it's being used.  The deployment
registry allows you to register the "extension points" that your plugin
implements.  For example, there could be a "WebAppDeployer" plugin that
defines a "WebContainer" "extension point".  When a jetty plugin gets
deployed it defines that it implements the "WebContainer" "extension
point".  Since it's all just meta-data, jetty does not really need to be
activated until the "WebAppDeployer" tries to get a instance of one of
the guys that implemented the "WebContainer" extension point.

It also provides each plugin an interface to persist runtime
configuration changes.  Persisting changes have to be done explicitly by
the plugin provider but at least every plugin uses the same
configuration persistence interface.

The down side is that they designed the deployment meta-data registry to
be loaded on startup and then be static after that.  So they do not hot
deploy new plugins or anything like that.  So their stuff will not work
for us well at all but they have implemented some very nice concepts. 
But some eclipse folks are working on changing this.. see: 
http://eclipse.org/equinox/index.html


Regards,
Hiram

On Fri, 2003-08-08 at 15:05, Jason Dillon wrote:
> 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.
> 
> --jason
> 
> 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.
> >
> > 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.
> >>
> >
-- 
/**************************
  * Hiram Chirino
  * Partner
  * Core Developers Network
  **************************/