geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Harrop <r...@cakesolutions.net>
Subject Re: Spring integration...
Date Tue, 08 Feb 2005 22:16:17 GMT
I'm going to agree with Jules on this - adding another layer of proxies 
in here is not a particularly good idea nor is it something we know will 
even work. If Spring has already supplied a CGLIB proxy, then we cannot 
proxy it again directly. We will have to create a lot of workarounds for 
this when can essentially achieve this functionality with a small amount 
of code in the kernel.

Rob

Jules Gosnell wrote:

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

Mime
View raw message