tying together various components w/ gbeans and spring?

[Tim Kettering <ti...@gmail.com>]

hi everyone.. this is more of a "lets fling this into the list and see
if anyone bites" question on architectural ideas/suggestions regarding
tying together an componentized application using geronimo.  hopefully
i dont make this too long-winded.

we've been deploying our product as a single webapp on tomcat, but as
things have gotten bigger and more complex, its become more bothersome
for the developers to constantly have to build and redeploy the whole
damn application when all they did was add a log statement to xyz
class.

so i've been looking into options to make the dev process easier, and
also to break down the application into more modular components (ooh,
a buzzword!), which is something we should be doing anyway.

after looking at servicemix, i ended up at geronimo.. although they're
wholly different beasts, i've started looking at geronimo more closely
to see if it could become the app server of our choice. i like how it
brings together ldap, jms, jta, yadda yadda under a common
umbrealla... i've come up with some stuff to deploy plans, .wars and
all that jazz, and i'm quite excited by the parent-child options that
makes shaping the classloader hiearchy somewhat more elegantly and
spiffy than the tomcat structure alone.

but enough background information, now to the burning questions.  lets
say we have a package of core biz functionality.  call it 
foo-core.jar.   it doesn't relate to the web-ui at all.  i can deploy
this to geronimo as a deployment plan, stick it in the classloader and
give it a configuration name, then deploy a .war file as a child of
that configuration and it'll pick up the classes from the parent. 
that's rather nice.

however i tried redeploying the core .jar again (while the webapp
continues to run) - and it seems to shut down the child web-app when i
do that.  is this standard functionality?  i would have expected it to
reload at least.  i was not able to find any documentation that covers
how gbean lifecycle are affected by parent gbeans.

next thing i looked at was deploying foo-core.jar wrapped around a
gbean as a server module.  i hooked things up so that when foo-core
gets deployed, the internal spring application context in foo-core.jar
is started up and initalized.   my intention then was to somehow
introduce that context into the webapp (and hopefully not having to
use any geronimo specific stuff in the webapp code).

i had been thinking something along the lines of deploying various
application components as gbeans, then the webapp itself could pick up
the references to those gbeans when it starts up.  by components, i
mean foo-core,  ldap reference, a jms reference, and datasource
references, to name a few.

i read up on how to do dependency injection w/ gbeans - and have been
able to accomplish that, but what im wondering is if anyone here has
figured out a good way to get those gbeans included in a spring
context that the webapp starts up as well?

lets say foo-webapp has a spring context that is started up when the
webapp starts up.  ideally i'd like this spring context to be able to
obtain the various gbeans that are set in the server and make them
available as beans in the context.  has anyone done this, or could
anyone offer some ideas/suggestions on how that might be done?

i will continue to work this angle - and share any answers i might by
miracle discover, considering my very amateur understanding of this
geronimo thing here.  :)

-tim

Re: tying together various components w/ gbeans and spring?

[Dain Sundstrom <da...@iq80.com>]

On Feb 24, 2006, at 8:35 AM, David Jencks wrote:

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

Um isn't this what startRecusive does?

We have A <- B with both running.  Stop(A) will stop B then A.   
StartRecursive(A) will start A and then start B.

-dain

Re: tying together various components w/ gbeans and spring?

[David Jencks <da...@yahoo.com>]

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

Re: tying together various components w/ gbeans and spring?

[Tim Kettering <ti...@gmail.com>]

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?

Re: tying together various components w/ gbeans and spring?

[Dain Sundstrom <da...@iq80.com>]

On Feb 17, 2006, at 11:49 AM, David Jencks wrote:

> On Feb 17, 2006, at 10:50 AM, Tim Kettering wrote:
>
>> lets say foo-webapp has a spring context that is started up when the
>> webapp starts up.  ideally i'd like this spring context to be able to
>> obtain the various gbeans that are set in the server and make them
>> available as beans in the context.  has anyone done this, or could
>> anyone offer some ideas/suggestions on how that might be done?
>>
>
> Dain has some ideas on how to do this generically.  Right now it is  
> not very convenient.  An example of something you can do is in  
> trunk in the Spring module where there's a spring bean that more or  
> less wraps our TransactionContextManager gbean.

In the xbean code we have spring bean factories that expose Geronimo  
services to Spring, but I don't expect that code to be integrated  
into Geronimo for several months (assuming that community wants it at  
all).

> Note that depending on the circumstances you might be able to use  
> JNDI. (not that I recommend JNDI for much of anything :-).    The  
> stuff specified in a web app's jndi specification will be  
> accessible in any thread that goes through that web app.  Therefore  
> if you don't need to access geronimo services (gbeans) during the  
> spring startup but only when in use from a web app, you can look up  
> stuff like datasources.

I'd like to be able to expose generic geronimo service via the J2EE  
enc, but never got around to adding the configuration code necessary  
to make it happen :(

>> i will continue to work this angle - and share any answers i might by
>> miracle discover, considering my very amateur understanding of this
>> geronimo thing here.  :)
>
> This is definitely an area we are interested in making easier :-)

+1

-dain

Re: tying together various components w/ gbeans and spring?

[David Jencks <da...@yahoo.com>]

On Feb 17, 2006, at 10:50 AM, Tim Kettering wrote:

> hi everyone.. this is more of a "lets fling this into the list and see
> if anyone bites" question on architectural ideas/suggestions regarding
> tying together an componentized application using geronimo.  hopefully
> i dont make this too long-winded.
>
> we've been deploying our product as a single webapp on tomcat, but as
> things have gotten bigger and more complex, its become more bothersome
> for the developers to constantly have to build and redeploy the whole
> damn application when all they did was add a log statement to xyz
> class.
>
> so i've been looking into options to make the dev process easier, and
> also to break down the application into more modular components (ooh,
> a buzzword!), which is something we should be doing anyway.
>
> after looking at servicemix, i ended up at geronimo.. although they're
> wholly different beasts, i've started looking at geronimo more closely
> to see if it could become the app server of our choice. i like how it
> brings together ldap, jms, jta, yadda yadda under a common
> umbrealla... i've come up with some stuff to deploy plans, .wars and
> all that jazz, and i'm quite excited by the parent-child options that
> makes shaping the classloader hiearchy somewhat more elegantly and
> spiffy than the tomcat structure alone.
>
> but enough background information, now to the burning questions.  lets
> say we have a package of core biz functionality.  call it
> foo-core.jar.   it doesn't relate to the web-ui at all.  i can deploy
> this to geronimo as a deployment plan, stick it in the classloader and
> give it a configuration name, then deploy a .war file as a child of
> that configuration and it'll pick up the classes from the parent.
> that's rather nice.
>
> however i tried redeploying the core .jar again (while the webapp
> continues to run) - and it seems to shut down the child web-app when i
> do that.  is this standard functionality?  i would have expected it to
> reload at least.  i was not able to find any documentation that covers
> how gbean lifecycle are affected by parent gbeans.

We've recently found some bugs in this area and it is likely to be  
affected by the work we are doing in the configid branch that should  
be included in the next (1.1) release.

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.   
Something appears to be broken with this process.  I think it would  
be worth trying stopping the web apps, then stopping the core config,  
changing the core, starting the core, starting the web app.  In any  
case:  we don't support keeping a classloader running while you  
change its parents, nor are we likely to.  However we do intend to  
make the process outlined here more reliable.


>
> next thing i looked at was deploying foo-core.jar wrapped around a
> gbean as a server module.  i hooked things up so that when foo-core
> gets deployed, the internal spring application context in foo-core.jar
> is started up and initalized.   my intention then was to somehow
> introduce that context into the webapp (and hopefully not having to
> use any geronimo specific stuff in the webapp code).
>
> i had been thinking something along the lines of deploying various
> application components as gbeans, then the webapp itself could pick up
> the references to those gbeans when it starts up.  by components, i
> mean foo-core,  ldap reference, a jms reference, and datasource
> references, to name a few.
>
> i read up on how to do dependency injection w/ gbeans - and have been
> able to accomplish that, but what im wondering is if anyone here has
> figured out a good way to get those gbeans included in a spring
> context that the webapp starts up as well?
>
> lets say foo-webapp has a spring context that is started up when the
> webapp starts up.  ideally i'd like this spring context to be able to
> obtain the various gbeans that are set in the server and make them
> available as beans in the context.  has anyone done this, or could
> anyone offer some ideas/suggestions on how that might be done?
>

Dain has some ideas on how to do this generically.  Right now it is  
not very convenient.  An example of something you can do is in trunk  
in the Spring module where there's a spring bean that more or less  
wraps our TransactionContextManager gbean.

Note that depending on the circumstances you might be able to use  
JNDI. (not that I recommend JNDI for much of anything :-).    The  
stuff specified in a web app's jndi specification will be accessible  
in any thread that goes through that web app.  Therefore if you don't  
need to access geronimo services (gbeans) during the spring startup  
but only when in use from a web app, you can look up stuff like  
datasources.

> i will continue to work this angle - and share any answers i might by
> miracle discover, considering my very amateur understanding of this
> geronimo thing here.  :)

This is definitely an area we are interested in making easier :-)

thanks
david jencks

>
> -tim