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
|