geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Global Spring ApplicationContext
Date Sat, 07 Apr 2007 18:11:12 GMT

On Apr 7, 2007, at 10:48 AM, Richard Wallace wrote:

> Hello,
>
> In an application we are in the planning stages of we are trying to
> figure out how to deploy it.  We've all but officially said that we
> are going to be using Geronimo for our application server.  The
> application will consist of many webapps that use Struts 2 and
> Spring.  There will be some shared components that all the webapps
> will need access to like email services, persistence, and other
> components.  We've been exploring the idea of having a shared Spring
> application context to achieve this.  Most of our work so far has been
> based on the architecture that Sakai uses.
>
> The way Sakai works is that certain APIs and other jars are put in the
> /shared/lib directory of Tomcat.  When the first webapp loads up a
> special extended Spring ContextListener starts up and initializes the
> component manager.  The component manager loads up a shared
> ApplicationContext with components that are in the
> ${CATALINA_HOME}/components directory.  This components directory
> contains a directory for each component that should be started up.
> The layout is similar to that of a webapp, except instead of a web.xml
> there is a components.xml which is a standard Spring beans xml
> descriptor.  Each component is loaded in it's own separate classloader
> so any versioning problems between jars they depend on will be
> isolated and not cause issues.  The components are put in the shared
> ApplcationContext and available to all the webapps which have their
> own ApplicationContexts which are children of the shared context.
> This way, the shared components are available to the webapps and
> Spring can do its dependency injection in the usual way.

So do the components implement interfaces that are in a shared  
classloader, so any app with that classloader as parent (or  
equivalent) can use the components?  Or is there some other way of  
using the components?

>
> What I want to do is figure out a way to do the same thing in an EAR
> file.  I was thinking of just packaging up the components in jar files
> and putting the components.xml files in their META-INF directories.
> Then the component manager could scan the jars on the classpath and
> look for these components.xml files and load the components into the
> shared ApplicationContext that way.  The problem is that then all the
> jars that the components depend on would need to be in the EAR itself
> and wouldn't be in separate classloaders, possibly causing versioning
> conflicts.
>
> I've seen some references to Geronimo and Spring integration, but I
> haven't been able to find any documentation or examples showing how to
> use it.  I've seen some references to META-INF/spring.xml and
> geronimo-spring.xml files, but nothing really describing how they work
> or what they do.  I saw the SpringGBean in the APIs, but there's not
> much documentation to say what it does.  Does this maybe already solve
> my problem?  Can anyone point me to more information about how to  
> use it?

Geronimo-spring integration is usually a bunch of half-tested  
components from several years ago because no one has figured out what  
it should actually do.  Most people seem to want to start one  
instance of spring from a web app and do nothing more complicated,  
which doesn't require any extra integration.  Eventually someone was  
bound to have more interesting requirements.... and here you are :-)

>
> If that's not going to help, I thought about maybe loading the
> components the way Sakai used to do it, where the components are in
> actual webapps and they are loaded before the other webapps.   This
> means that the order in which webapps are loaded is important,
> something that couldn't be controlled in a cross-platform way which is
> why they moved to the new "whichever webapp loads first causes the
> shared context to be loaded" methodology.  But I'm not sure if you can
> control the order in which webapps are loaded in Geronimo, can you?
> Even if you can, I'm not sure this is an ideal solution.
>
> The final solution I thought of for creating this shared application
> context and loading components with separate classloaders is to maybe
> try and create some kind of custom package that I can put into the EAR
> file and have the component loader look for and load it up that way.
> Maybe just a .jar file with a META-INF/components.xml and a lib/
> directory or something.  But I'm not 100% sure of how I could get that
> to work.
>
> If anyone has any ideas or thoughts about creating this shared Spring
> application context I'd love to hear them.
>

I'll describe the most geronimo centric way of doing this, and you  
can tell us what is wrong with this plan :-)

So, in geronimo we have modules which are basically a classloader +  
services.  Each module can have multiple parent modules: in  
particular this means each classloader can have multiple parents.

IIUC the requirements, you want one classloader/module that has the  
shared component interfaces, and runs a single spring instance.
Then you have numerous component modules, each providing  
implementations of services whose interfaces are in the shared module.
Finally you have numerous web apps all of which need access to the  
services but which should not be able to access the service  
implementation classes directly.

As far as modules/classloaders this is easy to set up in geronimo.   
For each module you just need a plan that specifies the jars and  
parents as dependencies.  The geronimo-web plans for the web app  
would include the shared module as a dependency.

I don't know enough about Spring to know how to set up the  
implementation module registration with the spring instance.  What I  
would try to do is:

- write a spring "server" gbean that would be configured in the  
shared module that would start the spring "server" and await  
registrations from the implementation  modules
- write a spring "plan registration" gbean that would be configured  
in each of the implementation modules that would find the appropriate  
spring plans for the module and register/start/whatever-the-correct- 
word-is them with the spring "server"

Do you need to assure that particular services start before  
particular web apps?  This can be assured in one way by the order in  
which the modules are started.  If you need something more robust so  
that startup will fail if someone tries to start things  in the wrong  
order we might have to add something to let you specify web app  
dependencies directly.

I've been wanting something like this for relatively complicated  
spring apps such as jetspeed2....

Hope this helps

thanks
david jencks




> Thanks,
> Rich
>


Mime
View raw message