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
