Support configuring Servlet container in Spring using Servlet 3.0 programmatic config [SPR-7672]

[spring-projects-issues]

Mike Youngstrom opened SPR-7672 and commented

This issue is a request to utilize Servlet 3.0 features to support the configuring of Servlets, Filters, Listeners, etc. using Spring configuration instead of forcing the user to configure that stuff in the web.xml. This type of configuration has a number of benefits. Some of those might be:

• Direct support for dependency injected spring beans as Servlets, Filters, etc. Without the need to use indirection such as DelegatingFilterProxy and HttpRequestHandlerServlet
• Support for configuration of servlet params (mappings, names, etc) with things such as SpringEL or PropertyPlaceholders
• Support for modifying what servlets, filters, etc. may be configured in an application based on runtime environment (with runtime config scheduled for 3.1)
• Potential simplification of Spring features/addons. For example auto configuration of SpringSecurity Filter as part of SpringSecurity namespace handlers, or SpringMVC servlet config, CharacterEncodingFilter, RequestLifecycleListener, etc.
• Bootstrapping of the Sring ApplicationContext without having to specify the the SpringContextLoaderListener in the web.xml by simply using conventions to determine if spring should start itself up or not.
• Potential for much much more.

I've attached a basic proof of concept example project. This example uses a ServletContainerInitializer to start a spring WebApplicationContext DURING ContainerStartup instead of after ServletContext Initialization. Not sure if this would break any existing functionality or not. My simple demo seems to work fine.

This ServletContainerInitializer looks for a file located in WEB-INF/applicationContext.xml or a contextConfigLocation init-param. If it finds either of these then it creates a WebApplicationContext uses ContextLoader.

This now enables a WebApplicationContext to add servlet configuration to the container at startup time. In my example I've created a simple bean that configures a DispatcherServlet in this web application and uses spring injected configuration to dictate how that Servlet gets configured.

This example is really ugly and more a proof of concept that you can use Spring to configure a servlet container as an alternative to web.xml. This example doesn't appear to me to eliminate any of the flexibility, customizability, extensibility, etc of Spring.

Some initial thoughts about work that might be involved in this issue:

• Perhaps some Spring objects that combine both a filter or Servlet with configuration for that filter or servlet such as name, url mapping, etc.
• These foundational objects could then potentially be automatically configured using a Spring PostProcessor or something.
• Some namespace handlers to simplify adding and configuring a filter, servlet, etc in spring.
• Perhaps some higher level configuration features to help simplify configuration of frameworks such as SpringMVC or Spring Security.

Thoughts?
Mike

---

Affects: 3.0.5

Attachments:

• mylyn-context.zip (25.66 kB)
• servlet-3.0-spring.zip (4.86 kB)

Issue Links:

• Make CharacterEncodingFilter more friendly for use in Servlet 3.0+ environments [SPR-13572] #18148 Make CharacterEncodingFilter more friendly for use in Servlet 3.0+ environments
• Support Servlet 3.0 (JSR-315) [SPR-5587] #10258 Support Servlet 3.0 (JSR-315)
• Declarative registration for ApplicationContextInitializer [SPR-8274] #12922 Declarative registration for ApplicationContextInitializer ("supersedes")

3 votes, 7 watchers

[spring-projects-issues]

Mike Youngstrom commented

BTW, this example requires Tomcat 7.

Setting the Servlet mapping to / doesn't appear to work. I think this is a Tomcat 7 bug.

[spring-projects-issues]

Mike Youngstrom commented

It sounds like functionality like this is planned for 3.1 M2. perhaps the fix version of this issue should be updated?

[spring-projects-issues]

Chris Beams commented

Initial support is now complete. Read the commit logs below (from bottom up) for details. Note that the implementation has limitations on Tomcat 7 (see WebApplicationInitializer Javadoc), and ServletContainerInitializer support under WAS 8 is problematic based on our preliminary research. GlassFish 3.1 behaves correctly.

See also the 'servlet3' branch of Spring's "Greenhouse" reference application, which, with this one commit has been refactored to take advantage of this new support: spring-attic/greenhouse@213d2c7

@Mike, thanks for your initial submission on this front. There will certainly be room for fine tuning this approach post 3.1 M2, so we'd love to have your feedback.

commit 886c89cf8b126dff1cd1c036f91bfaeb4779ad8f
Author: Chris Beams <cbeams@vmware.com>
Date:   Tue May 31 01:12:34 2011 +0000

    Sort WebApplicationInitializers properly
    
    Issue: SPR-7672
    
commit e6820ecebb935f01e0bceaf4b174e17f5732a15e
Author: Chris Beams <cbeams@vmware.com>
Date:   Mon May 30 12:57:19 2011 +0000

    Introduce DelegatingFilterProxy constructors
    
    Issue: SPR-7672
    
commit bd3cfea19ad21d594dbb32518e1cf6babf02240b
Author: Chris Beams <cbeams@vmware.com>
Date:   Mon May 30 12:56:01 2011 +0000

    Introduce ContextLoader(Listener) constructors
    
    Constructors have been added to both ContextLoader and
    ContextLoaderListener to support instance-based programmatic
    registration of listeners within ServletContainerInitializer
    implementations in Servlet 3.0+ environments, and more particularly
    when using Spring 3.1's WebApplicationInitializer SPI.
    
    Issue: SPR-7672
    
commit bd541aca940e2a3f6487ae4f1e9c3512024a92db
Author: Chris Beams <cbeams@vmware.com>
Date:   Mon May 30 12:54:48 2011 +0000

    Introduce Framework/DispatcherServlet constructors
    
    Constructors have been added to both FrameworkServlet and
    DispatcherServlet to support instance-based programmatic registration
    of Servlets within ServletContainerInitializer implementations in
    Servlet 3.0+ environments, and more particularly when using Spring 3.1's
    WebApplicationInitializer SPI.
    
    This change also renames the method added to FrameworkServlet in
    SPR-8185 from #initializeWebApplicationContext to #applyInitializers.
    The reason being that a method named #initWebApplicationContext was
    already present and the names overlapped confusingly.
    
    Issue: SPR-7672, SPR-8185
    
commit c28157344b95048d29dffb6dfb6b45a36e753396
Author: Chris Beams <cbeams@vmware.com>
Date:   Mon May 30 12:53:57 2011 +0000

    Update GenericWAC to implement ConfigurableWAC
    
    GenericWebApplicationContext now implements
    ConfigurableWebApplicationContext in order to be compatible with
    Framework/DispatcherServlet and ContextLoader/Listener, especially with
    regard to changes in SPR-7672 that allow for programmatic use of these
    types within Servlet 3.0+ environments.  For the first time, it's now
    reasonable to imagine injecting a GWAC into DispatcherServlet; the most
    robust way to accommodate this possibility is for GWAC to implement
    CWAC.
    
    The implementation is in name only, allowing for interchangable use of
    GWAC anywhere, for example, an XWAC could otherwise go.  Methods such
    as setConfigLocation will throw UnsupportedOperationException if the
    configLocation value actually contains text.  Other methods are
    implemented as no-ops or to throw UOE as appropriate.
    
    Issue: SPR-7672
    
commit fa99401dffbb424d01b13928f1ead431d3a6427a
Author: Chris Beams <cbeams@vmware.com>
Date:   Mon May 30 12:53:32 2011 +0000

    Introduce Servlet 3.0 WebApplicationInitializer
    
    WebApplicationInitializer provides a programmatic alternative to the
    traditional WEB-INF/web.xml servlet container deployment descriptor
    for Servlet API 3.0+ environments.
    
    This is done by building atop the new ServletContainerInitializer
    support in Servlet 3.0. See SpringServletContainerInitializer for
    complete details. And see WebApplicationInitializer Javadoc for
    typical usage examples.
    
    Issue: SPR-7672
    
commit d9b73461ff8a59fae21f73543b7bbeb2b7734586
Author: Chris Beams <cbeams@vmware.com>
Date:   Thu May 26 13:34:21 2011 +0000

    Upgrade javax.servlet dependency to 3.0 for .web
    
    In support of SPR-7672 which will support code-based configuration
    alternatives to web.xml using new features in the Servlet 3.0 API.
    
    This upgrade does *not* force Spring users to upgrade to Servlet 3.0
    capable containers.  Compatibility with and support for
    javax.servlet >= 2.4 remains.
    
    Issue: SPR-7672