geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: tying together various components w/ gbeans and spring?
Date Fri, 24 Feb 2006 16:35:50 GMT

On Feb 24, 2006, at 7:36 AM, Tim Kettering wrote:

> Thanks for the excellent responses.  So quickly too.
> I thought something was funky w/ the gbean lifecycle.. and I'll be
> trying out some nightlys to see how the fix is coming along.  One
> thing I wanted to ask however was this particular part you mention:
>> What should happen is that if you shut down the core config (to
>> change some classes) the child web app(s) also stop, and that after
>> you restart the (modified) core config you can restart the child
>> webapps and get the new classes in the parent classloaders.
> Does this mean I have to manually restart all the stopped children?

> or
> will Geronimo cascade stop all the children, then restart them after
> the parent is done?
>   i think the latter functionality would be useful,
> unless i'm not seeing a good reason this shouldn't occur.  (or at
> least a configurable option?)

I've never been able to figure out a reasonable way for this to work,  
maybe someone else has better thinking on the subject. Here's the  
problem I see:

Two configurations , A and B, B is a child of A.  We start with both   
A and B started.

Stop A, this should stop B first.

Now I want to stop B, so when I restart A, B does not restart.

Anyone see how to make this work?
> As for exposing via JNDI.  I agree with you that I want to avoid this
> if possible.  It makes for testing more complicated as well.  I would
> like the functionality to somehow expose GBeans to an spring context
> very much!
> If there is anything I can do to help on that end (yeah, I would love
> to contribute a patch, if I was even half as smart as most of you).
> But maybe I could with some help...
> -tim
> I did not expect Geronimo to have the functionality to hotswap the
> classloader, as you mention there are no plans for that.  I was asking
> more along the lines of how the parent relationship affects children
> in terms of lifecycle.
> So venturing out on a limb here to speculate... if i deploy
> foo-core.jar as a deployment plan, it gets deployed to geronimo
> wrapped as a gbean instance.  then when i deploy foo-webapp.war as a
> child to the previous, it is also wrapped as a gbean instance too.  so
> when i redeploy foo-core.jar via the deployer, it calls "stop" on the
> existing gbean, and all its children (and so forth).  Then when the
> parent starts up again, does it call 'start' on all the children
> GBeans?

There are 2 layers here, there are configurations (which are gbeans)  
and each configuration has gbeans inside it.  The configurations  
correspond to classloaders.  When you start a configuration (using  
the configuration manager) it sets up the classloader and starts all  
the gbeans inside it.  It has no effect on any configurations that  
are children of the current configuration, or the gbeans inside any  
child configurations.

In the configId branch we are about to introduce a feature of  
"required child configurations" that will let a config have some  
child configurations that are automatically started whenever the  
parent is started.  This will let you have sets of configurations  
that act as a unit.  I haven't figured out what should happen if you  
stop a child config: I'm tempted to have it stop the parent as well,  
but I don't have a strong feeling on this yet.  So far I have no  
plans to make this user-configurable, it will at first be only used  
for web apps in an ear.  We could try to figure out how to expose it  
to e.g. gbean plans as well if it seems valuable.

david jencks

View raw message