geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Spring integration...
Date Wed, 09 Feb 2005 00:28:34 GMT
David Jencks wrote:

> That's a somewhat different issue.  The Tomcat mbeans are basically 
> completely unknown to geronimo.  If we started the kernel with the 
> BasicGBeanRegistry rather than the JMXGBeanRegistry you'd never know 
> they were there.

That's not to say that they are not needed though - Jetty, as I expect 
Tomcat does, provides a J2EE management interface through the correct 
APIs published via the JMX API on a number of it's internal components. 
Geronimo's webcontainer management interface would be incomplete without 
these - thus they should be made available through the kernel. na matter 
what configuration you are running.

> If you wrapped the tomcat mbeans as gbeans, then you'd have a similar 
> issue when you tried to decide if you wanted to use the tomcat 
> lifecycle or replace it with the geronimo lifecycle.

You would put the relevant listeners on them such that they were 
registered with the kernel after creation and removed before 
destruction. They would not be created before the Jetty/Tomcat service 
was deployed, or destroyed after it had been destroyed.

> At this point I think that having 2 dependency/lifecycle systems 
> trying to manage the same objects is a disaster waiting to happen.  My 
> current bias is to remove the other guys dependency/lifecycle 
> management and do all of that through geronimo/gbeans.

??? lost you here - are you saying rewrite Tomcat and Jetty because they 
implement the standard J2EE management interface and Geronimo doesn't ?

> If we don't do that, I think we will have to do something like 
> installing the other guys dependency/lifecycle manager as a full gbean 
> and exposing all the other objects it creates as unmanaged 
> partial-gbean wrappers where geronimo does nothing with the 
> lifecycle.  I don't have any idea how safe it would be to expose 
> attribute writes and operations on such objects.

So, rather than dismiss it out of hand when we have no idea what it 
involves, why don't we drill down a little and see just what it would 
entail ?



> thanks
> david jencks
> On Feb 8, 2005, at 3:50 PM, 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?
>> 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.
>> Jeff
>> Dain Sundstrom wrote:
>>> I am definitely against this change.  A fundamental assumption of 
>>> the current GBean code is it controls life-cycle, and I believe 
>>> changing this would have a massive impact on the entire GBean 
>>> architecture.  I do believe that you could get it to work for your 
>>> small use case, but I believe that the impact will be much larger 
>>> then a small use case.  Further, I believe that you can use a 
>>> delegation model to achieve this today without a kernel patch.
>>> I'm not saying that this should never change, but that this is not 
>>> the time.  After certification, I would like to spend time 
>>> rethinking the GBean architecture.  Specifically, I'd like to make 
>>> it trivial to integrate Spring, Avalon, Pico, etc. components, and 
>>> I'd like to make it easier to program with GBeans.  This means, 
>>> taking a second look at the info object, data object, xml 
>>> configuration, persistence, dispatching and life-cycle.  Anyway, 
>>> this is something I believe can wait.
>>> -dain
>>> On Feb 8, 2005, at 1:55 AM, Jules Gosnell wrote:
>>>> So, Guys,
>>>> I've given you a few days to look over the minimal kernel patch.
>>>> As I understood it we left the thread with two real options :
>>>> 1) extend the kernel to allow acceptance of an existing object for 
>>>> proxying via GBeanInstance, rather than always constructing such 
>>>> objects itself.
>>>> 2) submit a dynamically crafted class and required instance (as 
>>>> constructor arg for said class). when class is instantiated and 
>>>> injected result will be a proxy that is [largely] semantically 
>>>> identical to (1). We must be able to proxy non-interfaces and final 
>>>> methods.
>>>> To summarise the debate over the two options :
>>>> against (1), for (2)
>>>> understandable reticence to change the kernel
>>>> concern over the kernel losing explicit ownership of the life-cycle 
>>>> of the object that it is managing
>>>> for (1), against (2)
>>>> we are talking about an extension, not a backwardly incompatible 
>>>> change to the kernel
>>>> I have demonstrated that such an extension would have minimal 
>>>> footprint and implication
>>>> (2) does not restore lifecycle ownership to the kernel
>>>> (2) is complex, less efficient and will need to be repeated 
>>>> anywhere someone needs this fn-ality
>>>> (1) is simpler, more efficient and will only need to be done once
>>>> Finding a resolution to this is, IMHO, critical to the Spring 
>>>> integration. Otherwise I would let it go.
>>>> I had a very similar problem integrating two other well known 
>>>> pieces of open source some time ago. The host had a JMX kernel and 
>>>> the thing that I was embedding had internal MBeans with their own 
>>>> private lifecycles. I persuaded the powers-that-were to allow 
>>>> MBeans that were not managed by the kernel to be exposed via it. A 
>>>> change was made. The extension to the kernel was never rescinded. 
>>>> In fact, at least one other integration now makes use of it. It 
>>>> enabled embedded components to open themselves up to the services 
>>>> supplied by the kernel in a way that could not be done before...
>>>> I humbly await your judgement :-)
>>>> Jules
>>>> -- 
>>>> "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.
>>>> **********************************/
>> -- 
>> Jeff Genender

"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