Jeremy Boynes wrote:
Jules Gosnell wrote:
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)?
long running services - the SpringGBean will do a kernel load and a kernel start on each one at the start-time of the module and a kernel stop and unload on each one at module stop-time.
This is exactly what a Configuration does to the GBean it contains - do you think there is a way we can package a set of Spring components into a Configuration?
The state portion of a Configuration comprises of: * GBeanInfo describing classes of GBeans * GBeanData describing instances of GBeans, with the values of their persistent attributes
When a Configuration starts, it loads GBeans into the kernel for each GBeanData present which:
1) instantiates the target instances,
2) initializes them with their persistent attributes via CDI or SDI, and
3) leaves them in the STOPPED state;
If startRecursive is used then the kernel will also attempt to start them.
In an closely integrated world, a Spring builder would be able to convert all Spring components into persistent GBeans that can be placed into a Configuration. That Configuration could then run in any server containing just the runtime components it needed and you would not need to handle the runtime load,start,stop,unload,fail operations for every component.
I agree with all of this. unfortunately, in pre-Geronimo days, containers did not tend to perform this native-component->GBean precompilation, so I think it unlikely that Spring will separate the two stages as cleanly as we would like. With the initial integration I have gone for the path of least resistance, which is to do everything in the runtime, since it is tricky to push it back to configration time. I will be looking, with the Spring team's help, at pushing more and more back to this stage. Ultimately, however, I think it unlikely that we will be able to come up with a perfect solution as it would mean that all the POJOs would have to serialisable (wouldn't they? - so that they can be built, preconfigured and stashed during the configuration phase, then unmarshalled and started up at runtime...). The lack of start/stop in a POJOs lifecycle would also make this awkward, I would imagine. Which is why I have mapped GBeanInstance.start() to POJO construct() and GBeanInstance.stop() to the releasing of all the POJO references.
Does this make sense ?
Jules
-- Jeremy
-- "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. **********************************/
