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?
yes
or
will Geronimo cascade stop all the children, then restart them after
the parent is done?
no
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.
thanks
david jencks
