The System Requirements documentation specifies which versions are supported. However, not all patch versions of Tomcat v10.1.x are supported. For example, since #41093, only Tomcat v10.1.25 or later are supported. Running a Spring Boot v3.3.4 application on Tomcat v10.1.24 or lower will result in an error since AbstractProtocol.setMaxQueueSize(int) does not exist.
Should the documentation make it more clear that certain patch versions won't work? For example, is it useful to update it to:
Name Servlet Version Tomcat 10.1 (10.1.25 or later) 6.0 Jetty 12.0 6.0 Undertow 2.3 6.0
Or would this cause too much of a maintenance burden?
Comment From: wilkinsona
Out of interest, what's your use case for downgrading Tomcat?
Comment From: g00glen00b
I don't have a use case myself but I encountered this problem while answering a question on Stack Overflow. So this is my best guess:
The OP of that question is using a combination of running an embedded Tomcat during development, and traditional deployment on an external Tomcat on other environments. That external Tomcat happens to be on v10.1.6. I assume they're not able to upgrade that Tomcat, so they decided to downgrade their embedded Tomcat in stead by overriding the tomcat.version property, which resulted in an error during startup.
They referenced the System Requirements page, arguing that it should be possible to use any Tomcat v10.1.x version, and I understand the confusion, which is why I opened this issue.
For context, here is the Q&A: https://stackoverflow.com/q/79116989
Comment From: wilkinsona
Thanks for the background and for helping the community on Stack Overflow.
IMO, they're reading a little too much into that table. In the section on customizing dependency versions, we warn that "each Spring Boot release is designed and tested against this specific set of third-party dependencies. Overriding versions may cause compatibility issues". That's what's happening here.
That said, usually, we do try to be more tolerant of older versions of Tomcat. Unfortunately, that wasn't possible in this case as falling back to the old way of doing this would reintroduce #40945 and #40957.
In short, I think it's worth noting that we require at least 10.1.25.