geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <>
Subject Re: Global Spring ApplicationContext
Date Sun, 08 Apr 2007 00:43:11 GMT
David Jencks wrote:
> 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?
You've got it.  The components implement interfaces that are in the
top most classloader for the application and available across all
component implementations and webapps.
>> 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 :-)
I've looked at what is currently there for the Spring integration, and
while the details are a bit over my head at the moment, I think it's
generally the direction that I want to go, but doesn't seem to have
the shared application context AFAIK.  I'd be interested to here what
Aaron Mulder has to say, since he's the one that was working on that code.
>> 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.
Yup, that's it exactly.
> 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.
Hmm.. still learning about Geronimo and deployment plans and what
not.  Why would the geronimo-web plans need to specify the shared
module as a dependency?  To make sure it's configured and setup before
the webapp?
> 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"
Ok, it looks like the second part is mostly taken care with these two

The first looks like what it does is look for a
META-INF/geronimo-spring.xml file in the jars and sets up deployment
of it.  Then, from what I understand of how Geronimo works, the actual
application context is setup in the second class.  The only thing
missing in this picture is a shared, parent application context that
each of the other spring modules will use as the parent of their own
application contexts.
> 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.
The way it should work is for all the services to be started before
any of the webapps.
> I've been wanting something like this for relatively complicated
> spring apps such as jetspeed2....
> Hope this helps
It does.  I appreciate the help.
> thanks
> david jencks
>> Thanks,
>> Rich

View raw message