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?) 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?
