On 3/29/24 03:18, Romain Manni-Bucau wrote:
Side note: what I meant about ASF is that there was a help habit between
communities. I know it got "broken" (=it is no more a general real thing)
some years ago to isolate all projects (give them a total independency) but
I'm clearly not a fan of that, in particular when it deserves the project
but I totally respect your choice, didnt mean anything stronger than a hope.

No problem. Adding the smile made it clear you were hoping about me specifically. But it wasn't clear what you were saying about the (Tomcat) project itself.

On the method addition/ TCK: no issue since signature of the api stays the
Can break tomcat facade object design - but not a big deal for me - but
clearly not tck compat.

Okay, I'm not super familiar with the TCK process itself. I had assumed that if we added arbitrary methods to the jakarta.* public interfaces, we'd fail the TCK.

If that's not the case, then...

If you build a patch set for Tomcat 10.1.x to re-add those methods and it passes your TCK, we can apply them to 10.1 nd see if we also pass the TCK.

If it passes both, I have no objection to adding those methods back to 10.1 to help-out anyone who feels strongly about supporting Servlet 5. You may find that others on the team are -1 on this; I'm not sure.

Back to practical things: if you maintain a patch set (which should be fairly limited, as I asserted and you seem to agree with) that you can apply in order to pass the TCK and that's neaarly all its for, then I think it won't be much maintenance for you to keep that set.

That is, if you either directly-fork Tomcat 10.1 or if your build process downloads the sources, patches and builds Tomcat locally, then you will pass the TCK and everyone is happy.

If your build process is strictly "download Tomcat binaries and use them" then of course it will be more complicated.


Le jeu. 28 mars 2024 à 23:13, Christopher Schultz <> a écrit :


On 3/27/24 15:29, Romain Manni-Bucau wrote:
FYI here is the diff between servlet 5 and 6 API jars:

New API: - jakarta.servlet.ServletConnection Deleted API: -
jakarta.servlet.SingleThreadModel -
- jakarta.servlet.http.HttpUtils Changed API:
jakarta.servlet.ServletContext Deleted methods: - public abstract
jakarta.servlet.ServletContext.getServlet(java.lang.String) throws
jakarta.servlet.ServletException - public abstract java.util.Enumeration
jakarta.servlet.ServletContext.getServletNames() - public abstract
java.util.Enumeration jakarta.servlet.ServletContext.getServlets() -
abstract void
jakarta.servlet.ServletRequest Added methods: - public abstract
jakarta.servlet.ServletRequest.getServletConnection() - public abstract
java.lang.String jakarta.servlet.ServletRequest.getProtocolRequestId() -
public abstract java.lang.String
jakarta.servlet.ServletRequest.getRequestId() Deleted methods: - public
abstract java.lang.String
jakarta.servlet.ServletRequestWrapper Added methods: - public
jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
Deleted methods: - public java.lang.String
jakarta.servlet.SessionCookieConfig Added methods: - public abstract
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String) -
abstract java.util.Map
- public abstract void

jakarta.servlet.UnavailableException Deleted methods: - public
jakarta.servlet.Servlet jakarta.servlet.UnavailableException.getServlet()
jakarta.servlet.descriptor.JspPropertyGroupDescriptor Added methods: -
public abstract java.lang.String

jakarta.servlet.http.Cookie Added methods: - public boolean
jakarta.servlet.http.Cookie.equals(java.lang.Object) - public int
jakarta.servlet.http.Cookie.hashCode() - public java.lang.String
jakarta.servlet.http.Cookie.getAttribute(java.lang.String) - public
java.lang.String jakarta.servlet.http.Cookie.toString() - public
java.util.Map jakarta.servlet.http.Cookie.getAttributes() - public void

jakarta.servlet.http.HttpServlet Added fields: - public static final
java.lang.String jakarta.servlet.http.HttpServlet.LEGACY_DO_HEAD Added
methods: - public void
jakarta.servlet.ServletException jakarta.servlet.http.HttpServletRequest
Deleted methods: - public abstract boolean
jakarta.servlet.http.HttpServletRequestWrapper Deleted methods: - public

jakarta.servlet.http.HttpServletResponse Deleted methods: - public

- public abstract java.lang.String
jakarta.servlet.http.HttpServletResponse.encodeUrl(java.lang.String) -
public abstract void
jakarta.servlet.http.HttpServletResponseWrapper Deleted methods: - public

- public java.lang.String

- public void

jakarta.servlet.http.HttpSession Deleted methods: - public abstract
jakarta.servlet.http.HttpSession.getSessionContext() - public abstract
jakarta.servlet.http.HttpSession.getValue(java.lang.String) - public
abstract java.lang.String[]
jakarta.servlet.http.HttpSession.getValueNames() - public abstract void

- public abstract void

It does not look crazy to get back (without @Override) deleted methods in
Tomcat - most of them are just either "return null" or a delegation to
another method so cost for tomcat is almost 0 for that side.
What I'm not yet sure - didn't have time to check yet - is if the new API
are used directly from jakarta package (if so it would fail running with
servlet 5 api else it will run smoothly and could be a win-win?).

I think if we put those methods back, then _Tomcat_ will not pass its
target TCKs since the interfaces aren't correct.

It really would require two separate builds. Yuck.


Le mer. 27 mars 2024 à 14:20, Romain Manni-Bucau <>
écrit :

Ok, let see if we can maybe have an exceptional certification status
servlet 6 as an exception but I doubt (but would make everyone happy) :(

Romain Manni-Bucau
@rmannibucau <> |  Blog
<> | Old Blog
<> | Github
<> | LinkedIn
<> | Book

Le mer. 27 mars 2024 à 14:15, Rémy Maucherat <> a écrit

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

Le mer. 27 mars 2024 à 10:58, Rémy Maucherat <> a

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
situation where Tomcat 9 is Servlet 4 and "+1" version is Tomcat
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
should be maintained and released again - pretty sure we can find
help if
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
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 ->
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
be fine soon.

I checked and there is a new CXF release from early March.

However, I still get the CDI 4 deprecation removal issue:
      Caused by: java.lang.NoSuchMethodError: 'void


This is deprecated in CDI 3 (and removed in 4):

I did not report it since this is EE 10 work, which they don't claim
to support. However, it doesn't hurt to remove use of these deprecated
methods and I believe this would make CXF work with OWB 4 (although
not officially supported). I use this example to show how much this EE
9 is simply a piece of garbage, you get breakage, it's useless, but
then you get breakage again with EE 10.

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
idea ...

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

I doubt it would make any difference:
a) Tomcat 10.0 was frozen at 10.1.1 level exactly 18 months ago.
b) I suppose this is about CVEs.
c) So the process would be to fix them and then release only the Maven
artifacts. We cannot make a real release and advertise it with so many
bugfixes missing.
This would produce the same result with the same effort compared to
their custom "forked" branch (I don't consider it a fork since this is
simply a continuation from where the Tomcat branch stopped). I would
be reluctant to vote +1 to these releases unfortunately due to the
known issues.

Backporting everything from Tomcat 10.1 is a huge effort ...



Romain Manni-Bucau
@rmannibucau <> |  Blog
<> | Old Blog
<> | Github <> |
LinkedIn <> | Book

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

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

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

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

Reply via email to