Track servlet version conventions from Spring Framework 5
Description
Environment
Activity
Scott Cantor March 22, 2021 at 9:44 PM
It should be addressed by the Spring update.
Brent Putman March 22, 2021 at 9:42 PM
In the middle of doing the release, and Jira complains that this is still open. I'm not going to stop the release, but can someone who is up-to-date on this please update the comments and close this out?
Ian Young February 23, 2021 at 2:07 PM
We decided on the 2021-02-19 developer call to revisit this at the next call on 2021-03-05, which is probably when we'll code freeze for the 4.1 release.
The hope is that we will be able to wait for the 5.3.5 release (current snapshots of which check out as functional).
Ian Young February 19, 2021 at 1:53 PM
Spring Framework has now reverted the problematic change. I built a 5.3.5-SNAPSHOT locally and our full stack now builds and runs tests OK with that and Servlet 3.1.0.
Spring Framework 5.3.x releases seem to on a roughly monthly cadence, so if that holds true we might anticipate a 5.3.5 around mid to end March.
Ian Young February 19, 2021 at 12:47 PM
https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions
Spring Framework 5.2 is supported until end of 2021.
Support for Java 17 only indicated for the 5.3 line.
In Spring Framework 5.3.4, a small change was made to one of the spring-test classes we use which has unfortunately exposed a level of misunderstanding on our part.
In short, the Spring project says:
The mock classes in spring-test are based on Servlet 4
You can however deploy applications into environments providing only Servlet 3.1
We have been assuming that the latter implied that the test classes were also based on Servlet 3.1, but that has apparently not been the case for years; we just got lucky until now.
We access the servlet API as a "provided" dependency; we never bundle an implementation. This means that, just like the Spring project, we could change the "provided" dependency version to 4.0.0 and everything would go back to working. We wouldn't be changing our ability to deploy code to a container implementing only 3.1 unless we explicitly coded something outside our tests that referenced the 4.0 API. So our "requirements" section could stay the same in this scenario.
The risk would be that we would accidentally breach that requirement and not know until we got a complaint from a deployer. We could mitigate that by CI tests in a 3.1-limited environment.
We have two supported containers: Tomcat 9+ supports Servlet 4, while our preferred Jetty 9.4+ supports only Servlet 3.1. So as long as our CI tests pass under the current version of Jetty, we know that we don't have a dependency on Servlet 4.
My proposal for digging us out of this, then:
Change the "provided" Servlet API dependency in java-parent-project to 4.0.0
Add a Great Big Comment explaining that this doesn't mean you can use the new features and need to colour within the 3.1 lines instead
Rely on our CI to keep us honest
Given the importance of this, I'd normally bring it up for discussion at our weekly meeting. However, the imminence of the 4.1 code freeze means we need to figure it out ASAP so if we can make a decision here that would be good.
The alternative would seem to be to defer this past 4.1 by not taking the 5.3.4 release of Spring Framework at this time. I don't think waiting will open up more options, unfortunately, and this would also mean that the fix Rod needs from 5.3.4 will have to be handled some other way.