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:45:30 GMT
David Jencks wrote:

> On Feb 8, 2005, at 4:06 PM, Jules Gosnell wrote:
>> Jeff Genender wrote:
>>> I think Jules has a point on this.  What about the use of other open 
>>> source projects that manage their own private mbean lifecycles, such 
>>> as Tomcat?
>> and not forgetting Jetty :-), which also exposes internals to JMX in 
>> this way - relevant parts of which, I expect, implement the relevant 
>> J2EE JSRs and would want to be made available to suitable tooling.
> As far as I can tell jetty exposes some information via jmx but this 
> has nothing to do with component lifecycle in jetty.

?? i may be out of date, Jetty may have bent over backwards to integrate 
with geronimo, but the point still stands. Any integrating 3rd party s/w 
may dynamically create and destroy MBeans at runtime that wish to be 
managed/monitored by the kernel. The lifecycles of these components are 
not managed by the kernel, but by the 3rd party s/w. Unless you are 
saying that because their lifecycle is bounded by that of this component 
they are controlled by geronimo, which was my point regarding Spring at 
the very outset of this thread :-)

> One problem with at least jetty's native lifecycle management is that 
> it does not fit with the geronimo concept of separating the steps of 
> processing the deployment descriptor xml into component configurations 
> and actually starting the configurations in a possibly separate 
> server.  For this and several other reasons I replaced jetty 
> deployment descriptor processing and lifecycle management with a 
> jetty-builder and gbeans for individual jetty components.  I 
> anticipate that the same process will be needed for tomcat, and I was 
> assuming a similar process would be used for Spring.  I haven't 
> understood yet why this is a bad idea for Spring.

we are talking at cross purposes. i am not talking about deployment 
module lifecycle but runtime component lifecycle, as i have always been 
- maybe i have not expressed myself well ? If you check out my reply to 
Jeremy i have explained why Spring is awkward in this respect. maybe we 
can get over this. Perhaps Rob will come up with something.

>> If all goes well with a proxy approach, this fn-ality will go into 
>> the Spring integration anyway, with a switch to disable it for the 
>> faint-hearted. So, either way, the kernel will be managing POJOs 
>> whose life-cycle it does not control. It's just a matter of how 
>> complex the code has to be and how many levels of proxy we want...
> I think one layer of proxy is plenty, but that 2 lifecycle managers is 
> extremely unlikely to work.  IMO this requires a lot of careful thought.

But I have thought about it :-), implemented it and tested it (to a 
certain extent...)

One GBean represents the Spring app. It bounds the lifecycle of all its 
subcomponents which may wish to be exposed via the kernel. It's 
lifecycle is controlled by Geronimo. This GBean is responsible for 
keeping the kernel informed of the creation and destruction of it's 
components - anything goes wrong, you point the finger at the 
SpringGBean, because it has failed to maintain this protocol.

I will go back to Rob and we will discuss the possibility of doing all 
the GBean mapping at Configuration time. I suspect that this will 
involve major restructuring of Spring, because you are splitting in half 
what it does when it fires up an app, but then i am not a Spring expert....


> thanks
> david jencks
>> Jules
>>> 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.
>>>>> **********************************/
>> -- 
>> "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.
>> **********************************/

"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