Jetty 11 and spring boot = problem without servlet 6 support

[mikebell90]

Jetty version(s)
Jetty 9.x is now at End of Community Support

Enhancement Description
Please consider backporting servlet 6 to jetty 11.

Reasoning : spring boot is compiled with servlet 6 . As a result spring boot tests fail when you backrev to servlet 5. They made this change last minute because of tomcat

jetty 12 is looking from its release candidate as end of year at best and the spring boot folks say due to breaking changes it’s not clear when they will fix this

spring-projects/spring-boot#33044

[gregw]

Jetty 12 is intended to be release end Q2 or beginning Q3. It is our intention to then focus on helping other project (like springboot) move to it.

The work required to backport servlet 6 to jetty-11 is significant. Perhaps we could do a jetty-11.1 that compiled against serlvet 6, but had servlet 5 behaviours. However that is still significant effort and another branch would just dilute the projects resources. It is not something that is going to happen unless there is commercial backing.

Jetty 12 is passing both Servlet 5 and Servlet 6 TCK tests (excluding cross context support) and performance has been significantly improved. We are currently cleaning up any needless behaviour changes and still have a reasonable job list. But a usable release is not too far away.

[mikebell90]

This is an honest and professional answer and I definitely appreciate. However given the WebSocket changes, I ssupect Spring Boot will not release Jetty 12 support (officially anyway) until SBT 3.2 in about 11 months. But we'll see.

[gregw]

I'm reopening this so that we will have a good think about how best to work with spring boot between the release of jetty 12 and the next spring boot release.

[mikebell90]

Thanks Greg. BTW as the servlet maintainer I shouldn't tell this lest you get apoplexy, but right now we are trying copying Cookie.java and ServletConnection.java to a forked Servlet 5, as those seem to make Spring happy. Not that I think that's at ALL a good idea ;). The Cookie changes look safish, but of course there is no concrete implementation of ServletConnection, which they simply mock. I concede all of this is silly, and in no way sane.

[anbusampath]

I ssupect Spring Boot will not release Jetty 12 support (officially anyway) until SBT 3.2 in about 11 months.

Spring Boot 3.2 GA targeted for November - https://github.com/spring-projects/spring-boot/milestone/308

Once Jetty 12 is GA with Servlet 6 support, Spring Framework and Spring Boot might pick up it right away for upcoming releases - spring-projects/spring-framework#30698

[olamy]

see comment here #9173 (comment)

[mikebell90]

If you read things like spring-projects/spring-framework#30698 (comment) It doesn’t sound at all straightforward or likely to happen even in a few months

…

On Wed, Jun 21, 2023 at 7:05 PM Anbu Sampath ***@***.***> wrote: I ssupect Spring Boot will not release Jetty 12 support (officially anyway) until SBT 3.2 in about 11 months. Spring Boot 3.2 GA targeted for November - https://github.com/spring-projects/spring-boot/milestone/308 Once Jetty 12 is GA with Servlet 6 support, Spring Framework and Spring Boot might pick up it right away for upcoming releases - spring-projects/spring-framework#30698 <spring-projects/spring-framework#30698> —

[gregw]

@mikebell90 one of the key features of jetty 12 is that it will support Servlet API 4, 5, or 6... or no servlet API at all if you just want HTTP support.

Could you say why a user of springboot would want a specific version of the servlet API? Is there a market for springboot without servlet support at all (as that would be smaller and faster).

Can you point us to where a springboot user can see through springboot to see the actual servlet API or any aspects of the server itself?

[grgrzybek]

Allowing myself to get involved in the discussion, I can point to one opinionated place where Spring Boot declares what it uses - the Spring Boot BOM. It can declare only one Maven managed dependency on single groupId/artifactId pair (jakarta.servlet/jakarta.servlet-api).

I can also speak from Pax Web (OSGi) perspective where I can admire much more the multi Servlet API approach of Jetty 12. In OSGi we can mix javax and jakarta Servlet API in the same JVM.

[gregw]

Excuse my naivete with spring boot..... but from my understanding you can declare arguments to mapped methods and springboot will do the work to provide those arguments from the request/response and hence you get a range of different application types:

• some apps that doesn't care about servlets nor even request/responses and will simply use arguments like @RequestBody JsonObject that are independent of servlets or any request/response abstraction
• other apps do care about request/responses, but not about the servlet API, so they will use o.s.h.s.reactive.ServerHttpResponse
• Other applications may wish to access the servlet request/response, so they can include those as arguments to a mapped method.

So I'm thinking that we should work to provide a mapping directly from the jetty 12 asynchronous request/response abstraction to the springboot reactive webflux. We should also continue to support the servlet API approach for those that want to also access the servlet request/response. What I don't know, is would it be possible for springboot to introspect the mapped method, and to see a Servlet API X.0 argument and then to use Jetty 12 configured to support that API to service that method. It might then be possible to have different servlet API versions supported within the same JVM using springboot. I'm not sure if this is possible, nor even if it is desirable, but we can definitely think about it if there is interest.

[github-actions]

This issue has been automatically marked as stale because it has been a
full year without activity. It will be closed if no further activity occurs.
Thank you for your contributions.

[mikebell90]

This can be closed. It remains a difficult issue with Jetty 11, but as of Spring Boot 3.2, Jetty 12 is supported and can bind full servlet 6 support