geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Geronimo/Spring integration - configurations?
Date Wed, 09 Feb 2005 10:49:34 GMT
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.
 **********************************/


Mime
View raw message