Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

Proposed that as well, not yet sure since means there is no more cetifiable
version but let see.

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



Le ven. 29 mars 2024 à 16:51, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Romain,
>
> On 3/29/24 08:50, Romain Manni-Bucau wrote:
> > Le ven. 29 mars 2024 à 13:41, Christopher Schultz <
> > ch...@christopherschultz.net> a écrit :
> >
> >> Romain,
> >>
> >> 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
> >>> same.
> >>> 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.
> >>
> >
> > This is true but the proposal is more to comply to servlet5 U servlet 6
> > (union) API in tomcat objects.
> > If ServletRequestImpl (RequestFacade mainly) has the union of methods
> then
> > it can run with api 5 or 6 and still repect the compliance of both in the
> > same codebase.
> >
> > Indeed I'm only proposing it cause the diff is very low IMHO otherwise I
> > agree it would be a nightmare.
> >
> >
> >>
> >> 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.
> >>
> >
> > The fork part is the unhappy part, not because of the work but because:
> >
> > * It breaks security scans
> > * It breaks change tracking and needs adjustments (for tomcat you try to
> > limit the diff between branches but as soon the branch is outside the
> > project it will be more complicated and a change can break the downstream
> > project more easily)
> > * It requires yet another release cycle outside of the official project
> > * It confuses end users
> > * It makes it impossible for users to upgrade Tomcat without a release of
> > the fork - what is possible in embedded TomEE or other projects
> >
> > This is why I was looking for another compromise.
>
> Could another compromise be "TomEE ignores Servlet 5 and just goes
> directly to Servlet 6"? That seems to be what Rémy is recommending
> because he obviously has no affection for Servlet 5 :)
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Christopher Schultz]

Romain,

On 3/29/24 08:50, Romain Manni-Bucau wrote:

Le ven. 29 mars 2024 à 13:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Romain,

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

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



This is true but the proposal is more to comply to servlet5 U servlet 6
(union) API in tomcat objects.
If ServletRequestImpl (RequestFacade mainly) has the union of methods then
it can run with api 5 or 6 and still repect the compliance of both in the
same codebase.

Indeed I'm only proposing it cause the diff is very low IMHO otherwise I
agree it would be a nightmare.




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.



The fork part is the unhappy part, not because of the work but because:

* It breaks security scans
* It breaks change tracking and needs adjustments (for tomcat you try to
limit the diff between branches but as soon the branch is outside the
project it will be more complicated and a change can break the downstream
project more easily)
* It requires yet another release cycle outside of the official project
* It confuses end users
* It makes it impossible for users to upgrade Tomcat without a release of
the fork - what is possible in embedded TomEE or other projects

This is why I was looking for another compromise.


Could another compromise be "TomEE ignores Servlet 5 and just goes 
directly to Servlet 6"? That seems to be what Rémy is recommending 
because he obviously has no affection for Servlet 5 :)


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

Le ven. 29 mars 2024 à 13:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Romain,
>
> 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
> > same.
> > 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.
>

This is true but the proposal is more to comply to servlet5 U servlet 6
(union) API in tomcat objects.
If ServletRequestImpl (RequestFacade mainly) has the union of methods then
it can run with api 5 or 6 and still repect the compliance of both in the
same codebase.

Indeed I'm only proposing it cause the diff is very low IMHO otherwise I
agree it would be a nightmare.


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

The fork part is the unhappy part, not because of the work but because:

* It breaks security scans
* It breaks change tracking and needs adjustments (for tomcat you try to
limit the diff between branches but as soon the branch is outside the
project it will be more complicated and a change can break the downstream
project more easily)
* It requires yet another release cycle outside of the official project
* It confuses end users
* It makes it impossible for users to upgrade Tomcat without a release of
the fork - what is possible in embedded TomEE or other projects

This is why I was looking for another compromise.


>
> If your build process is strictly "download Tomcat binaries and use
> them" then of course it will be more complicated.
>
> -chris
>
> > Le jeu. 28 mars 2024 à 23:13, Christopher Schultz <
> > ch...@christopherschultz.net> a écrit :
> >
> >> Romain,
> >>
> >> 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.HttpSessionContext
> >>> - jakarta.servlet.http.HttpUtils Changed API:
> >>> jakarta.servlet.ServletContext Deleted methods: - public abstract
> >>> jakarta.servlet.Servlet
> >>> 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() -
> >> public
> >>> abstract void
> >>>
> jakarta.servlet.ServletContext.log(java.lang.Exception,java.lang.String)
> >>> jakarta.servlet.ServletRequest Added methods: - public abstract
> >>> jakarta.servlet.ServletConnection
> >>> 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.ServletRequest.getRealPath(java.lang.String)
> >>> jakarta.servlet.ServletRequestWrapper Added methods: - public
> >>> jakarta.servlet.ServletConnection
> >>> jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
> >>> java.lang.String
> >>> jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
> >>> java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
> >>> Deleted methods: - public java.lang.String
> >>> 

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Christopher Schultz]

Romain,

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


-chris


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


Romain,

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

- jakarta.servlet.http.HttpUtils Changed API:
jakarta.servlet.ServletContext Deleted methods: - public abstract
jakarta.servlet.Servlet
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() -

public

abstract void
jakarta.servlet.ServletContext.log(java.lang.Exception,java.lang.String)
jakarta.servlet.ServletRequest Added methods: - public abstract
jakarta.servlet.ServletConnection
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.ServletRequest.getRealPath(java.lang.String)
jakarta.servlet.ServletRequestWrapper Added methods: - public
jakarta.servlet.ServletConnection
jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
java.lang.String
jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
Deleted methods: - public java.lang.String
jakarta.servlet.ServletRequestWrapper.getRealPath(java.lang.String)
jakarta.servlet.SessionCookieConfig Added methods: - public abstract
java.lang.String
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String) -

public

abstract java.util.Map

jakarta.servlet.SessionCookieConfig.getAttributes()

- public abstract void


jakarta.servlet.SessionCookieConfig.setAttribute(java.lang.String,java.lang.String)

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.descriptor.JspPropertyGroupDescriptor.getErrorOnELNotFound()

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.Cookie.setAttribute(java.lang.String,java.lang.String)

jakarta.servlet.http.HttpServlet Added fields: - public static final
java.lang.String jakarta.servlet.http.HttpServlet.LEGACY_DO_HEAD Added
methods: - public void

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

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.

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

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

> Romain,
>
> 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.HttpSessionContext
> > - jakarta.servlet.http.HttpUtils Changed API:
> > jakarta.servlet.ServletContext Deleted methods: - public abstract
> > jakarta.servlet.Servlet
> > 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() -
> public
> > abstract void
> > jakarta.servlet.ServletContext.log(java.lang.Exception,java.lang.String)
> > jakarta.servlet.ServletRequest Added methods: - public abstract
> > jakarta.servlet.ServletConnection
> > 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.ServletRequest.getRealPath(java.lang.String)
> > jakarta.servlet.ServletRequestWrapper Added methods: - public
> > jakarta.servlet.ServletConnection
> > jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
> > java.lang.String
> > jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
> > java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
> > Deleted methods: - public java.lang.String
> > jakarta.servlet.ServletRequestWrapper.getRealPath(java.lang.String)
> > jakarta.servlet.SessionCookieConfig Added methods: - public abstract
> > java.lang.String
> > jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String) -
> public
> > abstract java.util.Map
> jakarta.servlet.SessionCookieConfig.getAttributes()
> > - public abstract void
> >
> jakarta.servlet.SessionCookieConfig.setAttribute(java.lang.String,java.lang.String)
> > 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.descriptor.JspPropertyGroupDescriptor.getErrorOnELNotFound()
> > 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.Cookie.setAttribute(java.lang.String,java.lang.String)
> > 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.http.HttpServlet.init(jakarta.servlet.ServletConfig)
> throws
> > jakarta.servlet.ServletException jakarta.servlet.http.HttpServletRequest
> > Deleted methods: - public abstract boolean
> > jakarta.servlet.http.HttpServletRequest.isRequestedSessionIdFromUrl()
> > jakarta.servlet.http.HttpServletRequestWrapper Deleted methods: - public
> > boolean
> >
> jakarta.servlet.http.HttpServletRequestWrapper.isRequestedSessionIdFromUrl()
> > jakarta.servlet.http.HttpServletResponse Deleted methods: - public
> abstract
> > java.lang.String
> >
> jakarta.servlet.http.HttpServletResponse.encodeRedirectUrl(java.lang.String)
> > - public abstract java.lang.String
> > jakarta.servlet.http.HttpServletResponse.encodeUrl(java.lang.String) -
> > public abstract void
> > jakarta.servlet.http.HttpServletResponse.setStatus(int,java.lang.String)
> > jakarta.servlet.http.HttpServletResponseWrapper Deleted methods: - public
> > java.lang.String
> >
> jakarta.servlet.http.HttpServletResponseWrapper.encodeRedirectUrl(java.lang.String)
> > - public java.lang.String
> >
> jakarta.servlet.http.HttpServletResponseWrapper.encodeUrl(java.lang.String)
> > - public void
> >
> 

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Christopher Schultz]

Romain,

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.HttpSessionContext
- jakarta.servlet.http.HttpUtils Changed API:
jakarta.servlet.ServletContext Deleted methods: - public abstract
jakarta.servlet.Servlet
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() - public
abstract void
jakarta.servlet.ServletContext.log(java.lang.Exception,java.lang.String)
jakarta.servlet.ServletRequest Added methods: - public abstract
jakarta.servlet.ServletConnection
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.ServletRequest.getRealPath(java.lang.String)
jakarta.servlet.ServletRequestWrapper Added methods: - public
jakarta.servlet.ServletConnection
jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
java.lang.String
jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
Deleted methods: - public java.lang.String
jakarta.servlet.ServletRequestWrapper.getRealPath(java.lang.String)
jakarta.servlet.SessionCookieConfig Added methods: - public abstract
java.lang.String
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String) - public
abstract java.util.Map jakarta.servlet.SessionCookieConfig.getAttributes()
- public abstract void
jakarta.servlet.SessionCookieConfig.setAttribute(java.lang.String,java.lang.String)
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.descriptor.JspPropertyGroupDescriptor.getErrorOnELNotFound()
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.Cookie.setAttribute(java.lang.String,java.lang.String)
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.http.HttpServlet.init(jakarta.servlet.ServletConfig) throws
jakarta.servlet.ServletException jakarta.servlet.http.HttpServletRequest
Deleted methods: - public abstract boolean
jakarta.servlet.http.HttpServletRequest.isRequestedSessionIdFromUrl()
jakarta.servlet.http.HttpServletRequestWrapper Deleted methods: - public
boolean
jakarta.servlet.http.HttpServletRequestWrapper.isRequestedSessionIdFromUrl()
jakarta.servlet.http.HttpServletResponse Deleted methods: - public abstract
java.lang.String
jakarta.servlet.http.HttpServletResponse.encodeRedirectUrl(java.lang.String)
- public abstract java.lang.String
jakarta.servlet.http.HttpServletResponse.encodeUrl(java.lang.String) -
public abstract void
jakarta.servlet.http.HttpServletResponse.setStatus(int,java.lang.String)
jakarta.servlet.http.HttpServletResponseWrapper Deleted methods: - public
java.lang.String
jakarta.servlet.http.HttpServletResponseWrapper.encodeRedirectUrl(java.lang.String)
- public java.lang.String
jakarta.servlet.http.HttpServletResponseWrapper.encodeUrl(java.lang.String)
- public void
jakarta.servlet.http.HttpServletResponseWrapper.setStatus(int,java.lang.String)
jakarta.servlet.http.HttpSession Deleted methods: - public abstract
jakarta.servlet.http.HttpSessionContext
jakarta.servlet.http.HttpSession.getSessionContext() - public abstract
java.lang.Object
jakarta.servlet.http.HttpSession.getValue(java.lang.String) - public
abstract java.lang.String[]
jakarta.servlet.http.HttpSession.getValueNames() - public abstract void
jakarta.servlet.http.HttpSession.putValue(java.lang.String,java.lang.Object)
- public abstract void
jakarta.servlet.http.HttpSession.removeValue(java.lang.String)

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 

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Christopher Schultz]

Romain,

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

Hi Chris,

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


Romain,

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

which

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

10.0

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

the

code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?


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

more

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?

https://tomcat.apache.org/tomcat-10.0-doc/servletapi/deprecated-list.html

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


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.

-chris

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

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.HttpSessionContext
- jakarta.servlet.http.HttpUtils Changed API:
jakarta.servlet.ServletContext Deleted methods: - public abstract
jakarta.servlet.Servlet
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() - public
abstract void
jakarta.servlet.ServletContext.log(java.lang.Exception,java.lang.String)
jakarta.servlet.ServletRequest Added methods: - public abstract
jakarta.servlet.ServletConnection
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.ServletRequest.getRealPath(java.lang.String)
jakarta.servlet.ServletRequestWrapper Added methods: - public
jakarta.servlet.ServletConnection
jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
java.lang.String
jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
Deleted methods: - public java.lang.String
jakarta.servlet.ServletRequestWrapper.getRealPath(java.lang.String)
jakarta.servlet.SessionCookieConfig Added methods: - public abstract
java.lang.String
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String) - public
abstract java.util.Map jakarta.servlet.SessionCookieConfig.getAttributes()
- public abstract void
jakarta.servlet.SessionCookieConfig.setAttribute(java.lang.String,java.lang.String)
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.descriptor.JspPropertyGroupDescriptor.getErrorOnELNotFound()
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.Cookie.setAttribute(java.lang.String,java.lang.String)
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.http.HttpServlet.init(jakarta.servlet.ServletConfig) throws
jakarta.servlet.ServletException jakarta.servlet.http.HttpServletRequest
Deleted methods: - public abstract boolean
jakarta.servlet.http.HttpServletRequest.isRequestedSessionIdFromUrl()
jakarta.servlet.http.HttpServletRequestWrapper Deleted methods: - public
boolean
jakarta.servlet.http.HttpServletRequestWrapper.isRequestedSessionIdFromUrl()
jakarta.servlet.http.HttpServletResponse Deleted methods: - public abstract
java.lang.String
jakarta.servlet.http.HttpServletResponse.encodeRedirectUrl(java.lang.String)
- public abstract java.lang.String
jakarta.servlet.http.HttpServletResponse.encodeUrl(java.lang.String) -
public abstract void
jakarta.servlet.http.HttpServletResponse.setStatus(int,java.lang.String)
jakarta.servlet.http.HttpServletResponseWrapper Deleted methods: - public
java.lang.String
jakarta.servlet.http.HttpServletResponseWrapper.encodeRedirectUrl(java.lang.String)
- public java.lang.String
jakarta.servlet.http.HttpServletResponseWrapper.encodeUrl(java.lang.String)
- public void
jakarta.servlet.http.HttpServletResponseWrapper.setStatus(int,java.lang.String)
jakarta.servlet.http.HttpSession Deleted methods: - public abstract
jakarta.servlet.http.HttpSessionContext
jakarta.servlet.http.HttpSession.getSessionContext() - public abstract
java.lang.Object
jakarta.servlet.http.HttpSession.getValue(java.lang.String) - public
abstract java.lang.String[]
jakarta.servlet.http.HttpSession.getValueNames() - public abstract void
jakarta.servlet.http.HttpSession.putValue(java.lang.String,java.lang.Object)
- public abstract void
jakarta.servlet.http.HttpSession.removeValue(java.lang.String)

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?).

Romain Manni-Bucau

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

Ok, let see if we can maybe have an exceptional certification status with
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 é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
> > > which
> > > > 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
> > > 10.0
> > > > 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
> > > the
> > > > code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
> > > > Servlet 6 - to pass signature TCK.
> > > >
> > > > Wdyt?
> > >
> > > 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 more
> > 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.
>
> 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
> jakarta.enterprise.inject.spi.BeanManager.fireEvent(java.lang.Object,
> java.lang.annotation.Annotation[])'
> at
> org.apache.cxf.cdi.JAXRSCdiResourceExtension.onStartup(JAXRSCdiResourceExtension.java:167)
>
> This is deprecated in CDI 3 (and removed in 4):
>
> https://jakarta.ee/specifications/cdi/3.0/apidocs/jakarta/enterprise/inject/spi/beanmanager#fireEvent-java.lang.Object-java.lang.annotation.Annotation...-
>
> 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 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?
>
> 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 ...
>
> Rémy
>
> > >
> > > Rémy
> > >
> > > > Best,
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn 

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Rémy Maucherat]

On Wed, Mar 27, 2024 at 11:13 AM 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
> > which
> > > 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
> > 10.0
> > > 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
> > the
> > > code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
> > > Servlet 6 - to pass signature TCK.
> > >
> > > Wdyt?
> >
> > 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 more
> 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.

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
jakarta.enterprise.inject.spi.BeanManager.fireEvent(java.lang.Object,
java.lang.annotation.Annotation[])'
at 
org.apache.cxf.cdi.JAXRSCdiResourceExtension.onStartup(JAXRSCdiResourceExtension.java:167)

This is deprecated in CDI 3 (and removed in 4):
https://jakarta.ee/specifications/cdi/3.0/apidocs/jakarta/enterprise/inject/spi/beanmanager#fireEvent-java.lang.Object-java.lang.annotation.Annotation...-

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 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?

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

Rémy

> >
> > Rémy
> >
> > > Best,
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

Hi Chris,

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

> Romain,
>
> 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
> >> which
> >>> 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
> >> 10.0
> >>> 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
> >> the
> >>> code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
> >>> Servlet 6 - to pass signature TCK.
> >>>
> >>> Wdyt?
> >>
> >> 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
> more
> > 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?
>
> https://tomcat.apache.org/tomcat-10.0-doc/servletapi/deprecated-list.html
>
> 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
standpoint.


>
> 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
;)).


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


>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Christopher Schultz]

Romain,

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

which

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

10.0

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

the

code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?


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 more
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?

https://tomcat.apache.org/tomcat-10.0-doc/servletapi/deprecated-list.html

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


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.


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.


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

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
> which
> > 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
> 10.0
> > 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
> the
> > code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
> > Servlet 6 - to pass signature TCK.
> >
> > Wdyt?
>
> 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 more
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?


>
> Rémy
>
> > Best,
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Rémy Maucherat]

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 which
> 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 10.0
> 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 the
> code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
> Servlet 6 - to pass signature TCK.
>
> Wdyt?

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.

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

Rémy

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

Hi Mark,

I'm aware of these discussions but it let Tomcat in the state where Servlet
5.0 is not supported - but Servlet 4.0 is which is ultra weird but don't
get me wrong I'm for keeping it for a  moment.
Concretely it prevents downstream consumers to be certified so

> No interest in supporting 10.0.x

is likely wrong from a community standpoint and at least TomEE would be
interested in dropping its fork of Tomcat 10 for that reason.

Any way we get back a 10.0 or a 10.1 runnable with Servlet 5.0 API (guess
it would be better for everyone)?

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



Le mer. 27 mars 2024 à 10:45, Mark Thomas  a écrit :

> On 27/03/2024 08:48, 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
> which
> > 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
> 10.0
> > 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
> the
> > code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
> > Servlet 6 - to pass signature TCK.
> >
> > Wdyt?
>
> -1 to stopping Tomcat 9.0.x support.
>
> No interest in supporting 10.0.x
>
> This has been discussed at length previously. Those discussions can be
> found in the archives.
>
> The short version is:
> - Tomcat 9.x (Java EE8) will be maintained for the foreseeable future at
>it is the last branch to support Java EE.
> - Jakarta EE 9 (Tomcat 10.0) was a transition release that we only ever
>intended to maintain for as long as it took for Jakarta EE 10 (Tomcat
>10.1) to reach stability
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Mark Thomas]

On 27/03/2024 08:48, 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 which
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 10.0
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 the
code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?


-1 to stopping Tomcat 9.0.x support.

No interest in supporting 10.0.x

This has been discussed at length previously. Those discussions can be 
found in the archives.


The short version is:
- Tomcat 9.x (Java EE8) will be maintained for the foreseeable future at
  it is the last branch to support Java EE.
- Jakarta EE 9 (Tomcat 10.0) was a transition release that we only ever
  intended to maintain for as long as it took for Jakarta EE 10 (Tomcat
  10.1) to reach stability

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Romain Manni-Bucau]

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 which
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 10.0
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 the
code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?

Best,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book