Might I suggest that Berin and Stephen pop over to geronimo-dev and talk
about how the Merlin technology supports this vision?
You might also want to add it to the AvailableTechnologies page under the
ApacheJ2EE project Wiki.
--- Noel
-----Original Message-----
From: Jason Dillon [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 15:06
To: [EMAIL PROTECTED]
Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
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:[EMAIL PROTECTED]
>> Sent: Friday, August 08, 2003 8:55 AM
>> To: [EMAIL PROTECTED]
>> 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.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
