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