geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Spring integration...
Date Wed, 09 Feb 2005 00:24:09 GMT
Except that is not now Geronimo creates proxies.  Geronimo creates a 
proxy of any type the referencing code asks for.  This proxy delegates 
all calls to the kernel which in turn invokes the gbean instance.  The 
means that we are not proxying a proxy directly.  This means the proxy 
is totally decoupled from the target.  The target doesn't even have to 
implement the desired interface, it just needs to have the same 
methods.

BTW, why can't spring give the gbean a raw object?  Why would we ever 
get a proxy from Spring?

-dain

--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

On Feb 8, 2005, at 2:16 PM, Rob Harrop wrote:

> 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