I have already argued that many application contexts are better than a single application context. But how the heck do you load more than one context?

There are a couple of ways to do this.

web.xml

Your first option is to load them all into your Web application context via the ContextConfigLocation element. You’re already going to have your primary applicationContext here, assuming you’re writing a web application. All you need to do is put some white space between the declaration of the next context.

<context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml
        applicationContext2.xml
    </param-value>
</context-param>

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

The above uses carriage returns. Alternatively, yo could just put in a space.

<context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml applicationContext2.xml
    </param-value>
</context-param>

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

applicationContext.xml

Your other option is to just add your primary applicationContext.xml to the web.xml and then use import statements in that primary context.

In applicationContext.xml you might have…

<!-- hibernate configuration and mappings -->
<import resource="applicationContext-hibernate.xml"/>

<!-- ldap -->
<import resource="applicationContext-ldap.xml"/>

<!-- aspects -->
<import resource="applicationContext-aspects.xml"/>

Which Strategy?

I always prefer to load up via web.xml This allows me to keep all contexts isolated from each other. With tests, we can load just the contexts that we need to run those tests. This makes development more modular too as components stay loosely coupled, so that in the future I can extract a package or vertical layer and move it to its own module.

Any benefits to going with the application context import method?

This is a short introduction to splitting up your bean definitions from one single Spring application context, to many application contexts. That is, from one XML file to many XML files.

The general idea is to have one single primary application context, usually titled
applicationContext.xml, and then many other application contexts with are named what they contain.

Example

• applicationContext.xml
• applicationContext-dao.xml
• applicationContext-dao-datasource.xml
• applicationContext-ldap.xml
• applicationContext-aspects.xml
• applicationContext-web.xml

Breakdown

In this example, your DAO definitions, transaction managers, and DAO or integration interceptors are defined in applicationContext-dao.xml. We have further broken the DAO application context to a dao-datasource which contains our data sources. LDAP configuration, beans, and DAOs are in their own applicationContext-ldap.xml.

Benefits

Why so many? There have been a few benefits so far.

• Clearly, working with a smaller XML file is easier than working with one enormous file. It is easier to maintain and easier to read.
• Testing. When I wrote my tests for LDAP, I had my LDAP configuration in applicationContext.xml, but then every time I ran an LDAP test, I would get the WebApplicationContext, which would import applicationContext-hibernate, which would connect to the database, tests took forever, needless resources used… Anyway, now I just get applicationContext-ldap.xml which only contains LDAP configurations, so no needless resources are loaded.
• Including. Finally, its really easy to comment out a line like

  <import resource="applicationContext-aspects.xml"/>
  

  and quickly have all my aspects, which for me only write logs, disabled.

Does anyone else use multiple application context files? See any other benefits? Or problems?

This post on OpenSessionInViewInterceptor vs. OpenSessionInViewFilter gets a lot of views from developers who are searching “OpenSessionInViewFilter” and “OpenSessionInViewFilter”. I’d guess, a lot of them are looking for examples. I don’t want to disappoint anyone so here are example setups of both the filter and the interceptor.

OpenSessionInViewInterceptor

This goes into your action-servlet.xml.

<beans>

<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

<property name="interceptors">
<list>
<ref bean="openSessionInViewInterceptor"/>
</list>
</property>

<property name="mappings">

</bean>

<bean name="openSessionInViewInterceptor"
class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">

<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>

</beans>

OpenSessionInViewFilter

This goes into your web.xml.

<web-app>

<filter>
<filter-name>openSessionInViewFilter</filter-name>
<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>openSessionInViewFilter</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>

</web-app>

If you are not sure if you need to use the filter or the interceptor, check our post that explains the “>difference between the OpenSessionInViewFilter and the OpenSessionInViewInteceptor. The comments on that page offer some good insight too.