Spring Framework 5.x is documented as requiring only Servlet 3.1 (EE7). However, a recent change (commit f22e2ac578f6db8f988cbbee0af5f381a86fdd04 by @rstoyanchev, included in 5.3.4) introduces a reference to javax.servlet.http.HttpServletMapping into MockHttpServletRequest.

The referenced API is part of Servlet 4.0 (EE8) and is not present in Servlet 3.1.

It seems extremely unlikely that a dependency change to a new major version of the Servlet spec was intentionally introduced as part of a patch release of Spring Framework.

If I am not misunderstanding something here, it seems like this would need to be reverted.

Comment From: sbrannen

Spring Framework 5.3 supports Servlet 3.1 at runtime.

But... Spring's testing support for Servlet-based mocks requires Servlet 4.0. The Servlet API section of the Testing chapter states the following.

Since Spring Framework 5.0, the mock objects in org.springframework.mock.web are based on the Servlet 4.0 API.

Similar statements are present in the Javadoc for MockHttpServletRequest and related classes in that package.

Thus, you may need Servlet 4.0 on the classpath for your tests, but you are free to deploy your application on a server supporting Servlet 3.1.

In light of that, I am closing this issue.

Comment From: gionn

Thus, you may need Servlet 4.0 on the classpath for your tests, but you are free to deploy your application on a server supporting Servlet 3.1.

Hi, we are using Spring with embedded Jetty on a maven project and I don't have any idea on how can I have a different version with different scopes of servlet-api (compile and test, in this case) without maven complaining about duplicated dependencies.

Any hints?

Comment From: rstoyanchev

We've decided to unroll the change in MockHttpServletRequest due to the practical challenges it causes in combination with Maven builds where the Servlet API is not provided.

Comment From: iay

Thanks for the change in direction. We're also Maven-based and as far as I know there's no way to (a) code against Servlet 3.1 to make sure you're only using that API while also (b) having Servlet 4.0 available in your tests. Rolling back to Spring Framework 5.2.x was looking like our best option (and we may still need to do that, depending on our release timing).