The intent behind GBeans is that they are long running services - for example, running for the lifetime of an application. Is that how Spring would be using them or are you trying to create/delete instances frequently (say on each web request)?
I didn't see anything in the patch about unregistering an instance - how would that happen?
Is the target really the user's POJO or is it a Spring proxy? If the latter, doesn't it have final methods which would cause a problem for Geronimo trying to create proxies to it when it is referenced by other GBeans? If the former, is there a problem with having two proxy stacks (Spring's and Geronimo's)?
Doesn't the instance get double initialized - once via Spring and then again via setter injection from the GBeanData?
To what extent is it necessary for Spring to register the actual POJOs at runtime? How much can be built before hand and be packaged into a Geronimo Configuration?
To me, the challenges here are not in the lifecycle but in how references between objects are handled. I would have thought some level of proxy integration would also be needed with integration at this low a level.
Thanks -- Jeremy
Jules Gosnell wrote:
I enclose a minimal (15 lines changed/added) patch to the kernel which allows a POJO to be passed via Kernel.loadGBeanProxy(). This POJO is subsequently used as the target of the ensuing GBeanInstance. If the target is already initialise, the GBeanInstance does not bother to construct a fresh instance of its target's class, it just uses the one it has been given.
Pros:
It allows existing POJOs to take advantage of management and monitoring services provided by the kernel.
Cons:
person providing this POJO needs to be careful about managing its lifecycle - it must be loaded into the kernel after construction and unloaded before destruction. If it implements GBeanLifecycle the relevant methods will be called at the relevant time.
Thoughts:
This is really a minimal patch, designed to demonstrate exactly what I am talking about in the simplest manner. It should be immediately obvious that if no target is supplied the codepath will be completely unchanged. The path, if you do supply the target is suboptimal, many lines are still executed finding constructors and arranging parameters for them when they will never be called. Making the current requirement for target classes to provide accessible constructors conditional on whether a preconstructed target is not supplied will take a little more effort, but I don't see any real issue with this.
