I'm wondering how session-scoped beans would fit into this scenario. Since the shared context is not a web context, I assume that you can't use session-scoped beans there. Right?

"Instantiating a new instance of each shared bean for each war can have several drawbacks…"

Maybe so, but it also has one distinct advantage: predicatable, repeatable behaviour.

Maybe the implementation of ContextSingletonBeanFactoryLocator has been overhauled in Spring 2.0, but if not, I would strongly discourage its use unless you really know what you are doing.

When I used ContextSingletonBeanFactoryLocator, it operated very much at the mercy of the Classloader implementation of my server environment. When the classloader implementation was flaky, you ended up with singletons-that-are-not-really-singletons. For stateful components, this means that predicting the result of a method call has all the surprise and adventure of unwrapping a present on Christmas morning.

Very, very interesting article. In fact, that's exactely what I was looking for for months ! And, as always with Spring, there's a simple and staightforward solution

Thanks !

Benoit.

If you are not in an EJB container, but only use a servlet container, you have to deploy your classes for the global application context also into a global class loader, don't you? This gets a lot of stuff if you think of the domain model which you need for the mentioned SessionFactory.

My use case would be a portal web app a portlet web app which I have running both on plain Tomcat only, but I need to integrate them somehow: http://www.liferay.com/web/guest/devzone/forums/message_boards/message/35365. With the global context I'd need to deploy everything of the portlet web app except the MVC stuff to Tomcat's common class loader (common/lib, http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html). At some point you maybe have to switch to an EJB container – and if it's only for the class loader/ deployment stuff.

Joerg

I think I misunderstood something about your approach. What I did was putting my shared classes into a seperate jar file and provide it via Tomcat's shared lib folder. Then I assumed another webapp should have access to the jar and load its context as parent. While the parent context was initialized, I got the ClassNotFoundExceptions as described above.

Is there no way to do it the way I described here? I do not want to use an application server hence I do want to avoid EAR-files.

I put the all spring applicaitonContext.xml to myapp.ear/APP-INF/classes

Unfortunately, similar mechanism is missing for EJBs in current ContextJndiBeanFactoryLocator implementation. It would be nice if it can take also "parentContextKey" parameter similar to org.springframework.web.context.ContextLoaderListener to have one shared root context among EJB JARs as well as WARs.

Thanks for the great article and example. It works very well.

One problem we are having is that we dynamically load our application context, selecting the configuration files in Java. This also works well, but we how can we connect the two approaches? We created a custom listener and loader for a web application that creates and loads the context. As a result, it is not defined as a Spring bean in a configuration file. We would now like our dynamically created context to become the parent context for other web modules. Is there some way that we can "name" this context so that we can reference it in the web.xml of other web modules? I searched for a solution, but didn't find anything. Here is our custom ContextLoader code:

public class JeeContextLoader extends ContextLoader {
protected ApplicationContext loadParentContext(ServletContext servletContext) throws BeansException {
String moduleReferences = servletContext.getInitParameter("ModuleReferences") ;
if ( moduleReferences == null ) {
System.out.println("ModuleReferences is null");
} else {
System.out.println("ModuleReferences:" moduleReferences);
}
BootStrapper bootStrapper = new BootStrapper() ;
bootStrapper.setModuleReferences(moduleReferences);
Globals.Init(bootStrapper, FactoryInitAction.StartFactory);
ApplicationContext parentContext = Globals.getFactory() ;
return parentContext;}}

Thanks Joris, for your help. We are basically trying to do what you have done in your sample application without defining the application context in a Spring xml configuration file. We are doing this to support dynamic configuration for testing, shared Acegi security accross WARs, etc. Our same bootstrapper works for everything.

You were right in that we already had a solution. I just needed to add the functionality in our custom loader to point to a parent context, and it worked. I copied the following code right out of the Spring context loader.

BeanFactoryLocator bfLocator = ContextSingletonBeanFactoryLocator.getInstance();
BeanFactoryReference bfReference = bfLocator.useBeanFactory(parentContextKey);
parentContext = (ApplicationContext) bfReference.getFactory();

I have a client with the following issue…. They have a baseline non-branded WAR that works for most of their clients. However some clients (lets call them partners) are more demanding and would like something more configurable. My idea is to have a thin set of overriding/extension code for just the changes that are necessary for each partner. That partner override code will be in a separate WAR so that it can be tested and deployed separately. By using your solution I can have the child context replace the bean definitions for the parent context thereby injecting the partner code instead of the baseline code with no effect on the baseline. Is this correct? Is this the most effective way to gain this flexibility? Thanks.

Thanks for the quick response. Sorry it took a few days to get back. You actually bring up a separate point. I am trying to keep the WARs separate, but I don't know if I can.

Option 1: Keeping the WARs separate… This may not be possible because they are using Struts with JSP and Velocity. I am in the process of researching online if those files will be accessible in a separate WAR. In this case, I believe you are saying the parent context is the way to go.

Option 2: Merging the baseline and override… So are you saying that if the override defines a bean later in the initialization than the baseline it will replace the bean that was originally defined with that id? If so, that's much easier, but I couldn't see that documented anywhere. For some reason, I was thinking it might output a BeanAlreadyDefinedException (or something of the sort).

Hi,

many thanks for the very useful article. Like Dimitri Hautot, I've been trying this on WebLogic 9 and it works well. There's a slight difference in what I'm doing in that I want a bean at the managed server (i.e. JVM) level but that works fine with the bean code and required Spring jars at the server level (versus app-inf/lib at the ear level).

However, most of my web apps run with the WebLogic prefer-web-inf-classes setting changed to true (i.e. look first for code in the web app's web-inf/lib rather than first looking in the higher classloaders). When I turn this on, I get two instances of the SampleService class. I _think_ I understand why – the ContextSingletonBeanFactoryLocator is running from the web app's classloader and, although the SimpleService class is created by the server level classloader (it is not deployed to web-inf/lib), the ContextSingletonBeanFactoryLocator in each web app know nothing about the ApplicationContexts each other have created.

Does the above sound right? If so, do you know if there is an easy way round this i.e. so I can continue to run with prefer-web-inf-classes but am still able to pull in a single instance of an ApplicationContext created in a higher classloader as a parent into different web app's ApplicationContexts.

Thanks in advance if you have any pointers. I realise what I'm trying to do might sound strange i.e. turn on prefer-web-inf-classes to increase segregation between web apps while then wanting to also also put something on the server classpath but I would claim to have a valid use case for this!

Hi Joris,

thanks for the ultra speedy response! I am a little reluctant to change the existing web apps to move out the spring jar to the higher classloader. So I guess I'll need to think about alternative solutions – sharing an application context via JNDI sounds like fun to try!

Thanks again – appreciated.

Joris,

I'm using the shared context approach not for sharing my context between wars but between my war module and my ejb module.
More specifically I have one EAR with one ejb-jar module and one war module.
My EJBs (MDB's and SLSBs) extend from Spring's convenience classes and call as described in multiple threads on the web the setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance("classpath*:**/beanRefContext.xml")); and setBeanFactoryLocatorKey("service"); methods.
In my web.xml I have the correspondig parentContextKey and the locatorFactorySelector entries.

Everything works greath … except in one scenario … when I deploy/(re)start my EAR when there are messages on the queue. In this situation I'm running into the problem that the container preloads the MDB and calls the setMessageDrivenContext method in which the above method calls occur. Of course, at that point in time my web module is not started yet and therefore the shared application context is not loaded/initialized yet.
As a result I get a spring exception and my application doesn't start.

Is there a way to get around this problem ? For example, can I initialize the context from within my ejb and "make it available" to my web module, or could deploying a spring context as a JCA adapter help ?

Any help, advise, workarounds would be appreciated because I'm really stuck.

Kind regards,

EDH

Joris,

Thanks for your quick response !

In the meantime I also created a bug report for this: http://jira.springframework.org/browse/SPR-4301. That bug report shows the exceptions I'm getting. Now, I might have been a bit to fast to consider this a bug. From the comments on my bug report you'll see that a first problem I'll have to solve is to find out why the spring.schemas (file) is not found when the MDB gets created(preloaded) while in the normal scenario, when the web module is first loaded the schemas are found without any problem ? Do you have some advise on this perhaps ?

Now, let's say I've solved this schema problem then what I understand from your comment is that when the MDB is created/preloaded (before the web module has started and thus before the web module's contextloader kicks in) the setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance("classpath*:**/beanRefContext.xml")) call will also lead to the creation/initialization of the shared context. Is that correct ? Is so, then what happens at the time the web module gets loaded and it's contextloader kicks in ? Will it "detect" that the shared context is already there, or will it try to re-initialize it again ?

In either case, I'll try out your suggestions, and get back to you on this.

Thanks,
EDH

It looks like the default file isn't actually beanRefFactory.xml, but beanRefContext.xml. That confused me for sometime, until I looked at the source download.

Hi, Joris.

In one of your replies, you mentioned exposing an ApplicationContext via JNDI. This is something that I'm trying to do but can't seem to find documentation on. Could you point me to links, post hints or even outline a solution outright for how this is accomplished? Is there a container-independent way of doing this? I need to expose it that way because the EJB support of Spring recommends that the Context be picked up this way (sadly they don't mention how to do the first part).

Hi Joris,

thanks for this interesting hint. I used this implement modules for a web app last year and this worked perfectly for me.

But then I tried if I get my app running in a OSGI container using Spring DM. I know that OSGI now provides a better approach for modularizing an application, but I tried to do as little changes as possible for enabling OSGI.

So I added a OSGI manifest and deployed using the spring web extender. But now I get the following error message:

java.lang.IllegalStateException: BeanFactory not initialized or already closed – call 'refresh' before accessing beans via the ApplicationContext

Looks like Spring DM does not allow to change the root context? Or is there a way to "refresh" the context in order to get it run?

Thanks
Joern

Hi Joris,

thanks for your feedback. Your suggestion sounds good to me, even so I have to admit that I'm not sure if I understand all the details

The point where I got lost is, how can I make an XML application context OSGI aware? And another question is, can I use this context as a local BeanFactory?

Until today I used the getBean() method to dynamically create beans and their dependencies. Now I read that Spring DM discourages me to do so. I feel a bit lost here. How shall I create dynamic structures now? Or am I discouraged to do so either? Anyway I couldn't find an easy way to create a BeanFactory in an OSGI environment. Now I'm wondering if a custom XmlWebApplicationContext would solve this problem for me?

I know this is not a Spring-DM blog and I'm sorry if you are the wrong person to ask But then perhaps you can give me pointer, where I should follow up.

Thanks a lot
Joern

Hi Joris,

I'm just citing from the Spring DM doc, chapter 4.2.2:

"Note: the application context is published as a service primarily to facilitate testing, administration, and management. Accessing this context object at runtime and invoking getBean() or similar operations is discouraged."

This is what confuses me a lot, especially since it is not explained, how to get this context, if you are using the web extender. Perhaps this could be clarified a bit in the documentation?

Thanks a lot for your time and help!
Joern

Hi Joris,

This is Shameer from Dubai, I attended your course at Dubai. We had discussed the same problem there, which we were already implementing(not declaratively, but programmatically by adding the shared context as the parent of the web of EJB contexts), using the SingletonBeanFactory locator.

This blog is helpful for us, since it gives us a clue to use the existing mechanism in spring (the declarative use of parentContextKey.

But we still have a problem here, whenever a sub-context(web or ejb) of a multi-war EAR app locates the spring bean-factory using SingletonBeanFactoryLocator, it does return the once initiated bean-factory, but it refreshes (calls the refresh method) itself once again. So the result is, suppose there are five war modules in an EAR, there will be minimum five calls to the refresh method, which is undesirable.

Right now we handle it by overriding the refresh method in a sub class and controlling the further refresh calls (till startup of the application finishes) using a static boolean variable (it is a hack ).

Is there a way to avoid the further refreshes of an application-context unless it is forced to called by the client ?

Thanks,
Shameer

Great post, I have not yet seen spring setup this way. I'm thinking about giving it a shot but there is one question I have yet to find out the answer on.

Are you allowed to have multiple shared parentcontextkeys?

Example:

WAR-1 depends on Module-A and Module-B. Lets assume Module-A contains the DAO's and Module-B contains some services.

Module-B depends on Module-A. WAR-1 depends on Module-A and Module-B.

Can you specify a parent context key in WAR-1 for both Module-A and Module-B…similar to multiple configLocations?

Thanks

doesnt work in jboss 5.x enviroment..

The code also appears to work fine on WebSphere 7.0.

Hi Joris

So the parent applicationContext i shared in an application accross JVMs. Is it also possible to share it in an application that is clustered?

Hi Joris,

Thanks for your post. We also need to implement this. But ours is 1 war and multiple ejbs. And I want to share the application context of the war to the ejbs. But I'm having trouble just running your sample ear in our weblogic 10.3 server. The first servlet is able to run successfully but when i try the second servlet it is giving me classcast exception:

java.lang.ClassCastException: com.interface21.sample.multiplecontexts.service.SampleServiceImpl cannot be cast to com.interface21.sample.multiplecontexts.service.SampleService
at com.interface21.sample.multiplecontexts.web2.SecondServlet.doGet(SecondServlet.java:26)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3498)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Do you have any idea why I'm having this problem?

Hi Joris,

Thanks for the fast reply.
I can try the using the APP-INF/lib later but I'm not very clear on how I can put them in an EJB jar?
Could there be some setting in my server causing it to use different classloader if in case some other people was able to make it work in weblogic 10.3?

Hi Joris,

Ok, I'll look them up on how to set up a single classloader on WLS.
We are already using the ContextSingletonBeanFactoryLocator among our EJBs, the only problem is that our WAR is still having its own app context. So I'm in the process of modifying our WAR to use the same context.

Thanks for the advice again.

hi Joris,

Thanks for the great article. I've similar situation where there are 2 jars from different vendors are trying to load the beans. So after Bootstrap class in jar1 loads beans there is ContextListener in JAR2 which again tries to initialize the spring context. So, i get java.lang.IllegalStateException: Cannot initialize context because there is already a root application context present – check whether you have multiple ContextLoader* definitions in your web.xml!. Below is the code snippet in JAR1

t extends Spring's ContextLoaderListener and overrides contextInitialzed method where in it calls super.contextInitialized(event), which calls ContextLoader's initWebApplicationContext(event.getServletContext()) which checks for
servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE) != null and this condition turns to be true and thus it throws exception. Please finf below code snippet

public class PortalContextLoaderListener extends ContextLoaderListener {
public void contextInitialized(ServletContextEvent event) {

InitUtil.init();
super.contextInitialized(event); // error here
ApplicationContext applicationContext =
ContextLoader.getCurrentWebApplicationContext();

}
/************Spring ContextLoaderListener class ********************/

public class ContextLoaderListener extends ContextLoader implements ServletContextListener {

public void contextInitialized(ServletContextEvent event) {
this.contextLoader = createContextLoader();
if (this.contextLoader == null) {
this.contextLoader = this;
}
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
..
..
}

/************Spring ContextLoader class ********************/
public class ContextLoader {
…..
public WebApplicationContext initWebApplicationContext(ServletContext servletContext) {
if (servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE) != null) {
throw new IllegalStateException(
"Cannot initialize context because there is already a root application context present – "
"check whether you have multiple ContextLoader* definitions in your web.xml!");
}

Log logger = LogFactory.getLog(ContextLoader.class);
servletContext.log("Initializing Spring root WebApplicationContext");
if (logger.isInfoEnabled()) {
logger.info("Root WebApplicationContext: initialization started");
}
………..

// other stuff.
}

In JAR2 there's Config object which is doing also initializing the context and setting it to parent.

XmlBeanDefinitionReader xbdr = new XmlBeanDefinitionReader(ctx);

String[] springLocsArray = springLocations.toArray(new String[springLocations.size()] );
log.info( "Initializing spring with these config locations:: " springLocations );
try{
xbdr.loadBeanDefinitions( springLocsArray );
}catch(Exception e){ log.info( "Exception e: " e);}
log.info( "xbdr1" xbdr);
xbdr.setBeanClassLoader(Thread.currentThread().getContextClassLoader());
log.info("xbdr" xbdr);
ctx.setClassLoader( Thread.currentThread().getContextClassLoader() );
ctx.addBeanFactoryPostProcessor(ppc);
if ( poc != null ) {
ctx.addBeanFactoryPostProcessor( poc );
}

StaticApplicationContext parent = new StaticApplicationContext();
parent.refresh();
parent.getBeanFactory().registerSingleton( "config", this );
ctx.setParent( parent );
ctx.refresh();
if ( beanFactory == null ) {
beanFactory = ctx;
}

Can you pls advice how can I use the parent context as ceated in JAR2.

regards
Vijay

How would we use this approach with a web service application using spring-ws MessageDispatcherServlet.

it doesn't appear to support the parentContextKey

How would we use this approach with a web service application using spring-ws MessageDispatcherServlet.

it doesn't appear to support the parentContextKey

It doesn't use ContextLoader class at all to create it's application context.

Thanks Joris,

You're explaination of the extra level of nesting using spring dispatcher servlets makes it clear now.

For the benfit of anyone else using Jetty embeded and configured with spring, one piece of the puzzle is that took me a while to discover is that the context-param needed to set the parentContextKey in a web.xml translates to an init-param in the servlet API.

ContextLoader.loadParentContext() {
[...]
String parentContextKey = servletContext.getInitParameter(LOCATOR_FACTORY_KEY_PARAM);

Here's a full Jetty example for posterity

/

Joris,

First of all thanks for such wonderful post. I have a question related to making the same feature you are doing here session/request specific. What I am talking about is using the RequestContextListener instead of the ContextLoaderListener. Have you come across anythng like that..please guide me if you have any idea

Hi Joris,

Thank you for this excellent post and answering all those questions throughout the years. Did you have that on your mind when you were writing this blog post?

I wondered if this multiple context solution is equivalent to the use of prototypes in Spring 3? If correct wondering, which solution would you prefer?

With kind regards,

Loek

Hi Joris,

Great post even for Spring3, but I have something confused about the singleton. You mentioned"In general, if you have stateful beans that should really be used as a singleton (in the Spring sense, i.e. one instance per application as opposed to per JVM) you should define them in a single context accessed by the other contexts.", and is the comparison about the per application and per JVM means the clustered deployment and a non clustered one? If not, in a single server I think all the wars in an ear will be in a same JVM. Could you help explain that point in more details?

Great post. This is timely for us, as we have an EAR with 8 WARs that we are converting to Spring.

Is it proper to move the datasource and transaction manager beans up into the EAR as well? Seems a little strange, because I am using resource-ref=true, and resource references are defined to the WAR.