Improve Servlet 3 presence check in ServletServerHttpResponse [SPR-11712]

[spring-projects-issues]

Francisco Lozano opened SPR-11712 and commented

Caused by: java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getHeader(Ljava/lang/String;)Ljava/lang/String;
	at org.springframework.http.server.ServletServerHttpResponse$ServletResponseHttpHeaders.getFirst(ServletServerHttpResponse.java:136) ~[spring-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.http.HttpHeaders.getContentType(HttpHeaders.java:330) ~[spring-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.http.converter.AbstractHttpMessageConverter.write(AbstractHttpMessageConverter.java:171) ~[spring-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.writeWithMessageConverters(AbstractMessageConverterMethodProcessor.java:148) ~[spring-webmvc-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.HttpEntityMethodProcessor.handleReturnValue(HttpEntityMethodProcessor.java:125) ~[spring-webmvc-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:71) ~[spring-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:122) ~[spring-webmvc-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:749) ~[spring-webmvc-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:689) ~[spring-webmvc-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:83) ~[spring-webmvc-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:938) ~[spring-webmvc-4.0.3.RELEASE.jar:4.0.3.RELEASE]
	... 33 common frames omitted

Offending code is:

	/**
	 * Extends HttpHeaders with the ability to look up headers already present in
	 * the underlying HttpServletResponse.
	 *
	 * <p>The intent is merely to expose what is available through the HttpServletResponse
	 * i.e. the ability to look up specific header values by name. All other
	 * map-related operations (e.g. iteration, removal, etc) apply only to values
	 * added directly through HttpHeaders methods.
	 *
	 * @since 4.0.3
	 */
	private class ServletResponseHttpHeaders extends HttpHeaders {

		private static final long serialVersionUID = 3410708522401046302L;

		@Override
		public String getFirst(String headerName) {
			String value = servletResponse.getHeader(headerName);
			if (value != null) {
				return value;
			}
			else {
				return super.getFirst(headerName);
			}
		}

In theory Spring 4.0 webapps should work in 2.5, as mentioned in http://docs.spring.io/spring/docs/current/spring-framework-reference/html/new-in-4.0.html

Java EE version 6 or above is now considered the baseline for Spring Framework 4, with the JPA 2.0 and Servlet 3.0 specifications being of particular relevance. In order to remain compatible with Google App Engine and older application servers, it is possible to deploy a Spring 4 application into a Servlet 2.5 environment. However, Servlet 3.0+ is strongly recommended and a prerequisite in Spring’s test and mock packages for test setups in development environments.

---

Affects: 4.0.3

Issue Links:

• Regression: AbstractHttpMessageConverter does not set ContentType [SPR-11685] #16308 Regression: AbstractHttpMessageConverter does not set ContentType
• CORS for websocket breaks existing CORS Filter [SPR-11443] #16069 CORS for websocket breaks existing CORS Filter

[spring-projects-issues]

Francisco Lozano commented

Forgot to mention - 4.0.2.RELEASE works well

[spring-projects-issues]

Juergen Hoeller commented

Spring 4.0 based webapps should not only work on Servlet 2.5 in theory but also in practice :-)

So this is indeed a bug: Apparently our conditional Servlet 3 check is incomplete in this specific code path. We'll fix this for 4.0.4.

Juergen

[spring-projects-issues]

Rossen Stoyanchev commented

Taking a closer look at the stack trace, it implies the very check for the presence of Servlet 3 returns true when it should be false. ServletServerHttpResponse checks for the presence of "javax.servlet.AsyncContext" on the classpath and creates in instance of HttpHeaders accordingly. The question is why does that return true?

Is it possible that the build is including a Servlet 3 API jar in the war either as a "compile" dependency (might have been intended as "provided") or perhaps it's getting pulled in as a transitive dependency? Check the content of the WEB-INF/lib for a servlet-api jar. Also check the dependencies of the build (e.g. "mvn dependency:tree").

I'm unable to reproduce the issue with Tomcat 6 (Servlet 2.5). The spring-mvc-showcase runs okay and the servlet3Present flag is false as it should be.

[spring-projects-issues]

Francisco Lozano commented

It makes sense. This is not a .war deployment but rather a maven integration test build with an embeded (2.5) servlet container, and javax.servlet-api-3.1.0.jar is around (as transitive dependency that I didn't notice).
Apologies for the unneeded red flag.

PS: It could be great if "version" could be enforced by some system property to override this kind of detection...

[spring-projects-issues]

Juergen Hoeller commented

Actually, it will probably help to refine the check from the current attempt to load a new Servlet 3 specific class to a check on a Servlet 2.5 existing interface, e.g.

private static final boolean servlet3Present =
          ClassUtils.hasMethod(HttpServletResponse.class, "getHeader", String.class);

That will lead to a correct result even if a Servlet 2.5 API jar comes before a Servlet 3.x API jar on the classpath, since we're checking an artifact that's being found in the former jar.

As a side note, this also checks for the very method that we're then using in ServletResponseHttpHeaders. Such a specific check is always preferable if possible.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Fixed as suggested. To appear in a 4.1 snapshot ASAP, and in a 4.0.4 snapshot tomorrow.

Juergen