Propagate fully capable ServletContext in AbstractContextLoaderInitializer (for SessionCookieConfig access)

[vpavic]

Affects: 5.1.4.RELEASE

In Spring Session, we try to provide convenience of configuring our default CookieSerializer using Servlet API's SessionCookieConfig. The code involved can be seen here.

In a plain Spring app, without Spring Boot involved, this fails with Java based config due to inability to obtain SessionCookieConfig off injected ServletContext. However, the same action succeeds with XML based config.

I've put together a minimal sample app that exhibits this behavior.

Running XML config based sample using ./gradlew :sample-xml:tomcatRun will yield the following log output:

Jan 29, 2019 12:38:24 AM sample.Config setServletContext
INFO: Obtained SessionCookieConfig: org.apache.catalina.core.ApplicationSessionCookieConfig@5fbade79

While running Java config based sample using ./gradlew :sample-java:tomcatRun will result in the following error logged:

Jan 29, 2019 12:38:14 AM sample.Config setServletContext
WARNING: Cannot obtain SessionCookieConfig
java.lang.UnsupportedOperationException: Section 4.4 of the Servlet 3.0 specification does not permit this method to be called from a ServletContextListener that was not defined in web.xml, a web-fragment.xml file nor annotated with @WebListener
        at org.apache.catalina.core.StandardContext$NoPluggabilityServletContext.getSessionCookieConfig(StandardContext.java:6891)
        at sample.Config.setServletContext(Config.java:20)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:708)
        at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90)
        at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:374)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1378)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:575)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:498)
        at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:846)
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:863)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:546)
        at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:400)
        at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:291)
        at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:103)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4898)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5363)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1410)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1400)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

This was originally reported against Spring Session in spring-projects/spring-session#1040.

[sbrannen]

Interesting... when the Servlet container is initialized via the infrastructure in AbstractAnnotationConfigDispatcherServletInitializer the ServletContext injected into your code is an instance of Tomcat's org.apache.catalina.core.StandardContext.NoPluggabilityServletContext which is documented as follows.

The wrapped version of the associated ServletContext that is presented to listeners that are required to have limited access to ServletContext methods. See Servlet 3.1 section 4.4.

That implementation always throws an UnsupportedOperationException for getSessionCookieConfig().

[sbrannen]

Thus, it would appear that getSessionCookieConfig() is officially unsupported when Spring's ContextLoaderListener is registered programmatically as in AbstractContextLoaderInitializer.registerContextLoaderListener(ServletContext).

[sbrannen]

Specifically, the following code from Tomcat's org.apache.catalina.core.StandardContext.listenerStart() method ensures that the Spring ContextLoaderListener receives a NoPluggabilityServletContext which wraps the real, underlying ServletContext.

        for (Object lifecycleListener: getApplicationLifecycleListeners()) {
            lifecycleListeners.add(lifecycleListener);
            if (lifecycleListener instanceof ServletContextListener) {
                noPluggabilityListeners.add(lifecycleListener);
            }
        }

[sbrannen]

I'm not yet sure what we can do here to make this work, but I've tentatively slated this for 5.2 for further investigation.

[sbrannen]

In the interim -- not that I'd really recommend it -- you could introduce a hack that works on that particular version of Tomcat by using reflection to access the underlying sc field in org.apache.catalina.core.StandardContext.NoPluggabilityServletContext.

    private static class NoPluggabilityServletContext
            implements ServletContext {

        private final ServletContext sc;

[vpavic]

Thanks for the feedback @sbrannen.

Unfortunately, since we're hitting this limitation in Spring Session configuration infrastructure, any workaround that involves specific Servlet Container classes is not viable.

I should have probably mentioned that the code involved also works in a Spring Boot app - I didn't include that in the sample repo though.

[sbrannen]

Unfortunately, since we're hitting this limitation in Spring Session configuration infrastructure, any workaround that involves specific Servlet Container classes is not viable.

Sure. That was actually intended to be more of a joke, which I should have stated explicitly. 😉

You'd obviously need a solution that works across containers and according to the Servlet spec.

I should have probably mentioned that the code involved also works in a Spring Boot app - I didn't include that in the sample repo though.

Interesting. In the sample you provided it appears that Tomcat is behaving according to the spec, so it might well be that the Spring Boot embedded Servlet container support registers the Spring ContextLoaderListener differently.

We'll have to take a look at what Spring Boot does in order to better understand the issue at hand.

Thanks for the feedback!