Sharing an application context between two WARs?

Question

Is there a way to share an app-context between two deployed wars? One war needs to wire-in the services of another, and I don\'t know where to start with this.

Answer 1

There is maybe a way if you start an embedded jetty server and access both web apps from the class where you start and configure the jetty server.

See:

Embedding Jetty

Answer 2

The general purpose of a web application container like tomcat is that each application is able to run independently (so you can stop and start individual apps without affecting others), which means that there has probably been a lot of effort put into their development specifically to prevent you from doing this. So even if you find a loophole, I would suggest against using it unless it is recommended or at least sanctioned by the designers.

I suggest you start looking for other solutions. For example:

• Do you really need to share the object instances? If they are stateless you may not need to, and you can simply run a copy of the context in each app.
• Can you separate the code that you're trying to share into a third WAR that exposes a rest service? Or maybe one of the existing WARs could act as the service.

Answer 3

There is an informative blog post I think you should check out: Using a shared parent application context in a multi-war Spring application

Answer 4

Do you need to share the runtime context, or do you want to just re-use bean definitions across the two applications?

If it is only the latter then you could easily extract the common Spring context XML files into some shared dependency, and just re-use the JAR across the two webapps. However if you need the beans/services in each application to talk to each other, you need a different option.

Answer 5

You could possibly bind a context to JNDI if it doesn't exist.

The price for this is that each webapp's context somehow has to be aware that it might not be the primary.

Also, you need to be really careful about race conditions, e.g.

• first webapp starts, detects that there is no context
• first webapp starts to build the context
• second webapp starts, detects that there is no context
• second webapp starts to build the context
• first webapp finishes to build the context, binds it
• second webapp finishes to build the context, binds it
• congratulations, you have lost all beans from the context of the first webapp

Answer 6

Our team just had the same requirement--to share Spring beans between multiple WARs in Tomcat, and honestly, answers such as, "Don't do that," are not helpful.

The requirement stems from the fact that we have a multi-WAR application running on Tomcat, and all of the WARs need access to the same RDBMS for persisting information. We are using Spring and Hibernate to access the RDBMs, and all of the WARs share the same schema and ideally can use the same Hibernate SessionFactory and Spring transaction manager.

The answer on how to do it was posted here:

StackOverflow: Sharing ApplicationContext within EAR

and to summarize, you do the following in your web.xml:

<context-param>
  <param-name>parentContextKey</param-name>
  <param-value>sharedContext</param-value>
</context-param>
<context-param>
  <param-name>locatorFactorySelector</param-name>
  <param-value>classpath:beanRefContext.xml</param-value>
</context-param>
<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>classpath:yourWarSpecificAppContext.xml</param-value>
</context-param>

<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

where beanRefContext.xml contains:

<beans>
  <bean id="sharedContext" class="org.springframework.context.support.ClassPathXmlApplicationContext">
    <constructor-arg>
      <list>
        <value>classpath:yourSharedAppContext.xml</value>
      </list>
    </constructor-arg>
  </bean>
</beans>

This uses the Spring ContextSingletonBeanFactoryLocator to expose and share the parent context (in this case using the name "sharedContext"). The shared context will be lazily loaded when the first WAR references it.

Whatever beans you reference in the shared context have to be accessible to all of the WARs, which means that they cannot be loaded from WEB-INF/classes or WEB-INF/lib within a specific WAR. They must be shared, either using an EAR file, or by putting the jars that contain the beans (and dependencies) in the Tomcat shared "lib" folder ($CATALINA_HOME/lib), which is what our team did.

Fair warning that if you use this approach, you are likely to have most of your JARs located in the shared lib folder and not in individual webapps. For our project, this made sense because most of the webapps share and access the same back-end services.

Since the hardcore Tomcat developers are likely to object to putting lots of code into the Tomcat shared lib directory, I'll just enumerate some reasons why the other suggested answers might not work.

• Using separate application contexts for each WAR would mean having multiple connection pools to the database, one for each WAR, and separate initialization of expensive Hibernate SessionFactory for each WAR, which increases server start time and memory consumption. More generally, it does not allow the state of shared back-end services to be shared across webapps running in the same Tomcat.
• Putting the persistence code into a separate WAR and using REST calls, at least in our case, is totally inconvenient for developers, and increases the path length to get to the database compared with direct calls to shared beans.