Support Apache Tomcat 10 #144
Comments
|
@acestars - yes, support for Tomcat 10 is most definitely on the roadmap. Pull-request are welcome. Can you share a link about these "different dependencies" that you mention? |
|
@boris-petrov you can read at https://tomcat.apache.org/migration-10.html. The packages required by Tomcat 10 changed from javax.* to jakarta.* |
|
I produced a (failed) proof-of-concept in my branch feature/tomcat-ten. The build is passing, however, there are some caveats. I left a couple of It was a bit disappointing because trying to support legacy APIs in the "javax" namespace parallel to Jakarta introduced a mess. Rather than having a ready implementation I worked out areas in which Gretty requires more work (for supporting Tomcat 10, and Jetty 10). To my knowledge, a compatibility layer does not exist, which would help with the transition. As I understand, this is generally a good thing: we must get rid of the "javax" trademark - which has to happen sometime - and migration aids would simply delay the change. It's a breaking one, but for most projects far from impossible. In return we get APIs which can evolve. For Gretty, this means a number of modules / components are replicated (copied) in the current proof of concept with changed import statements:
Because this list only speaks for Tomcat, it is likely incomplete. The last point - integration tests - is by far the heaviest. All integration tests would have to be replicated to use the new imports. This is why my PoC only contains a single, copied "hello world" integration test for Jakarta. So the current Tomcat 10 server container adapter is covered by only 1 out of more than 30 test cases. Out of this experience I make the following proposal. The scope of supporting Jakarta-enabled servlet containers such as Tomcat 10 extends to:
I think if none of the apps deployed from Gretty can use e.g. Tomcat 9 and 10 in parallel, there is no point in having a version of Gretty which can support both at the same time. |
|
@f4lco - thanks a lot for your time and the work you've done! Here's my 5 cents. I think what you suggest makes perfect sense. I would make it the other way around though - make a branch for the "jakarta" things and leave I'm not sure I understand why point 3 is in your list - isn't the "work" there just renaming imports? Theoretically everything should work straight away, right? We don't expect anything to be broken or do we? Also, there is another option. We could play with the build system, implement some C-style macros like |
Yes, that's reasonable, too. The main takeaway from the branching model is that I assume there are two branches to deploy from for an extended period of time (the transition period between javax and jakarta; former for bugfixes and the latter for ongoing development).
Yes, you are totally right, technically it is just doing the imports. However, this is still the area of most uncertainty, because we do not know exactly which other breaking changes Jetty 10 or Tomcat 10 may introduce. Ideally, all tests simply and reliably pass. Thanks @boris-petrov for your quick response, hearing feedback and agreeing on what to do in the scope of this issue is a good first step in direction of Tomcat 10. |
|
@f4lco - no, thank you for the time you spend on this. I gave you commit rights to the repository - you can go ahead with creating the branch and porting over your changes from your branch to it when you have the time. 😄 |
|
Cool @boris-petrov I did not see that one coming 😃 This gave me extra motivation to spend two spare hours in which I discovered that the tests indeed do not magically pass. At least there are deprecations in the SSL config of Tomcat 10 which require rework. |
|
@f4lco - I see. It's great to see progress! I doubt that the changes needed will be big - I remember that we did some refactoring to support Tomcat 8.5 and 9 (in order to DRY up a bunch of stuff) but after that everything worked fine. I hope it won't be too difficult now either. Please keep us posted on the changes and problems - I'll try to help as much as I can. :) |
The WebappLoader lost the ctor with the parent class loader parameter and instead sets the reference from the started context. Alas, it should be possible to directly set the parent class loader on the context, and it should just function as before.
The SSL configuration of Tomcat 9 does not work any longer. The existing implementation used deprecated property names. Additionally, the SSLHostConfig configuration object is no longer created automatically if missing. Compare: http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2_(deprecated) to: http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support_-_SSLHostConfig
Calling toString() is mandatory, otherwise the call does not match the method signature of setProperty(String, String). This is now analog to the treatment of httpIdleTimeout, which already stringifies the property value.
Connector#setProperty is a bit of a lie. It does not set properties
on the Connector. Rather, the method set properties on the protocol
handler which is part of the connector.
Thus, the previous implementation tried to set a connector property
using setProperty, which was never successful.
Instead we directly set the property of the connector. To achieve
the original intent ("unlimited post size") the value must be
below zero. Compare:
http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#Common_Attributes
Connector#setProperty returns a success boolean. If the property is deprecated or goes missing, we will immediately notice.
While a recent Jersey version provides "jakarta"-ified APIs, we are still unable to deploy it because Jersey depends on the javax.servlet classes internally (for instance in org.glassfish.jersey.servlet.ServletContainer). We'll have to wait for a compatible release of Jersey.
There is already some preliminary work which pulls in dependencies for Jetty 10. Because Jetty 10 raises the minimum supported Java version to 11, Gretty will also require JDK 11 to compile and run. Source: https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
The SSL configuration of Tomcat 9 does not work any longer. The existing implementation used deprecated property names. Additionally, the SSLHostConfig configuration object is no longer created automatically if missing. Compare: http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2_(deprecated) to: http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support_-_SSLHostConfig
Calling toString() is mandatory, otherwise the call does not match the method signature of setProperty(String, String). This is now analog to the treatment of httpIdleTimeout, which already stringifies the property value.
Connector#setProperty is a bit of a lie. It does not set properties
on the Connector. Rather, the method set properties on the protocol
handler which is part of the connector.
Thus, the previous implementation tried to set a connector property
using setProperty, which was never successful.
Instead we directly set the property of the connector. To achieve
the original intent ("unlimited post size") the value must be
below zero. See:
http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#Common_Attributes
Connector#setProperty returns a success boolean. If the property is deprecated or goes missing, we will immediately notice.
The WebappLoader lost the ctor with the parent class loader parameter and instead sets the reference from the started context. Alas, it should be possible to directly set the parent class loader on the context, and it should just function as before.
While a recent Jersey version provides "jakarta"-ified APIs, we are still unable to deploy it because Jersey depends on the javax.servlet classes internally (for instance in org.glassfish.jersey.servlet.ServletContainer). We'll have to wait for a compatible release of Jersey.
There is already some preliminary work which pulls in dependencies for Jetty 10. Because Jetty 10 raises the minimum supported Java version to 11, Gretty will also require JDK 11 to compile and run. Source: https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
|
Closing: the Tomcat 10 connector landed in long-lived feature branch "gretty4". I assume it will take time to release anything Jakarta-related. A milestone is in place: https://github.com/gretty-gradle-plugin/gretty/milestone/2 |
The WebappLoader lost the ctor with the parent class loader parameter and instead sets the reference from the started context. Alas, it should be possible to directly set the parent class loader on the context, and it should just function as before.
While a recent Jersey version provides "jakarta"-ified APIs, we are still unable to deploy it because Jersey depends on the javax.servlet classes internally (for instance in org.glassfish.jersey.servlet.ServletContainer). We'll have to wait for a compatible release of Jersey.
There is already some preliminary work which pulls in dependencies for Jetty 10. Because Jetty 10 raises the minimum supported Java version to 11, Gretty will also require JDK 11 to compile and run. Source: https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
The WebappLoader lost the ctor with the parent class loader parameter and instead sets the reference from the started context. Alas, it should be possible to directly set the parent class loader on the context, and it should just function as before.
While a recent Jersey version provides "jakarta"-ified APIs, we are still unable to deploy it because Jersey depends on the javax.servlet classes internally (for instance in org.glassfish.jersey.servlet.ServletContainer). We'll have to wait for a compatible release of Jersey.
There is already some preliminary work which pulls in dependencies for Jetty 10. Because Jetty 10 raises the minimum supported Java version to 11, Gretty will also require JDK 11 to compile and run. Source: https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
Is there any plan to support apache tomcat 10? Because Apache Tomcat 10 has different dependencies.
The text was updated successfully, but these errors were encountered: