diff --git a/build-spring-framework/resources/changelog.txt b/build-spring-framework/resources/changelog.txt
index d7c1072c92..2f26e25106 100644
--- a/build-spring-framework/resources/changelog.txt
+++ b/build-spring-framework/resources/changelog.txt
@@ -26,7 +26,7 @@ Changes in version 3.1 RC2 (2011-11-15)
* support UriComponentsBuilder as @Controller method argument
* MockHttpServletRequest and MockHttpServletResponse now keep contentType field and Content-Type header in sync
* fixed issue with cache ignoring prototype-scoped controllers in RequestMappingHandlerAdapter
-
+* update Spring MVC configuration section to include MVC Java config and the MVC namespace
Changes in version 3.1 RC1 (2011-10-11)
---------------------------------------
diff --git a/spring-framework-reference/src/mvc.xml b/spring-framework-reference/src/mvc.xml
index 0e0aead14d..9bb6643b67 100644
--- a/spring-framework-reference/src/mvc.xml
+++ b/spring-framework-reference/src/mvc.xml
@@ -248,7 +248,7 @@
the web.xml of your web application. You need to map
requests that you want the DispatcherServlet to
handle, by using a URL mapping in the same web.xml
- file. This is standard J2EE Servlet configuration; the following example
+ file. This is standard Java EE Servlet configuration; the following example
shows such a DispatcherServlet declaration and
mapping:
@@ -301,8 +301,7 @@
Upon initialization of a DispatcherServlet,
- the framework looks
- for a file named
+ Spring MVC looks for a file named [servlet-name]-servlet.xml in the
WEB-INF directory of your web application and creates
the beans defined there, overriding the definitions of any beans defined
@@ -349,155 +348,219 @@
look up the WebApplicationContext if you
need access to it.
- The Spring DispatcherServlet uses special
- beans to process requests and render the appropriate views. These beans
- are part of Spring Framework. You can configure them in the
- WebApplicationContext, just as you
- configure any other bean. However, for most beans, sensible defaults are
- provided so you initially do not need to configure them. These
- beans are described in the following table.
-
-
- Special beans in the
- WebApplicationContext
-
-
-
-
-
-
-
-
- Bean type
-
- Explanation
-
-
-
-
-
- controllers
-
- Form the C part of the MVC.
-
-
-
- handler
- mappings
-
- Handle the execution of a list of pre-processors and
- post-processors and controllers that will be executed if they
- match certain criteria (for example, a matching URL specified with
- the controller).
-
-
-
- view
- resolvers
-
- Resolves view names to views.
-
-
-
- locale
- resolver
-
- A locale resolver
- is a component capable of resolving the locale a client is using,
- in order to be able to offer internationalized views
-
-
-
- Theme resolver
-
- A theme resolver
- is capable of resolving themes your web application can use, for
- example, to offer personalized layouts
-
-
-
- multipart file resolver
-
- Contains functionality to process file uploads from HTML
- forms.
-
-
-
- handler exception
- resolvers
-
- Contains functionality to map exceptions to views or
- implement other more complex exception handling code.
-
-
-
-
-
- After you set up a DispatcherServlet, and a
- request comes in for that specific
- DispatcherServlet, the
- DispatcherServlet starts processing the request as
- follows:
-
-
-
- The WebApplicationContext is
- searched for and bound in the request as an attribute that the
- controller and other elements in the process can use. It
- is bound by default under the key
- DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.
-
-
-
- The locale resolver is bound to the request to enable elements
- in the process to resolve the locale to use when processing the
- request (rendering the view, preparing data, and so on). If you do not
- need locale resolving, you do not need it.
-
-
-
-
-
- The theme resolver is bound to the request to let elements such
- as views determine which theme to use. If you do not use themes, you
- can ignore it.
-
-
-
-
-
-
-
- If you specify a multipart file resolver, the request is
- inspected for multiparts; if multiparts are found, the request is
- wrapped in a MultipartHttpServletRequest for
- further processing by other elements in the process. See for further information about multipart
- handling.
-
-
-
- An appropriate handler is searched for. If a handler is found,
- the execution chain associated with the handler (preprocessors,
- postprocessors, and controllers) is executed in order to prepare a
- model or rendering.
-
-
-
- If a model is returned, the view is rendered. If no model is
- returned, (may be due to a preprocessor or postprocessor intercepting
- the request, perhaps for security reasons), no view is rendered,
- because the request could already have been fulfilled.
-
-
-
-
-
- Handler exception resolvers that are declared in the
- WebApplicationContext pick up exceptions
- that are thrown during processing of the request. Using these exception
- resolvers allows you to define custom behaviors to address
- exceptions.
+
+ Special Bean Types In the WebApplicationContext
+
+ The Spring DispatcherServlet uses special
+ beans to process requests and render the appropriate views. These beans
+ are part of Spring MVC. You can choose which special beans to use
+ by simply configuring one or more of them in the
+ WebApplicationContext.
+ However, you don't need to do that initially since Spring MVC
+ maintains a list of default beans to use if you don't configure any.
+ More on that in the next section. First see the table below
+ listing the special bean types the
+ DispatcherServlet relies on.
+
+
+ Special bean types in the
+ WebApplicationContext
+
+
+
+
+
+
+
+
+ Bean type
+
+ Explanation
+
+
+
+
+
+ HandlerMapping
+
+ Maps incoming requests to handlers and a list of
+ pre- and post-processors (handler interceptors) based on some
+ criteria the details of which vary by HandlerMapping
+ implementation. The most popular implementation supports
+ annotated controllers but other implementations exists as well.
+
+
+
+ HandlerAdapter
+
+ Helps the DispatcherServlet to
+ invoke a handler mapped to a request regardless of the handler
+ is actually invoked. For example, invoking an annotated controller
+ requires resolving various annotations. Thus the main purpose
+ of a HandlerAdapter is to shield the
+ DispatcherServlet from such details.
+
+
+
+ HandlerExceptionResolver
+
+ Maps exceptions to views also allowing for more
+ complex exception handling code.
+
+
+
+ ViewResolver
+
+ Resolves logical String-based view names to actual
+ View types.
+
+
+
+ LocaleResolver
+
+ Resolves the locale a client is using,
+ in order to be able to offer internationalized views
+
+
+
+ ThemeResolver
+
+ Resolves themes your web application can use, for
+ example, to offer personalized layouts
+
+
+
+ MultipartResolver
+
+ Parses multi-part requests for example to support processing
+ file uploads from HTML forms.
+
+
+
+ FlashMapManager
+
+ Stores and retrieves the "input" and the "output"
+ FlashMap that can be used to pass attributes
+ from one request to another, usually across a redirect.
+
+
+
+
+
+
+
+
+ Default DispatcherServlet Configuration
+
+ As mentioned in the previous section for each special bean
+ the DispatcherServlet maintains a list
+ of implementations to use by default. This information is
+ kept in the file DispatcherServlet.properties
+ in the package org.springframework.web.servlet.
+
+
+ All special beans have some reasonable defaults of
+ their own. Sooner or later though you'll need to customize
+ one or more of the properties these beans provide.
+ For example it's quite common to configure
+ an InternalResourceViewResolver
+ settings its prefix property to
+ the parent location of view files.
+
+ Regardless of the details, the important concept
+ to understand here is that once
+ you configure a special bean such as an
+ InternalResourceViewResolver
+ in your WebApplicationContext, you
+ effectively override the list of default implementations
+ that would have been used otherwise for that special bean
+ type. For example if you configure an
+ InternalResourceViewResolver,
+ the default list of ViewResolver
+ implementations is ignored.
+
+
+ In you'll learn about
+ other options for configuring Spring MVC including
+ MVC Java config and the MVC XML namespace both of which provide
+ a simple starting point and assume little knowledge of
+ how Spring MVC works. Regardless of how you choose to
+ configure your application, the concepts explained in this
+ section are fundamental should be of help to you.
+
+
+
+
+
+ DispatcherServlet Processing Sequence
+
+ After you set up a DispatcherServlet, and a
+ request comes in for that specific
+ DispatcherServlet, the
+ DispatcherServlet starts processing the request as
+ follows:
+
+
+
+ The WebApplicationContext is
+ searched for and bound in the request as an attribute that the
+ controller and other elements in the process can use. It
+ is bound by default under the key
+ DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.
+
+
+
+ The locale resolver is bound to the request to enable elements
+ in the process to resolve the locale to use when processing the
+ request (rendering the view, preparing data, and so on). If you do not
+ need locale resolving, you do not need it.
+
+
+
+
+
+ The theme resolver is bound to the request to let elements such
+ as views determine which theme to use. If you do not use themes, you
+ can ignore it.
+
+
+
+
+
+
+
+ If you specify a multipart file resolver, the request is
+ inspected for multiparts; if multiparts are found, the request is
+ wrapped in a MultipartHttpServletRequest for
+ further processing by other elements in the process. See for further information about multipart
+ handling.
+
+
+
+ An appropriate handler is searched for. If a handler is found,
+ the execution chain associated with the handler (preprocessors,
+ postprocessors, and controllers) is executed in order to prepare a
+ model or rendering.
+
+
+
+ If a model is returned, the view is rendered. If no model is
+ returned, (may be due to a preprocessor or postprocessor intercepting
+ the request, perhaps for security reasons), no view is rendered,
+ because the request could already have been fulfilled.
+
+
+
+
+
+ Handler exception resolvers that are declared in the
+ WebApplicationContext pick up exceptions
+ that are thrown during processing of the request. Using these exception
+ resolvers allows you to define custom behaviors to address
+ exceptions.
+
+ The Spring DispatcherServlet also supports
the return of the last-modification-date, as
@@ -1062,7 +1125,7 @@ public class RelativePathUriTemplateController {
Session access may not be thread-safe, in particular in
a Servlet environment. Consider setting the
- AnnotationMethodHandlerAdapter's
+ RequestMappingHandlerAdapter's
"synchronizeOnSession" flag to "true" if multiple requests are
allowed to access a session concurrently.
@@ -3973,45 +4036,90 @@ public class SimpleController {
Configuring Spring MVC
- Spring 3 introduces a mvc XML configuration
- namespace that simplifies the setup of Spring MVC inside your web
- application. Instead of registering low-level beans such as
- AnnotationMethodHandlerAdapter, you can simply use the namespace and its
- higher-level constructs. This is generally preferred unless you require
- finer-grained control of the configuration at the bean level.
-
- The mvc namespace consists of three tags: mvc:annotation-driven,
- mvc:interceptors, and mvc:view-controller. Each of these tags is
- documented below and in the XML
- schema.
-
-
- mvc:annotation-driven
-
- This tag registers the RequestMappingHandlerMapping and
- RequestMappingHandlerAdapter beans that are required for Spring MVC to
- dispatch requests to @Controllers. The tag configures those two beans
- with sensible defaults based on what is present in your classpath. The
- defaults are:
+ and
+ explained about
+ Spring MVC's special beans and the default implementations
+ used by the DispatcherServlet.
+ In this section you'll learn about two additional ways of
+ configuring Spring MVC. Namely the MVC Java config and
+ the MVC XML namespace.
+
+
+ The MVC Java config and the MVC namespace provide
+ similar default configuration that overrides
+ the DispatcherServlet defaults.
+ The goal is to spare most applications from having to
+ having to create the same configuration and also to
+ provide higher-level constructs for configuring
+ Spring MVC that serve as a simple starting point and
+ require little or no prior knowledge of the underlying
+ configuration.
+
+ You can choose either the MVC Java config or the
+ MVC namespace depending on your preference. Also as you
+ will see further below, with the MVC Java config it is
+ easier to see the underlying configuration as well as
+ to make fine-grained customizations directly to the
+ created Spring MVC beans.
+ But let's start from the beginning.
+
+
+
+ Enabling MVC Java Config or the MVC XML Namespace
+
+ To enable MVC Java config add the annotation
+ @EnableWebMvc to one of your
+ @Configuration classes:
+
+ @EnableWebMvc
+@Configuration
+public class WebConfig {
+
+}
+
+ To achieve the same in XML use the mvc:annotation-driven element:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+ xmlns:mvc="http://www.springframework.org/schema/mvc"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="
+ http://www.springframework.org/schema/beans
+ http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
+ http://www.springframework.org/schema/mvc
+ http://www.springframework.org/schema/mvc/spring-mvc-3.1.xsd">
+
+ <mvc:annotation-driven />
+
+<beans>
+
+ The above registers a
+ RequestMappingHandlerMapping, a
+ RequestMappingHandlerAdapter, and an
+ ExceptionHandlerExceptionResolver (among others)
+ in support of processing requests with annotated controller methods using
+ annotations such as @RequestMapping ,
+ @ExceptionHandler, and others.
+
+ It also enables the following:
+
- Support for Spring 3's Type ConversionService in addition to
- JavaBeans PropertyEditors during Data Binding. A ConversionService
- instance produced by the
- org.springframework.format.support.FormattingConversionServiceFactoryBean
- is used by default. This can be overridden by setting the
- conversion-service attribute.
+ Spring 3 style type conversion through a ConversionService instance
+ in addition to the JavaBeans PropertyEditors used for Data Binding.Support for formatting Number
- fields using the @NumberFormat annotation
+ fields using the @NumberFormat
+ annotation through the
+ ConversionService.Support for formatting Date,
- Calendar, Long, and Joda Time fields using the @DateTimeFormat
+ Calendar, Long, and Joda Time fields using the
+ @DateTimeFormat
annotation, if Joda Time 1.3 or higher is present on the
classpath.
@@ -4019,14 +4127,17 @@ public class SimpleController {
Support for validating @Controller
- inputs with @Valid, if a JSR-303 Provider is present on the
- classpath. The validation system can be explicitly configured by
- setting the validator attribute.
+ inputs with @Valid,
+ if a JSR-303 Provider is present on the classpath.
- HttpMessageConverter support for @RequestBody method
- parameters and @ResponseBody method return values.
+ HttpMessageConverter support for
+ @RequestBody method
+ parameters and @ResponseBody
+ method return values from
+ @RequestMapping or
+ @ExceptionHandler methods.This is the complete list of HttpMessageConverters set up by
mvc:annotation-driven:
@@ -4085,76 +4196,130 @@ public class SimpleController {
-
- You can provide your own HttpMessageConverters through the
- mvc:message-converters sub-element of mvc:annotation-driven.
- Message converters you provide will take precedence over the
- ones registered by default.
-
- A typical usage is shown below:
-<?xml version="1.0" encoding="UTF-8"?>
-<beans xmlns="http://www.springframework.org/schema/beans"
- xmlns:mvc="http://www.springframework.org/schema/mvc"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="
- http://www.springframework.org/schema/beans
- http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
- http://www.springframework.org/schema/mvc
- http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd">
+
+
+
+
+
+ Customizing the Provided Configuration
+
+ To customize the default configuration in Java you simply
+ implement the WebMvcConfigurer
+ interface or more likely extend the class
+ WebMvcConfigurerAdapter and override
+ the methods you need. Below is an example of some of the available
+ methods to override. See WebMvcConifgurer for
+ a list of all methods and the Javadoc for further details:
+
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ protected void addFormatters(FormatterRegistry registry) {
+ // Add formatters and/or converters
+ }
- <!-- JSR-303 support will be detected on classpath and enabled automatically -->
- <mvc:annotation-driven/>
-
-</beans>
-
+ @Override
+ public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
+ // Configure the list of HttpMessageConverters to use
+ }
+
+}
+
+ To customize the default configuration of
+ <mvc:annotation-driven /> check what
+ attributes and sub-elements it supports. You can view the
+ Spring MVC XML schema
+ or use the code completion feature of your IDE to discover
+ what attributes and sub-elements are available.
+ The sample below shows a subset of what is available:
+
+ <mvc:annotation-driven conversion-service="conversionService">
+ <mvc:message-converters>
+ <bean class="org.example.MyHttpMessageConverter"/>
+ <bean class="org.example.MyOtherHttpMessageConverter"/>
+ </mvc:message-converters>
+</mvc:annotation-driven>
+
+<bean id="conversionService" class="org.springframework.format.support.FormattingConversionServiceFactoryBean">
+ <property name="formatters">
+ <list>
+ <bean class="org.example.MyFormatter"/>
+ <bean class="org.example.MyOtherFormatter"/>
+ </list>
+ </property>
+</bean>
+
+
-
- mvc:interceptors
+
+ Configuring Interceptors
- This tag allows you to register custom HandlerInterceptors or
- WebRequestInterceptors that should be applied to all HandlerMapping
- beans. You can also restrict the URL paths that specific interceptors
- apply to.
+ You can configure HandlerInterceptors
+ or WebRequestInterceptors to be applied
+ to all incoming requests or restricted to specific URL path patterns.
- An example of registering an interceptor applied to all URL
- paths:
+ An example of registering interceptors in Java:
- <mvc:interceptors>
- <bean class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor" />
-</mvc:interceptors>
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ public void addInterceptors(InterceptorRegistry registry) {
+ registry.addInterceptor(new LocalInterceptor());
+ registry.addInterceptor(new SecurityInterceptor()).addPathPatterns("/secure/*");
+ }
- An example of registering an interceptor limited to a specific URL
- path:
+}
+
+ And in XML use the <mvc:interceptors> element:<mvc:interceptors>
+ <bean class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor" />
<mvc:interceptor>
<mapping path="/secure/*"/>
<bean class="org.example.SecurityInterceptor" />
</mvc:interceptor>
-</mvc:interceptors>
+</mvc:interceptors>
+
+
-
- mvc:view-controller
+
+ Configuring View Controllers
- This tag is a shortcut for defining a
+ This is a shortcut for defining a
ParameterizableViewController that immediately
forwards to a view when invoked. Use it in static cases when there is no
- Java Controller logic to execute before the view generates the
+ Java controller logic to execute before the view generates the
response.
- An example of view-controller that forwards to a home page is
- shown below:
+ An example of forwarding a request for "/"
+ to a view called "home" in Java:
+
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ public void addViewControllers(ViewControllerRegistry registry) {
+ registry.addViewController("/").setViewName("home");
+ }
+
+}
+
+ And the same in XML use the <mvc:view-controller> element:<mvc:view-controller path="/" view-name="home"/>
-
- mvc:resources
+
+ Configuring Serving of Resources
- This tag allows static resource requests following a particular
+ This option allows static resource requests following a particular
URL pattern to be served by a
ResourceHttpRequestHandler from any of a list of
Resource locations. This provides a convenient
@@ -4169,8 +4334,20 @@ public class SimpleController {
unnecessary overhead for resources that are already cached by the
client. For example, to serve resource requests with a URL pattern of
/resources/** from a public-resources
- directory within the web application root, the tag would be used as
- follows:
+ directory within the web application root you would use:
+
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ public void addResourceHandlers(ResourceHandlerRegistry registry) {
+ registry.addResourceHandler("/resources/**").addResourceLocations("/public-resources/");
+ }
+
+}
+
+ And the same in XML:<mvc:resources mapping="/resources/**" location="/public-resources/"/>
@@ -4178,6 +4355,19 @@ public class SimpleController {
maximum use of the browser cache and a reduction in HTTP requests made
by the browser:
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ public void addResourceHandlers(ResourceHandlerRegistry registry) {
+ registry.addResourceHandler("/resources/**").addResourceLocations("/public-resources/").setCachePeriod(31556926);
+ }
+
+}
+
+ And in XML:
+
<mvc:resources mapping="/resources/**" location="/public-resources/" cache-period="31556926"/>The mapping attribute must be an Ant pattern that can
@@ -4189,7 +4379,21 @@ public class SimpleController {
given request. For example, to enable the serving of resources from both
the web application root and from a known path of
/META-INF/public-web-resources/ in any jar on the
- classpath, the tag would be specified as:
+ classpath use:
+
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ public void addResourceHandlers(ResourceHandlerRegistry registry) {
+ registry.addResourceHandler("/resources/**")
+ .addResourceLocations("/", "classpath:/META-INF/public-web-resources/");
+ }
+
+}
+
+ And in XML:<mvc:resources mapping="/resources/**" location="/, classpath:/META-INF/public-web-resources/"/>
@@ -4213,18 +4417,36 @@ public class SimpleController {
would be to manage the version of the application in a properties file,
such as:
-
-application.version=1.0.0
+ application.version=1.0.0and then to make the properties file's values accessible to SpEL
as a bean using the util:properties tag:<util:properties id="applicationProps" location="/WEB-INF/spring/application.properties"/>
-
+
With the application version now accessible via SpEL, we can
incorporate this into the use of the resources tag:<mvc:resources mapping="/resources-#{applicationProps['application.version']}/**" location="/public-resources/"/>
+
+ In Java, you can use the @PropertySouce
+ annotation and then inject the Environment
+ abstraction for access to all defined properties:
+
+ @EnableWebMvc
+@Configuration
+@PropertySource("/WEB-INF/spring/application.properties")
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Inject Environment env;
+
+ @Override
+ public void addResourceHandlers(ResourceHandlerRegistry registry) {
+ registry.addResourceHandler("/resources-" + env.getProperty("application.version") + "/**")
+ .addResourceLocations("/public-resources/");
+ }
+
+}and finally, to request the resource with the proper URL, we can
take advantage of the Spring JSP tags:
@@ -4232,7 +4454,7 @@ application.version=1.0.0
<spring:eval expression="@applicationProps['application.version']" var="applicationVersion"/>
<spring:url value="/resources-{applicationVersion}" var="resourceUrl">
- <spring:param name="applicationVersion" value="${applicationVersion}"/>
+ <spring:param name="applicationVersion" value="${applicationVersion}"/>
</spring:url>
<script src="${resourceUrl}/dojo/dojo.js" type="text/javascript"> </script>
@@ -4257,9 +4479,21 @@ application.version=1.0.0
of the DefaultServletHttpRequestHandler, which is
Integer.MAX_VALUE.
- To enable the feature using the default setup, simply include the
- tag in the form:
+ To enable the feature using the default setup use:
+
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
+ configurer.enable();
+ }
+}
+
+ Or in XML:
+
<mvc:default-servlet-handler/>The caveat to overriding the "/" Servlet mapping is that the
@@ -4274,29 +4508,125 @@ application.version=1.0.0
the default Servlet name is unknown, then the default Servlet's name
must be explicitly provided as in the following example:
+ @EnableWebMvc
+@Configuration
+public class WebConfig extends WebMvcConfigurerAdapter {
+
+ @Override
+ public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
+ configurer.enable("myCustomDefaultServlet");
+ }
+
+}
+
+ Or in XML:
+
<mvc:default-servlet-handler default-servlet-name="myCustomDefaultServlet"/>
-
-
- More Spring Web MVC Resources
-
- See the following links and pointers for more resources about Spring
- Web MVC:
-
-
-
- There are many excellent articles and tutorials that show how to
- build web applications with Spring MVC. Read them at the Spring
- Documentation page.
-
-
-
- Expert Spring Web MVC and Web Flow by Seth Ladd
- and others (published by Apress) is an excellent hard copy source of
- Spring Web MVC goodness.
-
-
+
+ More Spring Web MVC Resources
+
+ See the following links and pointers for more resources about Spring Web MVC:
+
+
+
+ There are many excellent articles and tutorials that show how to
+ build web applications with Spring MVC. Read them at the Spring
+ Documentation page.
+
+
+
+ Expert Spring Web MVC and Web Flow by Seth Ladd
+ and others (published by Apress) is an excellent hard copy source of
+ Spring Web MVC goodness.
+
+
+
+
+
+ Advanced Customizations with MVC Java Config
+
+ As you can see from the above examples, MVC Java config and
+ the MVC namespace provide higher level constructs that do not
+ require deep knowledge of the underlying beans created for you.
+ Instead it helps you to focus on your application needs.
+ However, at some point you may need more fine-grained control
+ or you may simply wish to understand the underlying configuration.
+
+ The first step towards more fine-grained control is to see the
+ underlying beans created for you. In MVC Java config you can
+ see the Javadoc and the @Bean
+ methods in WebMvcConfigurationSupport.
+ The configuration in this class is automatically imported
+ through the @EnableWebMvc annotation.
+ In fact if you open @EnableWebMvc you can
+ see the @Import statement.
+
+ The next step towards more fine-grained control is to
+ customize a property on one of the beans created in
+ WebMvcConfigurationSupport or perhaps
+ to provide your own instance. This requires two things --
+ remove the @EnableWebMvc
+ annotation in order to prevent the import and then
+ extend directly from WebMvcConfigurationSupport.
+ Here is an example:
+
+
+ @Configuration
+public class WebConfig extends WebMvcConfigurationSupport {
+
+ @Override
+ public void addInterceptors(InterceptorRegistry registry){
+ // ...
+ }
+
+ @Override
+ @Bean
+ public RequestMappingHandlerAdapter requestMappingHandlerAdapter() {
+
+ // Create or let "super" create the adapter
+ // Then customize one of its properties
+ }
+
+}
+
+ Note that modifying beans in this way does not prevent
+ you from using any of the higher-level constructs shown earlier in
+ this section.
+
+
+
+
+ Advanced Customizations with the MVC Namespace
+
+ Fine-grained control over the configuration created for
+ you is a bit harder with the MVC namespace.
+
+ If you do need to do that, rather than replicating the
+ configuration it provides, consider configuring a
+ BeanPostProcessor that detects
+ the bean you want to customize by type and then modifying its
+ properties as necessary. For example:
+
+ @Component
+public class MyPostProcessor implements BeanPostProcessor {
+
+ public Object postProcessBeforeInitialization(Object bean, String name) throws BeansException {
+ if (bean instanceof RequestMappingHandlerAdapter) {
+ // Modify properties of the adapter
+ }
+ }
+
+}
+
+ Note that MyPostProcessor needs to be
+ included in an <component scan />
+ in order for it to be detected or if you prefer you can declare it
+ explicitly with an XML bean declaration.
+
+
+