geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Spring integration...
Date Tue, 08 Feb 2005 21:56:23 GMT

Dain Sundstrom wrote:

> I am definitely against this change.  A fundamental assumption of the 
> current GBean code is it controls life-cycle,

in GBeanInstance without my patch:

the 'target' field is typed 'Object', not GBeanLifecycle.

doStart() contains:

            if (target instanceof GBeanLifecycle) {
                ((GBeanLifecycle) target).doStart();

doStop() contains:

            if (target instanceof GBeanLifecycle) {
                ((GBeanLifecycle) target).doStop();

doFail() contains:

            if (target instanceof GBeanLifecycle) {
                ((GBeanLifecycle) target).doFail();

in fact - these are the only relevant mentions of GBeanLifecycle in the 
file. Seeing as you have already impressed on us the importance of 
GBeanInstance totally encapsulating the target reference, I expect that 
it is not accessible anywhere else... So, I disagree. There is no 
assumption that the target must implement GBeanLifecycle i.e. 'be' a GBean.

> and I believe changing this would have a massive impact on the entire 
> GBean architecture.

I don't. Once the target is instantiated I don't see it mattering where 
it comes from as long as the code managing its lifecycle ensures that 
the kernel has access to the correct classloader and the kernel is kept 
up to date with the state of the Bean - i.e. someone calls 
start/stopGBean() and load/unloadGBean() at the correct times. Only 
people who need this fn-ality (me) will use it, and they will be 
entirely responsible for the outcome of their actions.

>   I do believe that you could get it to work for your small use case,

not small - pretty huge - the ability to make any POJO transparently 
manageable by the kernel.

> 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 agree that the delegation model _may_ be possible and I guess I will 
now have to go round the houses and implement exactly the same thing in 
this way. For the record, though, I think that this is a bad idea. Layer 
upon layer of proxies (The proxy that I shall have to supply will sit on 
top of other Spring proxies etc...) can only add confusion to 
stacktraces and take the JVM to seldom visited code paths... I expect 
that loading one of these into the kernel will be far more risky than a 
naked POJO.

> 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.

OK and understood - I shall make do with what I have. if it is not 
enough, then the Spring integration will just have to wait its turn.


> -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.

View raw message