org.springframework.web Documentation Differences

This file contains all the changes in documentation in the package org.springframework.web as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

Create a new MediaTypeExceptionHttpMediaTypeException. @param message the exception message

Create a new HttpMediaTypeNotSupportedExceptionHttpMediaTypeException with a list of supported media types. @param supportedMediaTypes the list of supported media types

Exception thrown when a client POSTs, PUTs, or PUTsPATCHes content of a type not supported by request handler. @author Arjen Poutsma @since 3.0

Interface to be implemented in Servlet 3.0+ environments in order to configure the ServletContext programmatically -- as opposed to (or possibly in conjunction with) the traditional {@code web.xml}-based approach.

Implementations of this SPI will be detected automatically by SpringServletContainerInitializer, which itself is bootstrapped automatically by any Servlet 3.0 container. See SpringServletContainerInitializer its Javadoc for details on this bootstrapping mechanism.

Example

The traditional, XML-based approach

Most Spring users building a web application will need to register Spring's {@code DispatcherServlet}. For reference, in WEB-INF/web.xml, this would typically be done as follows:

 {@code
 
   dispatcher
   
     org.springframework.web.servlet.DispatcherServlet
   
   
     contextConfigLocation
     /WEB-INF/spring/dispatcher-config.xml
   
   1
 

 
   dispatcher
   /
 }

The code-based approach with {@code WebApplicationInitializer}

Here is the equivalent {@code DispatcherServlet} registration logic, {@code WebApplicationInitializer}-style:

 public class MyWebAppInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext container) {
      XmlWebApplicationContext appContext = new XmlWebApplicationContext();
      appContext.setConfigLocation("/WEB-INF/spring/dispatcher-config.xml");

      ServletRegistration.Dynamic dispatcher =
        container.addServlet("dispatcher", new DispatcherServlet(appContext));
      dispatcher.setLoadOnStartup(1);
      dispatcher.addMapping("/");
    }

 }

As an alternative to the above, you can also extend from org.springframework.web.servlet.support.AbstractDispatcherServletInitializer. As you can see, thanks to Servlet 3.0's new ServletContext.addServlet method we're actually registering an instance of the {@code DispatcherServlet}, and this means that the {@code DispatcherServlet} can now be treated like any other object -- receiving constructor injection of its application context in this case.

This style is both simpler and more concise. There is no concern for dealing with init-params, etc, just normal JavaBean-style properties and constructor arguments. You are free to create and work with your Spring application contexts as necessary before injecting them into the {@code DispatcherServlet}.

Most major Spring Web componentry hascomponents have been updated to support this style of registration. You'll find that {@code DispatcherServlet}, {@code FrameworkServlet}, {@code ContextLoaderListener} and {@code DelegatingFilterProxy} all now support constructor arguments. Even if a component (e.g. non-Spring, other third party) has not been specifically updated for use within {@code WebApplicationInitializers}, they still may be used in any case. The Servlet 3.0 {@code ServletContext} API allows for setting init-params, context-params, etc programmatically.

A 100% code-based approach to configuration

In the example above, {@code WEB-INF/web.xml} was successfully replaced with code in the form of a {@code WebApplicationInitializer}, but the actual {@code dispatcher-config.xml} Spring configuration remained XML-based. {@code WebApplicationInitializer} is a perfect fit for use with Spring's code-based {@code @Configuration} classes. See @Configuration Javadoc for complete details, but the following example demonstrates refactoring to use Spring's AnnotationConfigWebApplicationContext in lieu of {@code XmlWebApplicationContext}, and user-defined {@code @Configuration} classes {@code AppConfig} and {@code DispatcherConfig} instead of Spring XML files. This example also goes a bit beyond those above to demonstrate typical configuration of the 'root' application context and registration of the {@code ContextLoaderListener}:

 public class MyWebAppInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext container) {
      // Create the 'root' Spring application context
      AnnotationConfigWebApplicationContext rootContext =
        new AnnotationConfigWebApplicationContext();
      rootContext.register(AppConfig.class);

      // Manage the lifecycle of the root application context
      container.addListener(new ContextLoaderListener(rootContext));

      // Create the dispatcher servlet's Spring application context
      AnnotationConfigWebApplicationContext dispatcherContext =
        new AnnotationConfigWebApplicationContext();
      dispatcherContext.register(DispatcherConfig.class);

      // Register and map the dispatcher servlet
      ServletRegistration.Dynamic dispatcher =
        container.addServlet("dispatcher", new DispatcherServlet(dispatcherContext));
      dispatcher.setLoadOnStartup(1);
      dispatcher.addMapping("/");
    }

 }

As an alternative to the above, you can also extend from org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer. Remember that {@code WebApplicationInitializer} implementations are detected automatically -- so you are free to package them within your application as you see fit.

Ordering {@code WebApplicationInitializer} execution

{@code WebApplicationInitializer} implementations may optionally be annotated at the class level with Spring's @Order annotation or may implement Spring's Ordered interface. If so, the initializers will be ordered prior to invocation. This provides a mechanism for users to ensure the order in which servlet container initialization occurs. Use of this feature is expected to be rare, as typical applications will likely centralize all container initialization within a single {@code WebApplicationInitializer}.

Caveats

web.xml versioning

{@code WEB-INF/web.xml} and {@code WebApplicationInitializer} use are not mutually exclusive; for example, web.xml can register one servlet, and a {@code WebApplicationInitializer} can register another. An initializer can even modify registrations performed in {@code web.xml} through methods such as ServletContext.getServletRegistration(String). However, if {@code WEB-INF/web.xml} is present in the application, its {@code version} attribute must be set to "3.0" or greater, otherwise {@code ServletContainerInitializer} bootstrapping will be ignored by the servlet container.

Mapping to '/' under Tomcat

Apache Tomcat maps its internal {@code DefaultServlet} to "/", and on Tomcat versions <= 7.0.14, this servlet mapping cannot be overridden programmatically. 7.0.15 fixes this issue. Overriding the "/" servlet mapping has also been tested successfully under GlassFish 3.1.

@author Chris Beams @since 3.1 @see SpringServletContainerInitializerSpringServletContainerInitializer @see org.springframework.web.context.AbstractContextLoaderInitializer @see org.springframework.web.servlet.support.AbstractDispatcherServletInitializer @see org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer