During the upgrade to JEE9 and Spring 6.1, found some test issues that result in the following exception:
java.lang.NoSuchMethodError: 'java.lang.String org.springframework.mock.web.MockCookie.getAttribute(java.lang.String)
at org.springframework.mock.web.MockCookie.getSameSite(MockCookie.java:98)
at org.springframework.mock.web.MockHttpServletResponse.getCookieHeader(MockHttpServletResponse.java:485)
at org.springframework.mock.web.MockHttpServletResponse.setCookie(MockHttpServletResponse.java:773)
at org.springframework.mock.web.MockHttpServletResponse.setSpecialHeader(MockHttpServletResponse.java:739)
at org.springframework.mock.web.MockHttpServletResponse.setHeaderValue(MockHttpServletResponse.java:697)
at org.springframework.mock.web.MockHttpServletResponse.setHeader(MockHttpServletResponse.java:674)
After some digging, it appears that MockCookie is calling a Servlet 6.0 API that does not exist in Servlet 5.0
As per Spring-Framework-Versions#javajakarta-ee-versions, Spring Framework 6.1.x: Jakarta EE 9-10 (jakarta namespace)
mentions that Spring 6.1 is compliant is JEE9, however with this dependency for tests, it appears to be broken with requirement on Servlet 6.0
I do NOT see any mentions of requiring Servlet 6.0 in the Spring-Framework-6.1-Release-Notes.
This is the commit that introduced dependency on Servlet 6.
Is this a deliberate requirement, or was it simply an oversight?
Is it feasible to keep Spring 6.1 fully compatible with JEE9 (including tests), ensuring that users won’t face the additional challenge of upgrading to the JEE10 ecosystem?
This approach would significantly reduce the burden on consumers, allowing them to continue their work without the added complexity of transitioning to a newer, potentially disruptive platform.
Comment From: bclozel
This is expected and called out in the Upgrading from Spring Framework 5.3 notes:
The Spring-provided Servlet mocks (MockHttpServletRequest, MockHttpSession) require Servlet 6.0 now, due to a breaking change between the Servlet 5.0 and 6.0 API jars. They can be used for testing Servlet 5.0 based code but need to run against the Servlet 6.0 API (or newer) on the test classpath. Note that your production code may still compile against Servlet 5.0 and get integration-tested with Servlet 5.0 based containers; just mock-based tests need to run against the Servlet 6.0 API jar.
Please make sure to upgrade your application iteratively, minor version by minor version, for a smoother experience. Thanks!
Comment From: rahulsh1
Thanks for pointing out this update @bclozel
I understand that breaking changes are expected between major versions, but could you clarify the rationale behind using the Servlet 6.0 API exclusively for mock-based tests? Would it be possible to maintain compatibility with Servlet 5.0 for both 6.0 and 6.1?
Changes like these introduce significant complexity to the migration process. Because of inconsistencies like this, we’re unable to take an incremental approach, which forces a more disruptive, all-at-once upgrade. This not only impacts development timelines but also increases the risk of errors and integration issues. A more consistent approach would ease the transition and make the migration much more manageable.
Comment From: bclozel
I understand that breaking changes are expected between major versions, but could you clarify the rationale behind using the Servlet 6.0 API exclusively for mock-based tests? Would it be possible to maintain compatibility with Servlet 5.0 for both 6.0 and 6.1?
We did our best to avoid this situation, but as explained by Juergen on the original issue we didn't have much choice here.
Changes like these introduce significant complexity to the migration process. Because of inconsistencies like this, we’re unable to take an incremental approach, which forces a more disruptive, all-at-once upgrade. This not only impacts development timelines but also increases the risk of errors and integration issues. A more consistent approach would ease the transition and make the migration much more manageable.
We're very much aware of this and do our best to have the smoothest upgrade experience possible. I guess that in this case, the actual trigger for a more disruptive upgrade is the fact that Spring Framework 6.0 is already out of OSS support and that you're not getting the commercial releases with CVE fixes.
If you want to get the best upgrade experience for your applications, testing our milestone releases and giving us feedback is the best way to influence the roadmap. For example, we're about to release our first Framework 7.0 milestone in January and we've already started documenting the expected changes.
Thanks!