Common Configuration
Before diving into the integration specifics of each supported web framework, let us first take a look at common Spring configuration that is not specific to any one web framework. (This section is equally applicable to Spring’s own web framework variants.)
One of the concepts (for want of a better word) espoused by Spring’s lightweight
application model is that of a layered architecture. Remember that in a “classic”
layered architecture, the web layer is but one of many layers. It serves as one of the
entry points into a server-side application, and it delegates to service objects
(facades) that are defined in a service layer to satisfy business-specific (and
presentation-technology agnostic) use cases. In Spring, these service objects, any other
business-specific objects, data-access objects, and others exist in a distinct “business
context”, which contains no web or presentation layer objects (presentation objects
,such as Spring MVC controllers, are typically configured in a distinct “presentation
context”). This section details how you can configure a Spring container (a
WebApplicationContext
) that contains all of the 'business beans' in your application.
Moving on to specifics, all you one need to do is declare a
ContextLoaderListener
in the standard Java EE servlet web.xml
file of your web application and add a
contextConfigLocation
<context-param/> section (in the same file) that defines which
set of Spring XML configuration files to load.
Consider the following <listener/>
configuration:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
Further consider the following <context-param/>
configuration:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext*.xml</param-value>
</context-param>
If you do not specify the contextConfigLocation
context parameter, the
ContextLoaderListener
looks for a file called /WEB-INF/applicationContext.xml
to
load. Once the context files are loaded, Spring creates a
WebApplicationContext
object based on the bean definitions and stores it in the ServletContext
of the web
application.
All Java web frameworks are built on top of the Servlet API, so you can use the
following code snippet to get access to this “business context” ApplicationContext
created by the ContextLoaderListener
.
The following example shows how to get the WebApplicationContext
:
WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);
The
WebApplicationContextUtils
class is for convenience, so you need not remember the name of the ServletContext
attribute. Its getWebApplicationContext()
method returns null
if an object
does not exist under the WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE
key. Rather than risk getting NullPointerExceptions
in your application, it is better
to use the getRequiredWebApplicationContext()
method. This method throws an exception
when the ApplicationContext
is missing.
Once you have a reference to the WebApplicationContext
, you can retrieve beans by their
name or type. Most developers retrieve beans by name and then cast them to one of their
implemented interfaces.
Fortunately, most of the frameworks in this section have simpler ways of looking up beans. Not only do they make it easy to get beans from a Spring container, but they also let you use dependency injection on their controllers. Each web framework section has more detail on its specific integration strategies.