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 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.
-chris
Le mer. 27 mars 2024 à 14:20, Romain Manni-Bucau <rmannibu...@gmail.com> a
écrit :
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 27 mars 2024 à 14:15, Rémy Maucherat <r...@apache.org> a écrit :
On Wed, Mar 27, 2024 at 11:13 AM Romain Manni-Bucau
<rmannibu...@gmail.com> wrote:
Le mer. 27 mars 2024 à 10:58, Rémy Maucherat <r...@apache.org> a écrit
:
On Wed, Mar 27, 2024 at 9:49 AM Romain Manni-Bucau
<rmannibu...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
