Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <42093587.2060508@coredevelopers.net>
References: <42088C8A.2020908@coredevelopers.net>
 <4d0d67ec44c11402a73de977b503b66f@gluecode.com>
 <42093587.2060508@coredevelopers.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <cfe81ae49af5c792f1c7cc4894eb8fcb@gluecode.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dsundstrom@gluecode.com>
Subject: Re: Spring integration...
Date: Tue, 8 Feb 2005 16:31:53 -0800
To: dev@geronimo.apache.org

On Feb 8, 2005, at 1:56 PM, 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.

Ah, we are talking in two different languages.  The gbean instance 
controls when objects are construcgted and ultimately dereferenced.  
Notifying user code is not what I consider the core of life-cycle

>> 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 disagree. It fundamentally and forever changes the encapsulation 
model.  I do not think this is something to take lightly.  This could 
definitely paint us into a corner. Also, there _are_ assumptions in the 
code proxies, registries, references and so on, (not docs, not 
interfaces) on exactly when a gbean can be referenced and when it can 
not.  Changing this is very likely to introduce very sublet errors and 
memory leaks.

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

It is small in the scope of what gbeans do... and you can double wrap

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

Right.  And that is something we can address at a later date.

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

Thanks.  I definitely think we should think about this after 
certification, and in the much bigger light of all ioc containers.

-dain