On 3/27/24 08:26, Romain Manni-Bucau wrote:
Hi Chris,

Le mer. 27 mars 2024 à 13:13, Christopher Schultz <> a écrit :


On 3/27/24 06:13, Romain Manni-Bucau wrote:
Le mer. 27 mars 2024 à 10:58, Rémy Maucherat <> a écrit :

On Wed, Mar 27, 2024 at 9:49 AM Romain Manni-Bucau
<> wrote:

Hi all,

Checkout out TomEE's notifications I realized Tomcat is in a weirdish
situation where Tomcat 9 is Servlet 4 and "+1" version is Tomcat 10.1
is Servlet 6.
It means Tomcat is no more a Servlet 5 friendly option.

I wonder if it means Tomcat < 10.1 should be stopped too or if Tomcat
should be maintained and released again - pretty sure we can find help
desired for that not that far.
Another option is to restore the deleted methods between servlet 5-6 in
code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.


Nothing. The Tomcat developers (= the committers) determined that the
EE 9 release was useless since the only change is the javax -> jakarta
package renaming. A big task for sure, but that seemed to us this was
more a developer oriented armaggeddon and not something that benefits
our users.

For reasons that elude my understanding, some other projects like
TomEE thought this was still useful and decided to release full
support for EE 9 rather than go to EE 10 like we did. Our plan about
EE was public. So I guess this is still our problem obviously, but I
don't feel like doing anything about it.

  From what I saw on other AsfEE projects, users requested it, nothing
and then you have CVE game.

BTW, about the last item. Recently, I tried to run CXF on the new EE
10 APIs (since OWB moved to that). It doesn't work as it uses
deprecated APIs, while IMO it should have moved away from them long
ago. And it's an ASF project, not some hack project somewhere.

This is fixed AFAIK on master (maybe last release, didnt check) so should
be fine soon.

Basically unless there's a cut somewhere, nothing will ever change :D
As a result, I don't think an API restoration in Tomcat 10.1 is a good
idea ...

Ok, so last option is TomEE community taking the lead on 10.0 branch, is
that an option if all the PR work is done?

Is the problem that you have customers actually using these APIs?

Or is the problem that you can't pass a TCK unless you have support for
these ancient methods?

A bit both, have to admit I lost a bit track of original user request and
if they adopted it or not but TCK point is important and justifies today a
complete tomcat fork which is quite not understandable for me from an ASF

It sounds like you are saying "we over at TomEE need something and because we are both ASF projects, Tomcat really ought to do this work for us". That doesn't sound very nice to me.

You asked us, and we told you we don't care to scratch that particular itch. *shrug*

Most of that stuff was deprecated ages ago and just finally removed.

Why is it super important for you to get certified for Servlet 5
specifically? Why not just get Jakarta EE 10 certified and move on? Any
applications that would actually fail on Tomcat 10.1 + Migration Tool
really really _really_ need to be updated to work properly. People have
had 15 years to stop using that stuff.

This is the plan, but for the same reason you don't want to release 10.0,
certification is not a one week fork, tomee 10m1 is planned but in the
meantime having tomee 9 (servlet 5) certified would be very welcomed.
That said should I read it as you are proposing yourself to help? (trying

Yeah... no.

I was just suggesting that maybe the patch set isn't really that big. And that you shouldn't bother yourself with 10.0 because nobody should use it. It's probably riddled with unfixed CVEs that actually-supported versions of Tomcat have fixed and released.

Honestly, I think it would be much more worth you while to fork Tomcat
10.1 and add-back the methods you need rather than trying to resurrect
the 10.0 branch. There have been no commits on that branch for 2 years,
and we've had something like ~24 releases of each other branch in the
meantime. That includes performance improvements, security fixes,
feature and stability improvements, etc.

Would it be as simple as providing your own replacements for deprecated
classes/methods to pass the TCK? That seems far less onerous than
bringing back zombie Tomcat 10.0.

Asked this morning the same question but it is still being investigated if
possible but still means forking at some point so gain is not really huge
for the project - can be for end users, agree.

You don't really need to fork. You just need a patch-set which is hopefully small. I suppose you could maintain a fork, but I don't think it would be that onerous.

I would like to see what your investigation reveals.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to