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