Before diving into the integration specifics of each supported web framework, let us first take a look at the Spring configuration that not specific to any one web framework. (This section is equally applicable to Spring's own web framework, Spring MVC.)
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) 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, etc. 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 one configures a Spring container (a
WebApplicationContext) that contains all of the
'business beans' in one's application.
Onto specifics... all that one need do is to declare a
in the standard J2EE servlet
web.xml file of one's web application,
and add a
contextConfigLocation <context-param/> section
(in the same file) that defines which set of Spring XML cpnfiguration files to load.
Find below the <listener/> configuration:
<listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>
Listeners were added to the Servlet API in version 2.3; listener startup order was
finally clarified in Servlet 2.4. If you have a Servlet 2.3 container, you can use the
Find below the <context-param/> configuration:
<context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext*.xml</param-value> </context-param>
If you don't specify the
context parameter, the
ContextLoaderListener will look
for a file called
/WEB-INF/applicationContext.xml to load.
Once the context files are loaded, Spring creates a
object based on the bean definitions and stores it in the
ServletContext of one's web application.
All Java web frameworks are built on top of the Servlet API, and so one can
use the following code snippet to get access to this 'business context'
ApplicationContext created by the
WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);
class is for convenience, so you don't have to remember the name of the
ServletContext attribute. Its getWebApplicationContext()
method will return
null if an object doesn't exist under the
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE key. Rather
than risk getting
NullPointerExceptions in your application, it's
better to use the
getRequiredWebApplicationContext() method. This
method throws an exception when the ApplicationContext is missing.
Once you have a reference to the
you can retrieve beans by their name or type. Most developers retrieve beans
by name, 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 allow you to use dependency injection on their controllers. Each web framework section has more detail on its specific integration strategies.