geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Spring integration...
Date Wed, 09 Feb 2005 00:57:04 GMT
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.

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)
> *
> *
> *
> * Open Source Training & Support.
> **********************************/

View raw message