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
