Noel J. Bergman wrote:
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.
Ok.
--- 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.
Yep, It all matters what supports the project best.
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.
I am curious as to your feelings on HiveMind. I haven't had much look
at it beyond its documentation.
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.
I think almost any of the Avalon containers can satisfy these requirements.
* Small, fast: the Fortress and Merlin containers have a fairly small footprint.
Fortress also supports asynchronous component initialization so that all
components are started up using a controlled number of threads. This
feature will be soon ported to Merlin which looks like a better fit.
* Loose Coupling: The Avalon project has developed all their
components/containers to avoid hard coupling. As long as you code to an
interface, all is well. In fact, the actual implementation of a component
is decided at runtime, not build time. This allows easy upgrades.
* JMX integration: The Avalon Phoenix container is the only one that currently
supports this, but the feature will be ported to Merlin in the near future.
Basically, you can mark a component's interface with some @mx-*** type
javadoc tags, and the container will dynamically build the JMXBeans and
publish them.
* Dependency management: Avalon Fortress, Merlin, and Phoenix all handle this
requirement well. Merlin goes so far as to allow you to specify a service's
version. They each test to make sure all *required* dependencies are
available before starting up. It also accounts for *optional* dependencies.
They also find any *circular* dependencies. In fact, this is probably one
of the most mature areas of the containers.
* Additional layers: There are facilities to extend the lifecycle of components,
and provide runtime features. More info on the exact requirement would be
needed before I can provide more info.
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 think Avalon Merlin has some pretty good features to help in these
areas.
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.
If you would like more info, let me know.
--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.
I can add a feature blurb on the WIKI if you point me to the right page.
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]
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
