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.
