-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Dependency on Servlet 4.0 in spring-test makes it challenging to have Servlet 3.1 at runtime #26555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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.
Similar statements are present in the Javadoc for 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. |
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? |
We've decided to unroll the change in |
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). |
Spring Framework 5.x is documented as requiring only Servlet 3.1 (EE7). However, a recent change (commit f22e2ac by @rstoyanchev, included in 5.3.4) introduces a reference to
javax.servlet.http.HttpServletMapping
intoMockHttpServletRequest
.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.
The text was updated successfully, but these errors were encountered: