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 > >>> 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 > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
