I think you are confusing jmx and lifecycle management.
Jetty exposes some mbeans, but the mbean server AFAICT has nothing to do with creating/destroying jetty components. In fact it looks to me as if the jetty mbeans are viewers that are completely independent of the components that are doing the work.
It's really easy to take an mbean and make it look like a gbean, that is expose the same attributes and operations. This has nothing to do with the work the geronimo kernel does to manage lifecycle, namely creating and destroying gbeans, and managing references between them. There is no jmx concept that is very similar to a gbean reference.
However, in order to expose an mbean as a gbean AND get it in geronimo, you have to be able to create the object in a somewhat unconstrained way -- basically as you would want to in an IOC container. Jetty lifecycle management is extremely intrusive and makes this difficult to achieve. I haven't looked at tomcat.
It seems to me that if a project has their components exposed as mbeans, and they have a clean separation between the deployment/construction/wiring code and the components themselves, it should be very easy to simply wrap the components as gbeans and deploy them in geronimo. If there's a substantial deployment step, writing a builder to construct the gbean configurations is also quite doable. Even though these aspects are somewhat mixed together in jetty, it was not all that hard to separate the phases, expose the components as gbeans, and write a builder.
The tricky part here is we are thinking of taking a completely separate container and integrating it with geronimo. Both are fighting over the lifecycle stuff: if we can figure that out then exposing the running components as gbeans will be easy.
thanks david jencks
On Feb 8, 2005, at 4:31 PM, Jules Gosnell wrote:
Jeremy Boynes wrote:
Jeff Genender wrote:
I think Jules has a point on this. What about the use of other open source projects that manage thier own private mbean lifecycles, such as Tomcat?
Well, the obvious question is how does that integrate with a Geronimo kernel that is not based on JMX?
see my reply to David.
A significant portion of the Tomcat underbelly infrastructure is managed this way.
In the debugconsole, I can see the Tomcat created mbean objects. But when I try to manage them (view, etc), the debugconsole throws an Exception that the object is not a gbean. I don't know of this is directly related, but it would be nice for gernimo to allow the plugged in components to manage thier own mbean lifecycles, and to be exposed.
I would say this is an artifact of mixing two different component models in the same MBeanServer. They should either be separated or more closely integrated.
see my reply to David - I think the onus is on Geronimo to meet integrating parties once, particularly when they implement the J2EE standard management interface, rather than leave each integration to do its own thing, with all the likely incomprehensible and duplicate code that this would involve.
Jules
-- Jeremy
-- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it."
/********************************** * Jules Gosnell * Partner * Core Developers Network (Europe) * * www.coredevelopers.net * * Open Source Training & Support. **********************************/
