Re: BND 7 and multi release JARs
My 2 cts would be to split anyway even if bnd can handle it: * mjar can imply some classloading overhead (java.util.jar.JarFile#getEntry) and keep the issue to have in a j17 jar > 17 bytecode (scanner not multirelease friendly will likely fail even if tomcat shouldnt be scanned it stays scanned quite often) * preview features are not that welcomed in default bundle IMHO - mainly embed case 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 mar. 11 juin 2024 à 16:16, Rémy Maucherat a écrit : > Hi, > > To fix the issue with having Java 22 classes in tomcat-coyote (and > embedded), I was looking at multi release JARs. I think it would work > fine *if* we were building the JARs ourselves (jarIt task), but then > the jars are actually rebuilt with bnd. > > Supposedly bnd 7.0.0 (which we just upgraded to) supports multi > release jars. After looking at their testsuite, it seems adding > "Multi-release: true" to the bnd and having the classes in the right > spot (META-INF/versions/22) would be enough [see: > https://github.com/bndtools/bnd/pull/5581/files ]. Unfortunately, this > keeps doing nothing for me. If anyone can get it to work, let me know. > > Anyway, instead of doing something too complex, I would instead be > back to producing a small tomcat-coyote-ffm jar. Then embedded users > can still use that small jar, even though it's a bit annoying to not > have it included in the big embed jar ... The naming of the jar will > be "stable" since even if adding quic/h3 to it somehow, the jar name > remains appropriate. > > Obviously all the mess comes from the combination of these two items: > - FFM missing the Java 21 cruise ship > - EE 11 downgrading to Java 17 > > :( > > So is it ok if I add a new tomcat-coyote-ffm.jar in lib ? > > Rémy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Extracting Panama code from coyote?
Hi all, Wonder if it would be an option to drop classes using panama from default tomcat jars (coyote), it breaks some consumers since bytecode has a higher level than tomcat targetted one plus it makes graalvm integration not as smooth as before so think it is worth extracting these early features in their own jar, even if they are enabled by reflection or something a bit more indirect. Wdyt? Immediate issue with graal native-image for example is org.apache.tomcat.util.net.openssl.panama.OpenSSLContext which relies on Arena and friends which are not in java 17 for ex. 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>
Re: [VOTE] Release Apache Tomcat 10.1.24
Thanks Mark. +1 then, tested on several embed servers which use the standard artifacts (Yupiik Fusion, Apache Meecrowave apps, ...). 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 ven. 10 mai 2024 à 12:26, Mark Thomas a écrit : > On 10/05/2024 11:22, Romain Manni-Bucau wrote: > > Hi Christopher, > > > > Is it possible to close the staging repo please (I get a 404)? > > There is a typo in the VOTE email. The correct staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1495 > > Mark > > > > > > 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 > > > > > > > > Le ven. 10 mai 2024 à 10:00, Mark Thomas a écrit : > > > >> On 09/05/2024 19:12, Christopher Schultz wrote: > >> > >>> The proposed 10.1.24 release is: > >>> [ ] Broken - do not release > >>> [X] Stable - go ahead and release as 10.1.24 > >> > >> Tests pass on Linux, Windows, MacOS (Intel) and MacOS (M1). > >> > >> Build is cross platform reproducible (Linux / Windows). > >> > >> Mark > >> > >> - > >> 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: [VOTE] Release Apache Tomcat 10.1.24
Hi Christopher, Is it possible to close the staging repo please (I get a 404)? 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> Le ven. 10 mai 2024 à 10:00, Mark Thomas a écrit : > On 09/05/2024 19:12, Christopher Schultz wrote: > > > The proposed 10.1.24 release is: > > [ ] Broken - do not release > > [X] Stable - go ahead and release as 10.1.24 > > Tests pass on Linux, Windows, MacOS (Intel) and MacOS (M1). > > Build is cross platform reproducible (Linux / Windows). > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 10.1.22
+1 (non binding), mainly tested downstream tomcat embedded cases (but using plain artifacts not embed ones). 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 jeu. 11 avr. 2024 à 19:21, Rainer Jung a écrit : > Am 10.04.24 um 20:51 schrieb Christopher Schultz: > > The proposed Apache Tomcat 10.1.22 release is now available for > > voting. Apache Tomcat 10.1.21 was canceled due to a release-build > > mistake. There are no source-level changes between 10.1.21 and 10.1.22. > > > > The notable changes compared to 10.1.20 are: > > > > - Add OpenSSL support when FFM is available > > > > - Improve locking strategies in Catalina core > > > > - Updates to Apache Commons dependencies > > > > For full details, see the change log: > > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > > without changes. Java EE applications designed for Tomcat 9 and earlier > > may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat > > will automatically convert them to Jakarta EE and copy them to the > > webapps directory. > > > > It can be obtained from: > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.22/ > > > > The Maven staging repo is: > > https://repository.apache.org/content/repositories/orgapachetomcat-1491 > > > > The tag is: > > https://github.com/apache/tomcat/tree/10.1.22 > > fd9c0bb1f0a7e586daabfda625ef50827bcfddf3 > > > > Please reply with a +1 for release or -0/-1 with an explanation. > > > > The proposed 10.1.22 release is: > > [X] Broken - do not release > > [ ] Stable - go ahead and release as 10.1.22 > > Unfortunately it seems broken. > > Commit 6550e203a8119683f38c182cbfbb9b56587c54a0 introduced the use of > --enable-native-access to the catalina script, which I think breaks 10.1 > on Java 11, since the flag was introduced later. > > Best regards, > > Rainer > > - > 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?
Proposed that as well, not yet sure since means there is no more cetifiable version but let see. 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 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?
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.Servl
Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?
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.
Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?
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?).
Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?
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 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 i
Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?
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?
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 <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 > >
Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?
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 <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 à 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 > >
Stop releasing Tomcat 9 or adding back Tomcat 10.0?
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 <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>
Re: Observability of virtual threads
Chris, added some comments inline. Le mer. 20 mars 2024 à 19:41, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Romain, > > On 3/20/24 13:34, Romain Manni-Bucau wrote: > > Thread dumps being dump of threads - literally os threads - and virtual > > threads not being threads at all - they are runnables in a dedicated > thread > > pool - it is quite fair to not make them the same and have their > scheduler > > - pool - only in the thread dump but not themselves no? > > Maybe. > > If you take a thread dump today (with a "real" thread), you only get a > Java stack trace, you get no "native stack trace" or anything like that. > So from that perspective, the "thread" is really the instance of > java.lang.Thread which could just as easily be a Virtual Thread. > > You also get no scheduling information, other than what the thread's > "priority" is... but you can't get any real-time data about where it > sits in the scheduling queue, etc. > Well, this does not work like that, as mentionned it is a ForkJoinPool so not a plain queue - except the design which is not a 1 task = 1 position, it has multiple queues - so the position in "the queue" does not give you the information you are mentionned there. If you really care about monitoring this pool you can just instrument java.lang.VirtualThread#DEFAULT_SCHEDULER (plain reflection works good enough if you open this part but agents too). > > I'm much less interested in what the "native thread" is doing _below_ > the Java part. Presumably, it's always running > Thread.cpp::runTheJavaCode and that's not useful information to anybody. > Depends how you instrument/query it, while at code level it does not change much things and you still get the thread stack context. For raw thread dumps you indeed need the new jcmd command (Thread.dump_to_file) and I agree there is no real point to not let it go in the plain jstack with a new toggle you can enable at need (but hopefully not by default since we'll end up with undownloadable/too big dumps). Ultimately using reflection and opening jdk.internal.vm package you can also just use ThreadContainers.root() and iterate over children()/threads() but not sure how portable it will be. There is a negative effect there, before we were often decorating executors (the Runnable to execute) to add before/after context and potentially track threads there but it does not work anymore since threads are totally unbounded. > > If the Virtual Thread is not mounted on an OS thread, then it's > "suspended" or "blocked" or whatever-it-is. If it's on an OS thread, it > had better be running: that's the whole point of the scheme. (I suppose > it could be BLOCKED-yet-on-an-OS-thread -- one of the current problems > which hopefully will be less of a problem in the future, but I'd like to > ignore that for now). > > I don't know what's wrong with having millions of threads, and still > being able to walk through them using existing APIs. Nobody walks > through threads for no good reason... if you want to see the threads, > you should be able to see the threads. > > If I wanted to walk-through every instance of java.lang.String in a JVM > (¡millions of them!), then I should be able to do it even if (a) it's a > weird thing to do and (b) it will take a while. Well, I want to do it, > so let me do it(!). > > If you have only one "real" Thread (e.g. the main thread) and everything > else is Virtual... when you ask for a thread dump or walk all the > threads, do you only see "main" and not the mounted-on-OS-threads > Virtual Threads? If the JVM were willing to consider Virtual Threads > "visible" and therefore dumpable, etc. through existing interfaces > _while they were mounted on an OS thread_ I could almost agree that > makes some sense. But if I have a unit of work not making any progress, > I'm gonna want to be able to see that (Virtual) Thread in a thread dump > or any other kind of analysis tool, including its stack trace. > > > Similarly to why threadlocal are not recommended for virtual thread this > > would probably make an useless pressure on the JVM IMHO - why there is an > > option to see it but it is mainly for debug purposes. > > See virtual threads as continuations (suspendable/resumable "Runnable") > in > > a dedicated and not programmatically configurable nor > selectable/proviable > > thread pool, they are not in thread dumps and this doesnt bother you ;) - > > ultimately if you want it you want all java objects to be monitored and > in > > the thread dump which would be weird - but I agree
Re: Observability of virtual threads
Le mer. 20 mars 2024 à 18:43, Rainer Jung a écrit : > Am 20.03.24 um 18:34 schrieb Romain Manni-Bucau: > > Hi Chris, > > > > Thread dumps being dump of threads - literally os threads - and virtual > > threads not being threads at all - they are runnables in a dedicated > thread > > pool - it is quite fair to not make them the same and have their > scheduler > > - pool - only in the thread dump but not themselves no? > > Similarly to why threadlocal are not recommended for virtual thread this > > would probably make an useless pressure on the JVM IMHO - why there is an > > option to see it but it is mainly for debug purposes. > > See virtual threads as continuations (suspendable/resumable "Runnable") > in > > a dedicated and not programmatically configurable nor > selectable/proviable > > thread pool, they are not in thread dumps and this doesnt bother you ;) - > > ultimately if you want it you want all java objects to be monitored and > in > > the thread dump which would be weird - but I agree the semantic is > > misleading. > > Nevertheless it would be helpful to knw, which virtual threads currently > have an associated OS thread or not, and for those having one, what > their stack is. And this not just as a dump into a file, but instead > available via a proper API. It might be worth to ask the JDK devs about > chanced to get such an API. > Hmm, I must miss something but virtual threads with an associated os thread are in the thread dump since they run code (execution is in a normal forkjoinpool). So if you lock - synchronized/mutex for ex issue - then you see it as before. That said for that they added a pinned system prop enabling to validate your app is VT friendly or not which is very helpful. > > From my tests virtual threads do their job but they stay slower than a > > proper reactive/async impl mainly due to the overhead they add > *everywhere* > > compare to reactive programming plus this single thread pool issue which > > adds a lot of contention when all the app/lot of tasks is/are done using > it > > - vs bulkhead pattern for ex. > > But if you come from a plain sync application it can be very interesting > if > > it stays compatible and you don't need to add throttling to control the > > memory - often in the old style you throttle with the number of threads, > > now you need a semaphore or alike. > > Will not be a free lunch ;). > > > > 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. 20 mars 2024 à 18:20, Christopher Schultz < > > ch...@christopherschultz.net> a écrit : > > > >> Rainer, > >> > >> Thanks for writing this up. > >> > >> On 3/20/24 07:22, Rainer Jung wrote: > >>> I wanted to share an observation and I hope the things are correct how > I > >>> am describing them. Maybe things have already improved and I am not > >>> aware of it, hints welcome. > >>> > >>> Part of JEP 425 (Project Loom, Java virtual threads) discusses how to > >>> handle observability of virtual threads from inside the JVM and > tooling. > >>> > >>> The final outcome is, that virtual threads are not included in the > >>> typical JVM APIs which one can use to observe threads, like enumerating > >>> them or accessing the stacks of individual threads. As a consequence, > >>> also jstack and "kill -QUIT" do not show virtual threads at all, not > >>> even when they are attached to a native thread and executing code. > >> > >> O_O > >> > >>> There is one single method to help with observability of virtual > threads > >>> > >>> > >> > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.management/com/sun/management/HotSpotDiagnosticMXBean.html#dumpThreads(java.lang.String,com.sun.management.HotSpotDiagnosticMXBean.ThreadDumpFormat) > >>> > >>> which dumps a full thread dump to a file. Of course that is by no means > >>> appropriate, if you want to do a fine grained observation. At least you > >>> can choose to write a json structure instead of a hard to parse text > >>> format, but that's it. > &g
Re: Observability of virtual threads
Hi Chris, Thread dumps being dump of threads - literally os threads - and virtual threads not being threads at all - they are runnables in a dedicated thread pool - it is quite fair to not make them the same and have their scheduler - pool - only in the thread dump but not themselves no? Similarly to why threadlocal are not recommended for virtual thread this would probably make an useless pressure on the JVM IMHO - why there is an option to see it but it is mainly for debug purposes. See virtual threads as continuations (suspendable/resumable "Runnable") in a dedicated and not programmatically configurable nor selectable/proviable thread pool, they are not in thread dumps and this doesnt bother you ;) - ultimately if you want it you want all java objects to be monitored and in the thread dump which would be weird - but I agree the semantic is misleading. >From my tests virtual threads do their job but they stay slower than a proper reactive/async impl mainly due to the overhead they add *everywhere* compare to reactive programming plus this single thread pool issue which adds a lot of contention when all the app/lot of tasks is/are done using it - vs bulkhead pattern for ex. But if you come from a plain sync application it can be very interesting if it stays compatible and you don't need to add throttling to control the memory - often in the old style you throttle with the number of threads, now you need a semaphore or alike. Will not be a free lunch ;). 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. 20 mars 2024 à 18:20, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Rainer, > > Thanks for writing this up. > > On 3/20/24 07:22, Rainer Jung wrote: > > I wanted to share an observation and I hope the things are correct how I > > am describing them. Maybe things have already improved and I am not > > aware of it, hints welcome. > > > > Part of JEP 425 (Project Loom, Java virtual threads) discusses how to > > handle observability of virtual threads from inside the JVM and tooling. > > > > The final outcome is, that virtual threads are not included in the > > typical JVM APIs which one can use to observe threads, like enumerating > > them or accessing the stacks of individual threads. As a consequence, > > also jstack and "kill -QUIT" do not show virtual threads at all, not > > even when they are attached to a native thread and executing code. > > O_O > > > There is one single method to help with observability of virtual threads > > > > > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.management/com/sun/management/HotSpotDiagnosticMXBean.html#dumpThreads(java.lang.String,com.sun.management.HotSpotDiagnosticMXBean.ThreadDumpFormat) > > > > which dumps a full thread dump to a file. Of course that is by no means > > appropriate, if you want to do a fine grained observation. At least you > > can choose to write a json structure instead of a hard to parse text > > format, but that's it. > > Boy, that's a real miss from the JVM team. I'm surprised that they have > overlooked this. I don't see a real reason that a Virtual Thread would > be treated any differently than a regular thread. > > > For instance I am often using a tool, that inspects our > > RequestProcessors to find long running requests and then retrieves the > > list of Java threads as ThreadInfo objects to find the one executing the > > request and finally retrieves the stack of that request from the JVM. > > Such an approach is no longer possible. Almost all of JMX does not show > > any info about virtual threads. > > > > It also seems Tomcat no longer uses a pool when a connector is > > configured to use virtual threads. So there are no metrics like > > currentThreadCount or currentThreadsBusy. > > When using virtual threads, the number of requests is the same as the > number of threads, since each request -> new Virtual Thread though I > think the request-count is only incremented when the request has > completed, so maybe there are threads running that can't be counted (yet). > > But I understand that you were hoping to get some information about > these threads and though maybe Tomcat's metrics could help. I guess not > really. > > But thread-busy count is the same as in-flight-request count. And > current thread count is the same as in-flight-request count as well.
Re: Observability of virtual threads
Hi Rainer, Think this is not related to virtual threads I think and way older (2010?). Since some years we use AsyncContext and therefore thread dumps don't match pending requests but just active computation (you can get 8K requests with 8 threads for ex). Most of the sync instrumentation (assumptions) are broken since Servlet 3.0 and must not be used to conclude anything but generally other metrics and data enable to monitor the server properly (request counter for example is decoralated from threads, active connections for database - generic term - etc). Thread stacks stay useful for performance related work but not for hanging investigation (for good since it enables a better scalability in general) so guess it is mainly a habit switch in terms of tools, no? Hope it makes sense. 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. 20 mars 2024 à 13:11, Rainer Jung a écrit : > Hi hi, > > I wanted to share an observation and I hope the things are correct how I > am describing them. Maybe things have already improved and I am not > aware of it, hints welcome. > > Part of JEP 425 (Project Loom, Java virtual threads) discusses how to > handle observability of virtual threads from inside the JVM and tooling. > > The final outcome is, that virtual threads are not included in the > typical JVM APIs which one can use to observe threads, like enumerating > them or accessing the stacks of individual threads. As a consequence, > also jstack and "kill -QUIT" do not show virtual threads at all, not > even when they are attached to a native thread and executing code. > > There is one single method to help with observability of virtual threads > > > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.management/com/sun/management/HotSpotDiagnosticMXBean.html#dumpThreads(java.lang.String,com.sun.management.HotSpotDiagnosticMXBean.ThreadDumpFormat) > > which dumps a full thread dump to a file. Of course that is by no means > appropriate, if you want to do a fine grained observation. At least you > can choose to write a json structure instead of a hard to parse text > format, but that's it. > > For instance I am often using a tool, that inspects our > RequestProcessors to find long running requests and then retrieves the > list of Java threads as ThreadInfo objects to find the one executing the > request and finally retrieves the stack of that request from the JVM. > Such an approach is no longer possible. Almost all of JMX does not show > any info about virtual threads. > > It also seems Tomcat no longer uses a pool when a connector is > configured to use virtual threads. So there are no metrics like > currentThreadCount or currentThreadsBusy. > > I guess this also limits the use of some manager features and probably > also the StuckThreadsDetectionValve when combined with virtual threads. > > Of course Tomcat has solved most of the problems, that virtual threads > want to solve, by doing the hard work of using the NIO and NIO2 APIs. So > virtual threads are probably not that important for us. But we should be > aware of the observability deficiencies whenever we would discuss > whether we could switch from NIO or NIO2 to virtual threads to simplify > connector code in some distant future. > > Best regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 10.1.20
+1 (non-binding), tested on several apps with "AsfEE" stack and Yupiik Fusion, no issue so far. 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 mar. 19 mars 2024 à 16:55, Rémy Maucherat a écrit : > On Tue, Mar 19, 2024 at 2:56 PM Christopher Schultz > wrote: > > > > The proposed Apache Tomcat 10.1.20 release is now available for > > voting. > > > > The notable changes compared to 10.1.19 are: > > > > - Fix regression when reloading TLS configuration and files. > > > > - When restoring a saved POST request after a successful FORM > >authentication, ensure that neither the URI, the query string no > >the protocol are corrupted when restoring the request body. > > > > - Align error handling for Writer and OutputStream. Ensure use of either > >once the response has been recycled triggers a NullPointerException > >provided that discardFacades is configured with the default value of > >true. > > > > For full details, see the change log: > > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > > without changes. Java EE applications designed for Tomcat 9 and earlier > > may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat > > will automatically convert them to Jakarta EE and copy them to the > > webapps directory. > > > > It can be obtained from: > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.20/ > > > > The Maven staging repo is: > > https://repository.apache.org/content/repositories/orgapachetomcat-1486 > > > > The tag is: > > https://github.com/apache/tomcat/tree/10.1.20 > > ab4d890c6fa7be3f910370f00fb5c7f10152e21c > > > > The proposed 10.1.20 release is: > > [ ] Broken - do not release > > [X] Stable - go ahead and release as 10.1.20 > > Rémy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: FFM in Tomcat 10.1
Le lun. 26 févr. 2024 à 13:16, Rémy Maucherat a écrit : > On Fri, Feb 23, 2024 at 4:39 PM Romain Manni-Bucau > wrote: > > > > Hi all, > > > > Sounds very good overall but would be great to not do it at the cost to > > break tomcat IDE support maybe - current status since it uses a single > > module and not all IDE support to compile supackages with different > target > > versions? > > Overall stays an Apache project where we should ensure we make > > contributions easy ;). > > > > Indeed just my 2cts feedback. > > This is possible in this particular case (all the Java 22 code is in > separate packages, the testsuite can accommodate that it is missing > and has no specific tests). > However, I have a hard time believing it would actually help as a > Tomcat developer. I often don't bother adding Ant so the ide complains > about catalina.ant packages, and I happily ignore it. Also it is not > bad if new developers are aware of FFM. > Agree it can be good if they know it but my point was it is always bad to not enable people to open a project in their preferred IDE - current state. At least eclipse/vscode, idea IMHO. Module is easier to workaround than packages where it is almost impossible in some IDE. > > > Rémy > > > 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 ven. 23 févr. 2024 à 16:08, Mark Thomas a écrit : > > > > > On 23/02/2024 13:35, Rémy Maucherat wrote: > > > > Hi, > > > > > > > > I would like to propose backporting the OpenSSL FFM support to Tomcat > > > 10.1. > > > > > > > > Java 22.0.0 should be released on March 19, and the next Java LTS > > > > should still have no problem targeting Java 11. As a result, there > > > > should be no negative impact to the platform support, and users > > > > running on Java 22+ could benefit from easier OpenSSL support. > > > > > > > > Obviously I anticipate most users will use FFM support once the next > > > > Java LTS is out in a few years, but getting the feature out now would > > > > still be good. > > > > > > > > After the change: > > > > - Compiling, running the testsuite, etc is still doable with Java 17. > > > > - Running Tomcat 10.1 still works with Java 11. > > > > - Building a Tomcat 10.1 release would now require Java 22+. > > > > > > > > Backporting further to Tomcat 9.0 could be riskier however. Following > > > > the removal of the Java 7 release target, Java 8 might be next. The > > > > main question is if the next Java LTS will still support the Java 8 > > > > release target. > > > > > > > > Comments ? > > > > > > LGTM. > > > > > > Mark > > > > > > - > > > 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: FFM in Tomcat 10.1
Hi all, Sounds very good overall but would be great to not do it at the cost to break tomcat IDE support maybe - current status since it uses a single module and not all IDE support to compile supackages with different target versions? Overall stays an Apache project where we should ensure we make contributions easy ;). Indeed just my 2cts feedback. 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 ven. 23 févr. 2024 à 16:08, Mark Thomas a écrit : > On 23/02/2024 13:35, Rémy Maucherat wrote: > > Hi, > > > > I would like to propose backporting the OpenSSL FFM support to Tomcat > 10.1. > > > > Java 22.0.0 should be released on March 19, and the next Java LTS > > should still have no problem targeting Java 11. As a result, there > > should be no negative impact to the platform support, and users > > running on Java 22+ could benefit from easier OpenSSL support. > > > > Obviously I anticipate most users will use FFM support once the next > > Java LTS is out in a few years, but getting the feature out now would > > still be good. > > > > After the change: > > - Compiling, running the testsuite, etc is still doable with Java 17. > > - Running Tomcat 10.1 still works with Java 11. > > - Building a Tomcat 10.1 release would now require Java 22+. > > > > Backporting further to Tomcat 9.0 could be riskier however. Following > > the removal of the Java 7 release target, Java 8 might be next. The > > main question is if the next Java LTS will still support the Java 8 > > release target. > > > > Comments ? > > LGTM. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [bug] websocket generics?
For the IDE issue, how do you setup the build in eclipse, didnt java
version reference in eclipse files?
using java 21 + --enable-preview fails due to allocateFrom() usage (java
22) but using java 22 EA fails cause both setups are not compatible it
seems.
Alternatively, moving panama integration to another module until it is
final wouldnt be bad IMHO, in particular while no LTS supports the required
code and it still moves, no?
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 lun. 22 janv. 2024 à 20:58, Mark Thomas a écrit :
>
>
> On 22/01/2024 15:04, Romain Manni-Bucau wrote:
> > Hi Mark,
> >
> > Checked deeper the sample and seems it is the old lambda issue, so indeed
> > we can avoid the NPE and fallback on Object but since it was not done I'm
> > not sure it would be helpful compared to current code.
> > Here is the test:
> >
> > @Test
> > public void testLambda() {
> > final MessageHandler.Whole handler = message -> {
> > };
> > Assert.assertEquals(Object.class, Util.getMessageType(handler));
> > }
> >
> > So guess we can play the status-quo.
>
> To save others doing the search:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=65458
>
> +1 to leaving things as they are.
>
> > Side note: seems ide-intellij ant task got broken with java 22 API usage
> of
> > the source.
>
> Possibly. I'm an Eclipse user so we'll need an IntelliJ user to take a
> look at that.
>
> Mark
>
>
> >
> > 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 lun. 22 janv. 2024 à 12:53, Mark Thomas a écrit :
> >
> >> On 21/01/2024 18:33, Romain Manni-Bucau wrote:
> >>> Hi,
> >>>
> >>> I know websocket 1.0 methods without providing the handler type are
> kind
> >> of
> >>> deprecated (not recommended would be more correct) so not sure this bug
> >>> would get a fix or not.
> >>> Long story
> >>> short,
> >>
> org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler)
> >>> will call Util.getMessageType which goes into the reflection code and
> the
> >>> interesting part is org.apache.tomcat.websocket.Util#getGenericType and
> >>> more precisely TypeResult superClassTypeResult = getGenericType(type,
> >>> superClazz); which can return null (end of recursion) but next line
> >> being int
> >>> dimension = superClassTypeResult.getDimension(); we can get a NPE.
> >>>
> >>> The fix is trivial but I'mnot sure it is worth it or just redirecting
> to
> >>> the right API would be better.
> >>
> >> It depends whether this is one of the cases we can actually handle
> >> correctly or if it is one where you have to use the new API.
> >>
> >> If we can handle it correctly, we should. If not, I'm fine with throwing
> >> an although it looks like the error handling might need a small tweak in
> >> that case.
> >>
> >> Can you provide a concrete example that currently fails?
> >>
> >> Mark
> >>
> >> -
> >> 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: [bug] websocket generics?
Hi Mark,
Checked deeper the sample and seems it is the old lambda issue, so indeed
we can avoid the NPE and fallback on Object but since it was not done I'm
not sure it would be helpful compared to current code.
Here is the test:
@Test
public void testLambda() {
final MessageHandler.Whole handler = message -> {
};
Assert.assertEquals(Object.class, Util.getMessageType(handler));
}
So guess we can play the status-quo.
Side note: seems ide-intellij ant task got broken with java 22 API usage of
the source.
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 lun. 22 janv. 2024 à 12:53, Mark Thomas a écrit :
> On 21/01/2024 18:33, Romain Manni-Bucau wrote:
> > Hi,
> >
> > I know websocket 1.0 methods without providing the handler type are kind
> of
> > deprecated (not recommended would be more correct) so not sure this bug
> > would get a fix or not.
> > Long story
> > short,
> org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler)
> > will call Util.getMessageType which goes into the reflection code and the
> > interesting part is org.apache.tomcat.websocket.Util#getGenericType and
> > more precisely TypeResult superClassTypeResult = getGenericType(type,
> > superClazz); which can return null (end of recursion) but next line
> being int
> > dimension = superClassTypeResult.getDimension(); we can get a NPE.
> >
> > The fix is trivial but I'mnot sure it is worth it or just redirecting to
> > the right API would be better.
>
> It depends whether this is one of the cases we can actually handle
> correctly or if it is one where you have to use the new API.
>
> If we can handle it correctly, we should. If not, I'm fine with throwing
> an although it looks like the error handling might need a small tweak in
> that case.
>
> Can you provide a concrete example that currently fails?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
[bug] websocket generics?
Hi, I know websocket 1.0 methods without providing the handler type are kind of deprecated (not recommended would be more correct) so not sure this bug would get a fix or not. Long story short, org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler) will call Util.getMessageType which goes into the reflection code and the interesting part is org.apache.tomcat.websocket.Util#getGenericType and more precisely TypeResult superClassTypeResult = getGenericType(type, superClazz); which can return null (end of recursion) but next line being int dimension = superClassTypeResult.getDimension(); we can get a NPE. The fix is trivial but I'mnot sure it is worth it or just redirecting to the right API would be better. Side note: for the context i'm using records instead of pojo, not very important since I guess interfaces would lead to the same issues but makes it more concrete. 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>
Re: Supposed to provide performance at daemon thread in tomcat
Hi Koti, There is not much between a daemon and not daemon thread in the JVM so until you: * start tomcat in an already (over)loaded environment (OSGi, multi-server instances) or * have some agent or plugin using AttachCurrentThreadAsDaemon extension point there is no reason using yield would help. So high level I think it makes sense for you to create instructions to reproduce the issue (you create a github repository with scripts or a readme to explain how to evaluate and identity this slowness for anyone willing to help on this topic) cause technically it looks like you don't fix the root cause of your issue but a side effect. Regards, 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 lun. 15 janv. 2024 à 09:45, koteswara Rao Gundapaneni < koti.gundapan...@gmail.com> a écrit : > On Sun, 14 Jan 2024, 18:13 koteswara Rao Gundapaneni, < > koti.gundapan...@gmail.com> wrote: > > > hi > > > > Daemon threads have identified the performance issue inorder to complete > . > > > > > Thread which is set as daemon by default has performance bottleneck > > I explain that as below > > myeg.setDaemon(true); > myeg.start(); > > > the above start() method is taking long time to complete which is by > default performance bottleneck > > > > > so bootstrap has its performance issue as this loader thread is using > > daemon thread. > > > > > In our code base we have lot of places where we have the code as below as > mentioned above. > > myeg.setDaemon(true); > myeg.start(); > > > > > inorder to resolve the issue we will yield the corresponding thread > > > > > Inorder to limit the time taking for above line of code we have the > solution like below > > myeg.setDaemon(true); > myeg.start(); > myeg.yield(); > > > the yield method declared as above will reduce the time taking for start > method > > > > Hope this will make sense if not I will write it in my own language telugu. > > > > regards, > > koti > > > > > > On Sun, Jan 14, 2024 at 4:13 AM Mark Thomas wrote: > > > >> You have yet to provide an explanation of the problem you are trying to > >> solve. > >> > >> Unless and until you provide the information requested, further messages > >> from you on this topic will be ignored. > >> > >> Mark > >> > >> > >> On 14/01/2024 12:05, koteswara Rao Gundapaneni wrote: > >> > hi team > >> > > >> > before clicking the link or check new private window in mozilla > >> > > >> > image.png > >> > > >> > > >> > > >> > when we browse the following link > >> > > >> > > >> > https://github.com/KoteswararaoGundapaneni/KotiSpringRepository/tree/master > >> < > >> > https://github.com/KoteswararaoGundapaneni/KotiSpringRepository/tree/master > >> > > >> > > >> > > >> > image.png > >> > > >> > Here the code page is shown as above > >> > > >> > > >> > > >> > On Fri, Jan 12, 2024 at 6:41 PM koteswara Rao Gundapaneni > >> > mailto:koti.gundapan...@gmail.com>> > wrote: > >> > > >> > > >> > hi mark, > >> > > >> > please check if the code is now available at your end I verified > >> > from my end it can be visible > >> > > >> > On Fri, Jan 12, 2024 at 1:28 AM koteswara Rao Gundapaneni > >> > mailto:koti.gundapan...@gmail.com>> > >> wrote: > >> > > >> > > >> > Sorry for the inconvenience as its been a private repo just > now > >> > i committed my changes to a new public repo > >> > > >> > > >> > https://github.com/KoteswararaoGundapaneni/KotiSpringRepository/tree/master > >> < > >> > https://github.com/KoteswararaoGundapaneni/KotiSpringRepository/tree/master > >> > > >> > > >> > Please find my attested changes in whole file > 'Bootstrap.java'. > >> > > >> > > >> > > >> > On Fri, Jan 12, 2024 at 12
Re: Invalid CVE on sonatype?
Think it had been done since the report seems to concern v8/v9, this is why from my window sonatype missed a data in their db and it triggers false positives for any recent tomcat build. 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 lun. 16 oct. 2023 à 14:30, Mark Thomas a écrit : > On 16/10/2023 13:11, Romain Manni-Bucau wrote: > > Hi all, > > > > It seems ossindex reports an invalid CVE for tomcat: > > > https://ossindex.sonatype.org/component/pkg:maven/org.apache.tomcat/tomcat-coyote@10.1.15 > > (https://ossindex.sonatype.org/vulnerability/CVE-2023-42794) > > > > Am I right assuming it is due to the way coordinates are entered in their > > system more than an actual issue or did I miss something? > > Should we send a mail to ossin...@sonatype.org to get it fixed? > > It isn't clear to me what Sonatype think the problem is. I have no > interest in creating an account to find out. > > If Sonatype have identified an error in the report (I've looked but > can't see one) then Sonatype should report it to the Tomcat security > team via the usual channel (secur...@tomcat.apache.org). > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Invalid CVE on sonatype?
Hi all, It seems ossindex reports an invalid CVE for tomcat: https://ossindex.sonatype.org/component/pkg:maven/org.apache.tomcat/tomcat-coyote@10.1.15 (https://ossindex.sonatype.org/vulnerability/CVE-2023-42794) Am I right assuming it is due to the way coordinates are entered in their system more than an actual issue or did I miss something? Should we send a mail to ossin...@sonatype.org to get it fixed? 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>
Re: [VOTE] Release Apache Tomcat 10.1.15
+1, thanks for the quick fix 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 jeu. 12 oct. 2023 à 10:04, Rémy Maucherat a écrit : > On Thu, Oct 12, 2023 at 2:50 AM Christopher Schultz > wrote: > > > > The proposed Apache Tomcat 10.1.15 release is now available for > > voting. > > > > The notable changes compared to 10.1.14 are: > > > > - Correct a regression in 10.1.14 that broke the Tomcat JBDC > >connection pool > > > > - Correct a regression in 10.1.14 that broke HTTP compression > > > > For full details, see the change log: > > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > > without changes. Java EE applications designed for Tomcat 9 and earlier > > may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat > > will automatically convert them to Jakarta EE and copy them to the > > webapps directory. > > > > It can be obtained from: > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.15/ > > > > The Maven staging repo is: > > https://repository.apache.org/content/repositories/orgapachetomcat-1462 > > > > The tag is: > > https://github.com/apache/tomcat/tree/10.1.15 > > bd69455d3331a153c411b6f1ac5e434bed06f3ce > > > > The proposed 10.1.15 release is: > > [ ] Broken - do not release > > [X] Stable - go ahead and release as 10.1.15 > > Rémy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: org.apache.tomcat.jdbc.pool.ConnectionPool interface?
Thanks a lot Mark. In the mean time using tomcat-jdbc v10.1.13 works as a workaround (but needs to take care of transitive deps). 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 mar. 10 oct. 2023 à 18:30, Mark Thomas a écrit : > On 10/10/2023 10:13, Mark Thomas wrote: > > On 10/10/2023 09:38, Romain Manni-Bucau wrote: > >> PS: if it eases the analyzis I guess it is an autoimport/refactor issue: > >> > https://github.com/apache/tomcat/commit/a5821ce8ec4626b615a71c9920279a3066735b11#diff-6ec6f1cfd5466f7bef8987d0931a9847d1691c5a81385e4ffd6a7fdb6ddb6cecL371 > > > > Thanks. That is my fault for thinking the tool I used was smarter than > > it really was. > > > > I'll review the entire commit. I may be some time... > > Should be fixed now. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: org.apache.tomcat.jdbc.pool.ConnectionPool interface?
PS: if it eases the analyzis I guess it is an autoimport/refactor issue: https://github.com/apache/tomcat/commit/a5821ce8ec4626b615a71c9920279a3066735b11#diff-6ec6f1cfd5466f7bef8987d0931a9847d1691c5a81385e4ffd6a7fdb6ddb6cecL371 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 mar. 10 oct. 2023 à 16:35, Romain Manni-Bucau a écrit : > Hi, > > in 10.1.14 PooledConnection is a class but it is used to create a jvm > proxy (org.apache.tomcat.jdbc.pool.ConnectionPool#getProxyConstructor) so > it does not work, is it a typo? > > 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> >
org.apache.tomcat.jdbc.pool.ConnectionPool interface?
Hi, in 10.1.14 PooledConnection is a class but it is used to create a jvm proxy (org.apache.tomcat.jdbc.pool.ConnectionPool#getProxyConstructor) so it does not work, is it a typo? 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>
Re: Potential performance improvement
Hi Christopher, A surprising thing is that skipping the new instance if it already fulfills the target makes it faster cause the JVM does it in both latin and utf16 cases, is it due to the fact it does not even check if the chars are surrogate which globally means the boost comes from the limited char set more than the algo? Anyway while it does not add much code a perf boost is always good so +1 too for the reasons you mentionned. 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. 13 sept. 2023 à 23:08, Mark Thomas a écrit : > So we are talking about a saving of around 35 nanoseconds per call. > > I just ran Tomcat 10.1.x through a profiler and requesting the Tomcat > homepage triggered String.toLowerCase() just under 100 times (some of > those calls may be from other JRE methods). So at best, we are looking > at 3 microseconds per request. That is pretty small but it all adds up > over time so +1 from me providing we have some sort of unit tests that > confirms the custom code is faster than the JRE code in case > circumstances change in the future. > > Mark > > > On 13/09/2023 17:38, Christopher Schultz wrote: > > All, > > > > Ping. I've added a few other implementations which will e.g. perform no > > char-copy if the string is already in lower-case, so they are faster > > under special circumstances. > > > > I'm happy to share my jmh runs, which seem to show that Java's > > String.toLowerCase is getting faster and faster every time I run the > > benchmark, which is puzzling. > > > > Thanks, > > -chris > > > > On 9/8/23 13:39, Christopher Schultz wrote: > >> All, > >> > >> Please ignore the fact that my benchmark is all oriented around > >> toUpperCase instead of toLowerCase :) > >> > >> -chris > >> > >> On 9/8/23 13:25, Christopher Schultz wrote: > >>> All, > >>> > >>> There are many cases in Tomcat where we change the letter-case of a > >>> String value so it's easier to compare when case doesn't matter. In > >>> particular, HTTP header names and many spec-defined values are > >>> supposed to be case-insensitive and so all comparisons involving them > >>> must be done without regard to letter-case. > >>> > >>> The idiom in Tomcat source code for that is[1]: > >>> > >>> collection.add(element.toLowerCase(Locale.ENGLISH)); > >>> > >>> Locale.ENGLISH is used because all of these values are supposed to be > >>> in ASCII encoding and Locale.ENGLISH is as good as any equivalent > >>> Locale that (nominally) uses (mostly) ASCII semantics. > >>> > >>> It turns out that String.toLowerCase (and it's mirror, > >>> String.toUpperCase) has a ton of code in it to manage the many > >>> complexities of Locales in which we are not interested. > >>> > >>> Implementing an ASCII-only version of toLowerCase appears to have a > >>> speed improvement of roughly 2x for some simple cases. I have a > >>> sample microbenchmark below and the output of jmh on Java 17. > >>> > >>> Given the frequency of calls to toLowerCase (many ties per request), > >>> I think it may be a worthwhile performance improvement to implement > >>> and use our own version of toLowerCase and use it when only ASCII is > >>> expected. > >>> > >>> It may even be possible to write a more complicated version of > >>> toLowerCase than I have below that performs even faster (e.g. for > >>> String values that end up not having any upper-case characters at all). > >>> > >>> WDYT? > >>> > >>> -chris > >>> > >>> [1] > >>> > https://github.com/apache/tomcat/blob/feb77a15849389001ebcfdd623df86a42a62019e/java/org/apache/tomcat/util/http/parser/TokenList.java#L95 > >>> > >>> BenchmarkMode Cnt Score > >>> Error Units > >>> MyBenchmark.testStringToUpperCase thrpt5 28130795.259 ± > >>> 1297495.570 ops/s > >>> MyBenchmark.testStringToUpperCaseASCII thrpt5 52221288.421 ± > >>> 5112349.492 ops/s > >>
Re: Hide jakarta.annotations from tomcat-catalina?
Ok, and doing a tomcat-catalina-xxx which wouldnt target spec explicitly, would more be a http server reusable is not an option too I guess? So for the record I guess the best option is to switch to SimpleInstanceManager automatically. Thanks for the clarification Mark. 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 jeu. 13 juil. 2023 à 15:15, Mark Thomas a écrit : > 12 Jul 2023 10:50:30 Romain Manni-Bucau : > > > Le mer. 12 juil. 2023 à 10:47, Mark Thomas a écrit : > > > >> On 07/07/2023 09:33, Romain Manni-Bucau wrote: > >>> Hi, > >>> > >>> Do you think we can make jakarta.annotations optional from > >> tomcat-catalina? > >>> Would ease IDE completion when this is not supported and tomcat is > >> wrapped > >>> in another web api. > >> > >> I don't think so. @PostConstruct and @PreDestory support is a > >> mandatory > >> requirement of the Servlet spec. > >> > > > > Does not mean it can not be made optional if not in the classpath > > technically - or did you speak more on "will" side? > > I think I am close to a -1 on such a change. Marking what is a mandatory > dependency as optional is likely to cause issues for folks that need it. > It isn't as if they expect to have to add the dependency to use those > annotations. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: multipart streaming as fileupload native usage?
Le mer. 12 juil. 2023 à 17:53, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Romain, > > On 7/11/23 08:57, Romain Manni-Bucau wrote: > > on commons fileupload list there was the need to have streaming for > Parts. > > > > As of today Servlet API enables to only get a list and not an iterator - > > even if it uses it under the hood. > > :/ > > It's a Collection, though, and not a List, so there is a little more > flexibility. > > > Any way tomcat pushes that need (Iterator or Stream I guess) to the > servlet > > EG for next version? > > We could certainly propose it. Something like > > Iterator HttpServletRequest.getPartIterator() > and/or > Stream HttpServletRequst.getPartStream() > > > Do we want to provide this thru the current API implementing a LazyList > > (while only Iterator is touched the list is not materialized)? > > If implemented as a LazyList, then getParts().iterator() will get you > what you want and the Servlet API need not be modified. On the other > hand, supporting such streaming interfaces better-communicates the > application's intent to consume the parts in a streaming fashion rather > than all-at-once. > > But it may delay IO errors until after getParts() is called. How would > we handle that? With some kind of RuntimeException thrown from > Collection, Iterator, and Stream operations? > Yes, an IllegalStateException from Iterator implementation sounds sufficient (stream being an iterator wrapper thanks StreamSupport class). > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Hide jakarta.annotations from tomcat-catalina?
Le mer. 12 juil. 2023 à 10:47, Mark Thomas a écrit : > On 07/07/2023 09:33, Romain Manni-Bucau wrote: > > Hi, > > > > Do you think we can make jakarta.annotations optional from > tomcat-catalina? > > Would ease IDE completion when this is not supported and tomcat is > wrapped > > in another web api. > > I don't think so. @PostConstruct and @PreDestory support is a mandatory > requirement of the Servlet spec. > Does not mean it can not be made optional if not in the classpath technically - or did you speak more on "will" side? > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
multipart streaming as fileupload native usage?
Hi all, on commons fileupload list there was the need to have streaming for Parts. As of today Servlet API enables to only get a list and not an iterator - even if it uses it under the hood. Any way tomcat pushes that need (Iterator or Stream I guess) to the servlet EG for next version? Do we want to provide this thru the current API implementing a LazyList (while only Iterator is touched the list is not materialized)? 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>
Hide jakarta.annotations from tomcat-catalina?
Hi, Do you think we can make jakarta.annotations optional from tomcat-catalina? Would ease IDE completion when this is not supported and tomcat is wrapped in another web api. Technically it does not look crazy but wonder if it can end upstream.
Re: Tomcat and filesystems
If it helps, here is a draft: https://github.com/apache/tomcat/pull/630 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 lun. 26 juin 2023 à 10:53, Mark Thomas a écrit : > On 25/06/2023 13:50, Romain Manni-Bucau wrote: > > Hi all, > > > > Doing some tests I realized two things: > > > > * tomcat still uses File a lot (thinking to default servlet stack) > > * tomcat does not uses FileSystem abstraction and previous point would > only > > makes sense with this addition > > > > What about a (nio) Fileystem/Path based implementation of WebResourceSet? > > It would enable to not only rely on local filesystem but also more exotic > > ones (in mem for ex). > > Was it already discussed/studied? > > I don't recall any discussions. There have been a few discussions around > using custom implementations of various WebResouce classes but that has > generally been to customize some specific behaviour. > > > Would it makes sense in tomcat codebase? > > It depends if there is demand for it. My initial reaction is "probably > not". > > Where I think there probably is room for improvement is some refactoring > to make it easier to use custom implementations for different parts of > the WebResource implementation. Picking a random example, custom JAR > handling to validate signatures. > > If there is a demand for extending WebResource, making it easier to have > custom implementations will hopefully give us an insight into what that > demand is. If there was something folks were consistently asking for > then it would make sense to include it in the default Tomcat distribution. > > All that said, I do think if there was a demand for this sort of > functionality we would have seen some indication of that on the users > list. But maybe it is chicken/egg situation so I am in favour of making > custom extensions/implementations easier and seeing what happens. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Tomcat and filesystems
Hi all, Doing some tests I realized two things: * tomcat still uses File a lot (thinking to default servlet stack) * tomcat does not uses FileSystem abstraction and previous point would only makes sense with this addition What about a (nio) Fileystem/Path based implementation of WebResourceSet? It would enable to not only rely on local filesystem but also more exotic ones (in mem for ex). Was it already discussed/studied? Would it makes sense in tomcat codebase? 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>
Re: [tomcat] branch main updated: Add control of byte decoding errors to ByteChunk and StringCache
Hi Rémy,
If it helps openjmh uses an annotation processor so you can use it with ant
build, the setup is just not documented AFAIK but there is no reason it
does not work technically.
Then code usage is more or less close to junit, run is a main which will
include resources/files generated from the annotation processor, really
nothing crazy IMHO on that part (hard one is to use Blackhole properly and
tune the jvm for the bench) but happy to help if needed.
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 ven. 23 juin 2023 à 10:15, Rémy Maucherat a écrit :
> On Fri, Jun 23, 2023 at 10:07 AM Mark Thomas wrote:
> >
> > On 23/06/2023 08:34, Rémy Maucherat wrote:
> > > On Thu, Jun 22, 2023 at 8:55 PM wrote:
> > >>
> > >> This is an automated email from the ASF dual-hosted git repository.
> > >>
> > >> markt pushed a commit to branch main
> > >> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> > >>
> > >>
> > >> The following commit(s) were added to refs/heads/main by this push:
> > >> new 944951302e Add control of byte decoding errors to ByteChunk
> and StringCache
> > >> 944951302e is described below
> > >>
> > >> commit 944951302e2f478879411dbff353f5818ad44121
> > >> Author: Mark Thomas
> > >> AuthorDate: Wed Jun 14 12:25:21 2023 +0100
> > >>
> > >> Add control of byte decoding errors to ByteChunk and StringCache
> >
> >
> >
> > >> +/**
> > >> + * Converts the current content of the byte buffer to a String
> using the configured character set.
> > >> + *
> > >> + * @param malformedInputAction Action to take if the input
> is malformed
> > >> + * @param unmappableCharacterAction Action to take if a byte
> sequence can't be mapped to a character
> > >> + *
> > >> + * @return The result of converting the bytes to a String
> > >> + *
> > >> + * @throws CharacterCodingException If an error occurs during
> the conversion
> > >> + */
> > >> +public String toStringInternal(CodingErrorAction
> malformedInputAction, CodingErrorAction unmappableCharacterAction)
> > >> +throws CharacterCodingException {
> > >> if (charset == null) {
> > >> charset = DEFAULT_CHARSET;
> > >> }
> > >> // new String(byte[], int, int, Charset) takes a defensive
> copy of the
> > >> // entire byte array. This is expensive if only a small
> subset of the
> > >> // bytes will be used. The code below is from Apache
> Harmony.
> > >> -CharBuffer cb = charset.decode(ByteBuffer.wrap(buff, start,
> end - start));
> > >> +CharBuffer cb =
> charset.newDecoder().onMalformedInput(malformedInputAction)
> > >> +
> .onUnmappableCharacter(unmappableCharacterAction).decode(ByteBuffer.wrap(buff,
> start, end - start));
> > >
> > > Looking at the code, this is not equivalent, like charset.decode uses
> > > thread locals and so on. I will make a change so that charset.decode
> > > is used if is REPLACE REPLACE, if you don't mind. I'm pretty sure
> > > benching would show no performance difference though.
> >
> > Seems reasonable to me.
>
> BTW, for actual microbenchmarks, the OpenJDK people recommend using
> https://github.com/openjdk/jmh rather than whatever hack. Does anyone
> have any experience with it ?
> Since it is Maven based, microbenchmarks would need to be added in a
> separate mavenized location rather than the testsuite.
>
> Rémy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: Tomcat, Jakarta TCKs and Arquillian
Congrats for the achievement, +1 to follow tomcat versions, tag and run at least daily if possible, it is a huge step for tomcat and tck IMHO. Le mer. 21 juin 2023 à 11:10, Mark Thomas a écrit : > On 21/06/2023 09:54, Rémy Maucherat wrote: > > On Wed, Jun 21, 2023 at 10:33 AM Mark Thomas wrote: > >> > >> Thanks again for the pointers. I can run the refactored WebSocket TCK > now. > >> > >> I think we need to setup a new Git project to hold the Tomcat > >> configuration for the refactored TCKs. This would be a multi-module > >> Maven project with one module for each TCK. I have the basis for this > >> locally but it needs some clean-up. > >> > >> One issue in particular is that there are some dependencies that might > >> not be available on Maven central yet. That might delay some of what we > >> want to do or require that folks need to build stuff locally and publish > >> to their local repository to use this - at least while the refactoring > >> is still in progress. > >> > >> A couple of questions. > >> > >> Would we ever release this? Or would it just be a vehicle for running > >> the TCK? I'm not seeing a need to release but we might tag from time to > >> time (e.g. when a Tomcat version passes all the TCKs). > >> > >> Will we (ultimately) want branches for each Tomcat version? I think we > >> will. Currently, the Jakarta EE 10 TCK is being refactored. I'm not sure > >> of the plan but I assume there will be a refactored release for Jakarta > >> EE 10 and then work will start on Jakarta EE 11. > >> > >> What version scheme should we use? Not hugely important if we aren't > >> releasing. Do we leave it on 0.0.1-SNAPSHOT, align it with the TCK > >> version, the Tomcat version or something else? My current thinking is > >> set it to 0.0.1-SNAPSHOT and revisit if we need to. > >> > >> Do we want to configure GitHub actions to run the TCKs after a commit? I > >> think we do as this gives us an easy way to run the TCKs. Update the > >> Tomcat version. Commit. Push. Wait. Done. > >> > >> Thoughts? > > > > It would be quite impressive if this becomes just another testsuite. > > Given how resource and annoyance intensive the previous TCK was, I > > mean. > > Did I mention the TCKs are at least an order of magnitude faster? :) > > The full WebSocket TCK (minus the signature tests which haven't been > migrated yet) run in just over 5 mins and I haven't even looked at > tuning (parallel) options yet. > > Mark > > > > > Rémy > > > >> Mark > >> > >> > >> > >> On 16/06/2023 20:18, Mark Thomas wrote: > >>> Thanks, those are really helpful. I'll try and find some time to look > at > >>> this some more next week. > >>> > >>> Mark > >>> > >>> > >>> On 16/06/2023 17:59, Romain Manni-Bucau wrote: > >>>> Yes > >>>> > >>>> > https://github.com/apache/bval/blob/master/bval-tck/src/main/java/org/apache/bval/arquillian/BValArquillianExtension.java > >>>>or > >>>> > https://github.com/apache/geronimo-opentracing/blob/master/geronimo-opentracing/src/test/java/org/apache/geronimo/microprofile/opentracing/tck/setup/SkipOpentracingApiSetup.java > >>>> > >>>> To hack the container I guess the easiest is to override default > >>>> tomcat one > >>>> to force a context class and then hack the autoconfig in the custom > >>>> context. > >>>> > >>>> If needed i can do a poc to explain more next week if it helps and you > >>>> point me a pom setup you use for deps to ensure I use the same ones. > >>>> > >>>> Le ven. 16 juin 2023 à 18:12, Mark Thomas a écrit > : > >>>> > >>>>> Do you have a pointer for an example of the custom TCK loadable > >>>>> extension? That sounds like it might be all we need. If the plumbing > is > >>>>> already in place in Arquillian then I'm happy not to reinvent the > wheel. > >>>>> > >>>>> Mark > >>>>> > >>>>> > >>>>> > >>>>> On 16/06/2023 16:34, Romain Manni-Bucau wrote: > >>>>>> Hi Mark, > >>>>>> > >>>>>> On TomEE side (and other spec impl ones) we had a hybrid approach: > >
Re: Tomcat, Jakarta TCKs and Arquillian
Yes https://github.com/apache/bval/blob/master/bval-tck/src/main/java/org/apache/bval/arquillian/BValArquillianExtension.java or https://github.com/apache/geronimo-opentracing/blob/master/geronimo-opentracing/src/test/java/org/apache/geronimo/microprofile/opentracing/tck/setup/SkipOpentracingApiSetup.java To hack the container I guess the easiest is to override default tomcat one to force a context class and then hack the autoconfig in the custom context. If needed i can do a poc to explain more next week if it helps and you point me a pom setup you use for deps to ensure I use the same ones. Le ven. 16 juin 2023 à 18:12, Mark Thomas a écrit : > Do you have a pointer for an example of the custom TCK loadable > extension? That sounds like it might be all we need. If the plumbing is > already in place in Arquillian then I'm happy not to reinvent the wheel. > > Mark > > > > On 16/06/2023 16:34, Romain Manni-Bucau wrote: > > Hi Mark, > > > > On TomEE side (and other spec impl ones) we had a hybrid approach: > > > > * Add arquillian container properties when reusable (ex: context > > customization for tomcat for ex) > > * Add a custom tck loadableextension (ServiceLoader for arquillian) which > > overrides the container for the specific tck suite > > > > Overall any scanning must be hybrid between container and app with > embedded > > container in arquillian approach (in openwebbeans/tomee we configure the > > resources we can read from container or not for ex!). > > > > So I think the easiest would be to just make the context and loader > > configurable from arquillian.xml for this particular case or if not > willed, > > let tomcat-tck module patch the default container to do it > programmatically > > specifically for tck runner. Kind of least worse compromise IMHO. > > > > 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 ven. 16 juin 2023 à 17:11, Mark Thomas a écrit : > > > >> Hi all, > >> > >> The Jakarta TCK project is in the process of refactoring the TCKS to run > >> with JUnit 5 and Arquillian. I have tested early versions of the > >> refactored EL and WebSocket and things are very promising. The TCKs > >> complete a LOT faster. > >> > >> I hit upon a small niggle with the WebSocket TCK and wanted to get some > >> feedback on solutions. > >> > >> The way the WebSocket TCK is constructed, it exposes the entire > >> testsuite on the class path, as well as the current WAR file under test. > >> The annotation scanning therefore picks up all the tests, attempts to > >> deploy them all which - unsurprisingly - fails due to path conflicts. > >> The fix is to set StandardJarScanner.scanClassPath to false. The > >> question is how best to do this long term. > >> > >> My current solution is to change the default, rebuild Tomcat 10.1.x > >> snapshot, deploy it to my local Maven repository and then run the TCK > >> with the snapshot. That works but isn't a viable long-term solution. > >> > >> Other ideas I have had: > >> > >> Add a system property (yuck) to set the default for > >> StandardJarScanner.scanClassPath. I don;t like this because a) it adds a > >> system property and b) it isn't scalable if there are other settings we > >> need to configure for the TCKs. > >> > >> Update the Arquillian containers to add new configuration properties. > >> Better, but dependent on the Arquillian project for Tomcat containers > >> that is looking dormant. Forking is an option but there is still the > >> issue of adding more and more settings over time. My fear is this ends > >> up like the admin app and never keeps up with newly added features. > >> > >> Use the ServiceLoader mechanism on Tomcat instance creation to load > >> LifecycleListener instances that are then attached to the Server > >> instance and can be used to configure it. Use some new class like > >> EmbeddedConfigurationLifecycleListener for this. For security, disable > >> this behaviour by default unless enabled with (yuck) a system property. > >> > >> I'm leaning towards the ServiceLoader appro
Re: Tomcat, Jakarta TCKs and Arquillian
Hi Mark, On TomEE side (and other spec impl ones) we had a hybrid approach: * Add arquillian container properties when reusable (ex: context customization for tomcat for ex) * Add a custom tck loadableextension (ServiceLoader for arquillian) which overrides the container for the specific tck suite Overall any scanning must be hybrid between container and app with embedded container in arquillian approach (in openwebbeans/tomee we configure the resources we can read from container or not for ex!). So I think the easiest would be to just make the context and loader configurable from arquillian.xml for this particular case or if not willed, let tomcat-tck module patch the default container to do it programmatically specifically for tck runner. Kind of least worse compromise IMHO. 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 ven. 16 juin 2023 à 17:11, Mark Thomas a écrit : > Hi all, > > The Jakarta TCK project is in the process of refactoring the TCKS to run > with JUnit 5 and Arquillian. I have tested early versions of the > refactored EL and WebSocket and things are very promising. The TCKs > complete a LOT faster. > > I hit upon a small niggle with the WebSocket TCK and wanted to get some > feedback on solutions. > > The way the WebSocket TCK is constructed, it exposes the entire > testsuite on the class path, as well as the current WAR file under test. > The annotation scanning therefore picks up all the tests, attempts to > deploy them all which - unsurprisingly - fails due to path conflicts. > The fix is to set StandardJarScanner.scanClassPath to false. The > question is how best to do this long term. > > My current solution is to change the default, rebuild Tomcat 10.1.x > snapshot, deploy it to my local Maven repository and then run the TCK > with the snapshot. That works but isn't a viable long-term solution. > > Other ideas I have had: > > Add a system property (yuck) to set the default for > StandardJarScanner.scanClassPath. I don;t like this because a) it adds a > system property and b) it isn't scalable if there are other settings we > need to configure for the TCKs. > > Update the Arquillian containers to add new configuration properties. > Better, but dependent on the Arquillian project for Tomcat containers > that is looking dormant. Forking is an option but there is still the > issue of adding more and more settings over time. My fear is this ends > up like the admin app and never keeps up with newly added features. > > Use the ServiceLoader mechanism on Tomcat instance creation to load > LifecycleListener instances that are then attached to the Server > instance and can be used to configure it. Use some new class like > EmbeddedConfigurationLifecycleListener for this. For security, disable > this behaviour by default unless enabled with (yuck) a system property. > > I'm leaning towards the ServiceLoader approach as it gives us maximum > flexibility and maximum control. It also provides a way for folks to > configure Tomcat when it is embedded in other products with the > necessary configuration being exposed. > > Thoughts? > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Java 21 and virtual threads
+1 for java 21, since tomcat 11 is still in the "dont use" area I think it can start with 21 and thanks to the backport policy if java 17 is needed later, work will not be crazy IMHO. 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 ven. 5 mai 2023 à 03:53, Han Li a écrit : > > > > On May 4, 2023, at 20:37, Mark Thomas wrote: > > > > Hi all, > > > > The latest Java 21 EA build has moved virtual threads (from project > Loom) out of preview. How do we want to handle this in Tomcat 11? Recall > that Jakarta EE 11 has set Java 21 as the minimum version. > > > > I think we have the following options: > > > > 1. Stick with Java 17 as the minimum version and don't provide virtual > thread functionality. > > > > 2. Stick with Java 17 as the minimum version and provide virtual thread > functionality via the JreCompat module. > > > > 3. Increase minimum Java version to Java 21 for Tomcat 11 and provide > virtual thread functionality. > +1 > > The impact of switching 17 to 21 will not be very wide I think as Tomcat > 11 is Alpha version now, so let’s be straightforward. :) > > Han > > > > > I am currently leaning towards 3 but could live with 2. > > > > Thoughts? Other options? > > > > Mark > > > > PS Option 3 will require updates to the CI systems - I am happy to take > care of those. > > > > PPS I don't think all of the current Loom module will make it into > Tomcat 11. I am currently thinking to pull in the Executor and then provide > a boolean option for the existing endpoints to switch the internal executor > to Loom. > > > > - > > 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: Workaround for misbehaving ClassLoader
Hi Chris,
Fixing the parent in this project is quite easy, if the OSGi
bundle.getResources returns null then return emptyEnumeration instead of
the direct result of the call but generally speaking this is a valid
statement but I guess Tomcat can await some other hit of this issue to push
forward a fix it since this one is very trivial to do in the failing
project ([1]).
[1]
https://github.com/CodeGerm/osgi-server/blob/master/plugins/org.cg.dao.webcontainer/src/org/cg/dao/webcontainer/tomcat/DaoClassLoader.java#L132
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. 3 mai 2023 à 21:02, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
> All,
>
> Please check this thread for full details:
> https://lists.apache.org/thread/of5ozg43zyk729cg311dktjcv3swct26
>
> Briefly, a user reported this NPE:
>
> Apr 29, 2023 5:41:32 PM org.apache.catalina.core.StandardContext
> listenerStart
> SEVERE: Exception sending context initialized event to listener instance
> of class [org.springframework.web.context.ContextLoaderListener]
> java.lang.NullPointerException
> at
>
> org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(WebappClassLoaderBase.java:2775)
> at
>
> org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(WebappClassLoaderBase.java:2760)
> at
>
> org.apache.commons.logging.LogFactory.getConfigurationFile(LogFactory.java:1366)
> at
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:453)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
>
> Mark introduced the CombinedEnumeration in
>
> https://github.com/apache/tomcat/commit/fdd35009ead6365cbae84008e63356d6ab88ed40
> to merge the resources from the parent ClassLoader with the
> WebappClassLoader(Base). His code looks sound to me, but it can expose
> what I think of as a bug in the ClassLoader being used as the parent.
>
> ClassLoader.getResources is documented to return an empty Enumeration if
> there are no matching resources, but in this case, the ClassLoader is
> returning null.
>
> WebappClassLoaderBase assumes that the parent ClassLoader is following
> the rules and so grabs the resources from both itself and the parent and
> combines them using CombinedEnumeration.
>
> Here is a patch that will fix that:
>
> diff --git a/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> index aa747a5873..6f98f6e413 100644
> --- a/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> +++ b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> @@ -1121,7 +1121,9 @@ public abstract class WebappClassLoaderBase
> extends URLClassLoader
> // Enumerations are combined depends on how delegation is
> configured
> boolean delegateFirst = delegate || filter(name, false);
>
> -if (delegateFirst) {
> +if(null == parentResources) {
> +return localResources;
> +} else if (delegateFirst) {
> return new CombinedEnumeration(parentResources,
> localResources);
> } else {
> return new CombinedEnumeration(localResources,
> parentResources);
>
> But my question is whether or not this is something that Tomcat should
> be working-around. IMO the parent ClassLoader is buggy and should be
> fixed, but it may be difficult or impossible to fix the parent, so it
> may be worth it.
>
> We could even log it including the class name of the offending ClassLoader.
>
> WDYT?
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: Utility Executor
Le ven. 28 avr. 2023 à 11:55, Rémy Maucherat a écrit :
> On Fri, Apr 28, 2023 at 9:02 AM Romain Manni-Bucau
> wrote:
> >
> > Le ven. 28 avr. 2023 à 08:36, Rémy Maucherat a écrit :
> >
> > > On Fri, Apr 28, 2023 at 8:10 AM Romain Manni-Bucau
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > Guess this utility should be there very early so before other
> > > starts/stops
> > > > sounds good but ultimately init/destroy is better since it avoids to
> > > create
> > > > custom utility threads in subcomponents init/destroy (more destroy
> for
> > > real
> > > > cases I think, not sure for init).
> > >
> > > The Server starts first and stops last, so it seems it will be fine. I
> > > don't quite see why it is a good idea to do utility tasks in init or
> > > destroyed (they should happen in start or stop).
> > > Right now the only item which needs to change is that the connector
> > > endpoint gets it on init. The other components were using it on start.
> > >
> >
> > Still in the spirit of being "stable" in terms of threads and avoiding to
> > create instances per components (which makes the machine under stress, in
> > particular when combined with colocalised deployments - k8s style or just
> > multiple processes locally.
> > The destroy usage I saw was mainly to push (broadcast) metrics captured
> > between stop and destroy by valves - but can ack it is a bit particular
> so
> > can not need something specific.
>
> We are talking about a Server.stop/start here, this is a very
> expensive process (TLS configs, and so on), and I don't understand why
> it would be a good idea to allow background tasks of subcomponents to
> keep running.
>
Server means more or less all the subgraph, it is not about leaking tasks
but dont break the backward compat since today it is allowed.
>
> > That said I'm not sure it fixes the spring-boot issue at all.
>
> Remy
>
> >
> > >
> > > Remy
> > >
> > > > What about getting it injected from the context and ignoring its
> > > lifecycle
> > > > ("external" notion)? Will keep it globally usable and integrate
> smoothly
> > > > with any env.
> > > >
> > > >
> > > > Le ven. 28 avr. 2023 à 04:27, Han Li a écrit :
> > > >
> > > > >
> > > > >
> > > > > > On Apr 28, 2023, at 00:33, Mark Thomas wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > As part of a discussion around a Spring Boot issue [1], the
> question
> > > has
> > > > > been raised whether there is merit in moving the Utility executor
> > > > > start/stop from StandardServer init/destroy to start/stop.
> > > > > >
> > > > > > I've looked at the code and I don't see any uses of the Executor
> > > until
> > > > > sub-components are in the start phase (there is a little copying of
> > > > > references that might need to move) so I think the change is
> doable.
> > > > >
> > > > > Maybe ContainerBase#startStopExecutor also need same operation
> above?
> > > > >
> > > > > >
> > > > > > The main advantage is that in the embedded scenario where there
> > > might be
> > > > > a long series of start / stop / start / stop etc, shutting down the
> > > > > executor on stop should avoid issues where executor tasks are not
> > > shutdown
> > > > > correctly. My brief code review suggested that Tomcat does this
> > > correctly
> > > > > but the executor is also exposed to application code.
> > > > > >
> > > > > > Thoughts?
> > > > > + 1
> > > > >
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > > [1] https://github.com/spring-projects/spring-boot/issues/34955
> > > > > >
> > > > > >
> -
> > > > > > 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
>
>
Re: Utility Executor
Le ven. 28 avr. 2023 à 08:36, Rémy Maucherat a écrit :
> On Fri, Apr 28, 2023 at 8:10 AM Romain Manni-Bucau
> wrote:
> >
> > Hi
> >
> > Guess this utility should be there very early so before other
> starts/stops
> > sounds good but ultimately init/destroy is better since it avoids to
> create
> > custom utility threads in subcomponents init/destroy (more destroy for
> real
> > cases I think, not sure for init).
>
> The Server starts first and stops last, so it seems it will be fine. I
> don't quite see why it is a good idea to do utility tasks in init or
> destroyed (they should happen in start or stop).
> Right now the only item which needs to change is that the connector
> endpoint gets it on init. The other components were using it on start.
>
Still in the spirit of being "stable" in terms of threads and avoiding to
create instances per components (which makes the machine under stress, in
particular when combined with colocalised deployments - k8s style or just
multiple processes locally.
The destroy usage I saw was mainly to push (broadcast) metrics captured
between stop and destroy by valves - but can ack it is a bit particular so
can not need something specific.
That said I'm not sure it fixes the spring-boot issue at all.
>
> Remy
>
> > What about getting it injected from the context and ignoring its
> lifecycle
> > ("external" notion)? Will keep it globally usable and integrate smoothly
> > with any env.
> >
> >
> > Le ven. 28 avr. 2023 à 04:27, Han Li a écrit :
> >
> > >
> > >
> > > > On Apr 28, 2023, at 00:33, Mark Thomas wrote:
> > > >
> > > > Hi all,
> > > >
> > > > As part of a discussion around a Spring Boot issue [1], the question
> has
> > > been raised whether there is merit in moving the Utility executor
> > > start/stop from StandardServer init/destroy to start/stop.
> > > >
> > > > I've looked at the code and I don't see any uses of the Executor
> until
> > > sub-components are in the start phase (there is a little copying of
> > > references that might need to move) so I think the change is doable.
> > >
> > > Maybe ContainerBase#startStopExecutor also need same operation above?
> > >
> > > >
> > > > The main advantage is that in the embedded scenario where there
> might be
> > > a long series of start / stop / start / stop etc, shutting down the
> > > executor on stop should avoid issues where executor tasks are not
> shutdown
> > > correctly. My brief code review suggested that Tomcat does this
> correctly
> > > but the executor is also exposed to application code.
> > > >
> > > > Thoughts?
> > > + 1
> > >
> > > >
> > > > Mark
> > > >
> > > > [1] https://github.com/spring-projects/spring-boot/issues/34955
> > > >
> > > > -
> > > > 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
>
>
Re: Utility Executor
Hi
Guess this utility should be there very early so before other starts/stops
sounds good but ultimately init/destroy is better since it avoids to create
custom utility threads in subcomponents init/destroy (more destroy for real
cases I think, not sure for init).
What about getting it injected from the context and ignoring its lifecycle
("external" notion)? Will keep it globally usable and integrate smoothly
with any env.
Le ven. 28 avr. 2023 à 04:27, Han Li a écrit :
>
>
> > On Apr 28, 2023, at 00:33, Mark Thomas wrote:
> >
> > Hi all,
> >
> > As part of a discussion around a Spring Boot issue [1], the question has
> been raised whether there is merit in moving the Utility executor
> start/stop from StandardServer init/destroy to start/stop.
> >
> > I've looked at the code and I don't see any uses of the Executor until
> sub-components are in the start phase (there is a little copying of
> references that might need to move) so I think the change is doable.
>
> Maybe ContainerBase#startStopExecutor also need same operation above?
>
> >
> > The main advantage is that in the embedded scenario where there might be
> a long series of start / stop / start / stop etc, shutting down the
> executor on stop should avoid issues where executor tasks are not shutdown
> correctly. My brief code review suggested that Tomcat does this correctly
> but the executor is also exposed to application code.
> >
> > Thoughts?
> + 1
>
> >
> > Mark
> >
> > [1] https://github.com/spring-projects/spring-boot/issues/34955
> >
> > -
> > 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: sendfile and async?
The use case was something like: * checkDocBaseUpToDate() // done async if the validity period is passed (means each 5mn check wil be async else sync is ok) * serve() // delegate No error but the GET has the right content-length but content is empty cause in async sendfile is not processed. Le jeu. 20 avr. 2023 à 22:30, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Rmoain, > > On 4/20/23 15:27, Romain Manni-Bucau wrote: > > I just notice using nio connector+sendfile+asynccontext seems quite not > > functional, is it intended? > > > > My original intent was to add a kind of pre-hook to DefaultServlet which > > was async (nio http client) so wanted to use asynccontext then delegate > to > > super.doGet (more or less) but I got this sendfile issue with such a > mode. > > Is it intended or just part of the code which didnt get enough love? > > Can you give a little more detail? > > You wanted to subclass DefaultServlet but delegate to super.doGet under > some cases, right? Do you always enter async mode, then delegate? What > error/failure do you get? > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
sendfile and async?
Hi all, I just notice using nio connector+sendfile+asynccontext seems quite not functional, is it intended? My original intent was to add a kind of pre-hook to DefaultServlet which was async (nio http client) so wanted to use asynccontext then delegate to super.doGet (more or less) but I got this sendfile issue with such a mode. Is it intended or just part of the code which didnt get enough love? 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>
Re: Support of ReadListener for Reader?
Overall +1 but in the meantime what's the option, not using req.getReader? 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 lun. 3 avr. 2023 à 20:51, Mark Thomas a écrit : > On 02/04/2023 18:23, Romain Manni-Bucau wrote: > > Hi all, > > > > Wonder if tomcat couldn't get ReadListener support for > request.getReader(), > > I know it is not in servlet spec but it is weirdish to have a high level > > API less usable than the low level one because it lacks features. > > Since CoyoteReader uses the same input than the servlet inputstream > > (inputbuffer) it would just be a matter of enabling to forward the > > setReadListener. > > Now, on an API standpoint and for me, it makes more sense to do it on the > > servlet request since it gives callbacks of the request more than on a > > particular input impl so it can be a better option. > > I'm not sure if RequestFacade would be casted as such or if some Unwrap > API > > can help but it would really help to promote this API without enforcing > > InputStream usage which can make the code not respecting the encoding > quite > > easily - or enforce to duplicate servlet logic and its optimizations. > > > > Wdyt? > > I think I'd rather see changes like this come via the Servlet spec > rather than add Tomcat specific API for something as fundamental as > reading the request body. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Support of ReadListener for Reader?
Hi all, Wonder if tomcat couldn't get ReadListener support for request.getReader(), I know it is not in servlet spec but it is weirdish to have a high level API less usable than the low level one because it lacks features. Since CoyoteReader uses the same input than the servlet inputstream (inputbuffer) it would just be a matter of enabling to forward the setReadListener. Now, on an API standpoint and for me, it makes more sense to do it on the servlet request since it gives callbacks of the request more than on a particular input impl so it can be a better option. I'm not sure if RequestFacade would be casted as such or if some Unwrap API can help but it would really help to promote this API without enforcing InputStream usage which can make the code not respecting the encoding quite easily - or enforce to duplicate servlet logic and its optimizations. Wdyt? 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>
Re: PersistentManager, PersistentValve, and DataSource/JDBCStore can cause PK violations
Le mer. 8 mars 2023 à 16:23, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
> Romain,
>
> On 3/8/23 04:10, Romain Manni-Bucau wrote:
> > Seems doing it only there will get back to the issue the synchronization
> > was introduced (there are other synchronized(session) for "local"
> instance).
>
> Don't forget that there are multiple reasons to synchronize on a
> session, and they solve different problems. Some examples:
>
> 1. Don't corrupt the internal state of the Session
>
> synchronized(session) {
>Integer count = (Integer)session.getAttribute("count");
>count = count +1;
>session.setAttribute("count", count);
> }
>
> This ensures that you don't "count twice" or fail to count even once
> when there are multiple threads in play. There are application business
> reasons to do this kind of thing, and this doesn't solve them all (e.g.
> across a cluster, or for different threads working on the "same" session
> but with different JVM objects representing them).
>
> If there are multiple JVM objects in play, this is still appropriate
> because it solves the immediate problem.
>
Hmm, i didn't check recently but this was not guaranteed by servlet spec,
is it - if so the issue you describe wouldn't be probably too?
>
> 2. Don't do something with the session simultaneously that's Important
>
> That's where this proposal falls: the PresistentManager knows it only
> wants to do something very specific, here, and no other code needs to
> know about it or cares about it.
>
> So I think it's okay not to worry about /other/ instances of
> synchronized(session) in the code and having to update those. Those are
> being done for a different reason.
>
> > However you hit a real point, the instance does not have to be stable,
> only
> > its equals/hashCode could be considered stable so guess the idea would be
> > to add to the session *manager* a getLock() method (don't think a RWLock
> is
> > needed there due to current usage) and use it instead of synchronized.
>
> The synchronization mechanism itself isn't super important, it's just
> that we want to:
>
> 1. Perform operations for this one session (regardless of how many JVM
> objects are present in memory)
>
> 2. Allow other sessions to continue without interfering with them
>
> It would be easy to just synchronzied(this) and never have a problem,
> but that kills performance.
>
> > The lock eviction should get some kind of delay for its own eviction and
> > not be evicted directly with the session to work.
> > A trivial impl could be to use a Map<$sessionId, $lock> and add a default
> > delay of 0 when purely in memory and a few seconds when a remote manager
> is
> > used (this logic belonging to the manager).
>
> Are you talking about a distributed Manager that can handle
> cross-cluster synchronization?
>
No, the (concurrent)map solution was really for local instances just adding
to support a small latency in session destruction/recreation.
>
> A Map of sessionId -> Lock would work locally, and may be the better
> solution but it does require more memory, more management,
> synchronization (or ConcurrentMap, etc.), etc.
>
For me it is not a big deal when you use session because it is exactly the
issue you hit with session themselves (in a worse manner since sessions are
not "a few session" latent objects) so sounds/sounded like a compromise
short term.
>
> > That said it stays a workaround and a better protocol handling that in a
> > cluster can be a more robust (but more complex) solution so not sure
> which
> > compromise is the best.
>
> I'd like to solve the single-JVM case first, here, but I think you have
> some interesting ideas for the future.
>
> If I were implementing a clustered application, I would not choose
> HttpSession as the way to share data across the cluster, for exactly
> these reasons.
>
+1
>
> -chris
>
> > Le mer. 8 mars 2023 à 04:43, Han Li a écrit :
> >
> >>
> >>
> >>> On Mar 8, 2023, at 07:29, Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>>
> >>> All,
> >>>
> >>> Please see https://bz.apache.org/bugzilla/show_bug.cgi?id=66513 for
> >> reference.
> >>>
> >>> It appears that the synchronization used by the PersistentManager can
> >> cause problems when used with the PersistentValve and
> DataSource/JDBCStore.
> >>>
> >>> The problem is that PersistentManager assu
Re: PersistentManager, PersistentValve, and DataSource/JDBCStore can cause PK violations
Hi Chris,
Seems doing it only there will get back to the issue the synchronization
was introduced (there are other synchronized(session) for "local" instance).
However you hit a real point, the instance does not have to be stable, only
its equals/hashCode could be considered stable so guess the idea would be
to add to the session *manager* a getLock() method (don't think a RWLock is
needed there due to current usage) and use it instead of synchronized.
The lock eviction should get some kind of delay for its own eviction and
not be evicted directly with the session to work.
A trivial impl could be to use a Map<$sessionId, $lock> and add a default
delay of 0 when purely in memory and a few seconds when a remote manager is
used (this logic belonging to the manager).
That said it stays a workaround and a better protocol handling that in a
cluster can be a more robust (but more complex) solution so not sure which
compromise is the 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>
Le mer. 8 mars 2023 à 04:43, Han Li a écrit :
>
>
> > On Mar 8, 2023, at 07:29, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> >
> > All,
> >
> > Please see https://bz.apache.org/bugzilla/show_bug.cgi?id=66513 for
> reference.
> >
> > It appears that the synchronization used by the PersistentManager can
> cause problems when used with the PersistentValve and DataSource/JDBCStore.
> >
> > The problem is that PersistentManager assumes that the Session object
> can be used as a synchronization monitor to load/update the session in the
> Store. The DataSource/JDBCStore implementation uses an INSERT to create a
> new session, and a DELETE-then-INSERT to re-write the session data in the
> db.
> >
> > When two requests arrive simultaneously, thread scheduling can cause
> DELETE-then-DELETE-then-INSERT-then-INSERT which causes a duplicate PK
> violation.
> >
> > If the PersistentValve were not in use, the in-memory Session would be
> stable. PersistentValve re-loads the Session from the Store on ever
> request, rendering the PersistentManager's synchronized(session) attempt to
> protect things useless.
> >
> > I think a simple way to fix this might be to change:
> >
> > // PersistentManager.java:478~
> >if(session != null) {
> >synchronized(session){
> >session = super.findSession(session.getIdInternal());
> >if(session != null){
> > // To keep any external calling code from messing up
> the
> > // concurrency.
> > session.access();
> > session.endAccess();
> >}
> >}
> >}
> >
> > to this:
> >
> >if(session != null) {
> >sessionId = String.intern(sessionId);
> >synchronized(sessionId){
> >session = super.findSession(session.getIdInternal());
> >if(session != null){
> > // To keep any external calling code from messing up
> the
> > // concurrency.
> > session.access();
> > session.endAccess();
> >}
> >}
> >}
> >
> > This swaps the Session object for the sessionId as the synchronization
> monitor. We use String.intern to ensure that we always have the same exact
> object, even across sessions, request, etc.
> -1
>
> This method does seem very simple and solves this problem, but it’s not as
> good as you might think, see below:
> https://shipilev.net/jvm/anatomy-quarks/10-string-intern/ <
> https://shipilev.net/jvm/anatomy-quarks/10-string-intern/>
>
> So I don’t think it should be the preferred option.
>
> Han
>
> >
> > This is *a* way to solve this problem. There are other ways.
> >
> > Another way is also a TODO in the DataSourceRealm code which suggests
> using UPDATE for sessions that already exist. That is probably worth
> implementing, and it would fix this particular issue.
> >
> > Note that it is essentially impossible to prevent thread scheduling,
> requests to other members of the cluster, etc. to prevent data-loss from
> the session and this BZ isn't asking us to fix that. It's only asking that
> a single Tomcat node with PersistentValve enabled doesn't cause thee
> duplicate PK violations for some pretty basic usages.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
>
Re: Loom research
Hi all, Checked the tccl thing and VirtualThread accept to set their TCCL but default to the creation thread one so issue is really more on the caller so guess it is more about tomcat ensuring it is created at the right time and likely integrated with the standard context loader appropriately so only the pool to configure IMHO and tomcat could autoswitch to loom when available :). 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 lun. 27 févr. 2023 à 20:39, Romain Manni-Bucau a écrit : > > > Le lun. 27 févr. 2023 à 20:21, Mark Thomas a écrit : > >> On 27/02/2023 18:02, Romain Manni-Bucau wrote:> Le lun. 27 févr. 2023 à >> 18:38, Mark Thomas a écrit : >> > >> >> On 27/02/2023 17:09, Romain Manni-Bucau wrote: >> >>> Hi, >> >>> >> >>> AFAIK loom or a standard thread pool are exactly the same except when >> you >> >>> use loom you need to ensure you pass the contextual executor to use >> >>> (scheduler in the API IIRC) otherwise the Thread.startVirtualThread >> will >> >>> use the global JVM one (so you use 2 thread pools which is unintended >> in >> >>> general and for tomcat which is multi-webapp can be an issue in some >> >>> contexts). >> >>> So overall the main benefit is to enable to use the contextual thread >> >> pool >> >>> owner to execute any banalized task. >> >>> This is a great advantage and shouldnt touch other applications (which >> >>> stays in a thread pool executor) so it sounds hurtless to auto switch >> to >> >>> loom when possible. >> >>> >> >>> However it means you do not use LoomExecutor but a configured loom >> >> executor >> >>> (default works while only using loom friendly and not blocking code >> but >> >> as >> >>> soon as you will break that statement it will not work anymore). >> >>> Ideally it means using java/lang/ThreadBuilders(Executor) to >> configure it >> >>> and pass a standard executor to it. >> >>> >> >>> Hope it makes sense. >> >> >> >> Not really, no. There is no thread pool with Loom. >> >> >> > >> > There is an implicit default fork join pool, see >> > >> https://github.com/openjdk/loom/blob/e9f05191c306b2af9d91397f8a5bfffd948e6d69/src/java.base/share/classes/java/lang/VirtualThread.java#L1081 >> > . >> > It defaults to the number of proc. >> > Max is 256 and min number of proc/2. >> > Similarly there is a scheduled pool of 1 by default for background >> tasks. >> >> Oh. The carrier threads. That clarifies your meaning somewhat. There is >> a notable difference between that and the standard thread pool which was >> evident in the tests in the blog post. The blocking queue used for the >> work queue on the standard thread pool suffers from contention much more >> than Loom's work stealing queue. >> > > Well theorically it should converge at some point (speaking outside > continuation part which adds specific contentions and optimization) since > both are likely the same. > This is also why the perfs are not that different when the app using a > thread pool really does not block. > > >> >> Yes, putting virtual threads into a standard thread pool is pointless >> (and probably has a negative performance impact too). >> >> Tomcat has taken the simple approach for this for now: >> >> https://github.com/apache/tomcat/blob/main/modules/loom/src/main/java/org/apache/catalina/core/LoomExecutor.java > > > Means you don't control the tomcat thread pool used by virtual threads > which can be ok-ish when you deploy a single webapp in a tomcat owning the > JVM but miss some control when you want to allocate threads to usages > (executor per webapp is what I have in mind). > > >> >> >> Whether we'll need to worry about separate pools of carrier threads - or >> configuration of that pool / those pools - is TBD. >> > > ack > > >> >> I'm still not sure what you mean by "default works while only using loom >> friendly and not blocking code". >> > > Default stays a forkjoin pool, wh
Re: Loom research
Le lun. 27 févr. 2023 à 20:21, Mark Thomas a écrit : > On 27/02/2023 18:02, Romain Manni-Bucau wrote:> Le lun. 27 févr. 2023 à > 18:38, Mark Thomas a écrit : > > > >> On 27/02/2023 17:09, Romain Manni-Bucau wrote: > >>> Hi, > >>> > >>> AFAIK loom or a standard thread pool are exactly the same except when > you > >>> use loom you need to ensure you pass the contextual executor to use > >>> (scheduler in the API IIRC) otherwise the Thread.startVirtualThread > will > >>> use the global JVM one (so you use 2 thread pools which is unintended > in > >>> general and for tomcat which is multi-webapp can be an issue in some > >>> contexts). > >>> So overall the main benefit is to enable to use the contextual thread > >> pool > >>> owner to execute any banalized task. > >>> This is a great advantage and shouldnt touch other applications (which > >>> stays in a thread pool executor) so it sounds hurtless to auto switch > to > >>> loom when possible. > >>> > >>> However it means you do not use LoomExecutor but a configured loom > >> executor > >>> (default works while only using loom friendly and not blocking code but > >> as > >>> soon as you will break that statement it will not work anymore). > >>> Ideally it means using java/lang/ThreadBuilders(Executor) to configure > it > >>> and pass a standard executor to it. > >>> > >>> Hope it makes sense. > >> > >> Not really, no. There is no thread pool with Loom. > >> > > > > There is an implicit default fork join pool, see > > > https://github.com/openjdk/loom/blob/e9f05191c306b2af9d91397f8a5bfffd948e6d69/src/java.base/share/classes/java/lang/VirtualThread.java#L1081 > > . > > It defaults to the number of proc. > > Max is 256 and min number of proc/2. > > Similarly there is a scheduled pool of 1 by default for background tasks. > > Oh. The carrier threads. That clarifies your meaning somewhat. There is > a notable difference between that and the standard thread pool which was > evident in the tests in the blog post. The blocking queue used for the > work queue on the standard thread pool suffers from contention much more > than Loom's work stealing queue. > Well theorically it should converge at some point (speaking outside continuation part which adds specific contentions and optimization) since both are likely the same. This is also why the perfs are not that different when the app using a thread pool really does not block. > > Yes, putting virtual threads into a standard thread pool is pointless > (and probably has a negative performance impact too). > > Tomcat has taken the simple approach for this for now: > > https://github.com/apache/tomcat/blob/main/modules/loom/src/main/java/org/apache/catalina/core/LoomExecutor.java Means you don't control the tomcat thread pool used by virtual threads which can be ok-ish when you deploy a single webapp in a tomcat owning the JVM but miss some control when you want to allocate threads to usages (executor per webapp is what I have in mind). > > > Whether we'll need to worry about separate pools of carrier threads - or > configuration of that pool / those pools - is TBD. > ack > > I'm still not sure what you mean by "default works while only using loom > friendly and not blocking code". > Default stays a forkjoin pool, which works as of today without loom so switching the default to tomcat is fine but is not LoomExecutor but a slightly enhance flavor which controls the underlying scheduler as task scheduler (to not rely on system props but tomcat executor props). > > > > So using loom without caution is using a JVM (with its classloader side > > effect) thread pool which is enabled for JVM continuations, nothing more. > > What class loader effects? The context class loader should be picked up > from the virtual thread. > This part highly depends the code and deployment setup. Carrying thread has the JVM classloader as contextual one (a bit like common pool). Ultimately the continuation is what will define the context once submitted to the thread pool: https://github.com/openjdk/loom/blob/e9f05191c306b2af9d91397f8a5bfffd948e6d69/src/java.base/share/classes/java/lang/VirtualThread.java#L235 (which enters back in a standard thread pool land ;)). Reading the loom spec it is unclear to me if the context classloader can be controlled or not (I'm tempted to think not) so this can be an issue if the enclosing thread pool does not help and enable it in the context of tomcat. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Loom research
Le lun. 27 févr. 2023 à 18:38, Mark Thomas a écrit : > On 27/02/2023 17:09, Romain Manni-Bucau wrote: > > Hi, > > > > AFAIK loom or a standard thread pool are exactly the same except when you > > use loom you need to ensure you pass the contextual executor to use > > (scheduler in the API IIRC) otherwise the Thread.startVirtualThread will > > use the global JVM one (so you use 2 thread pools which is unintended in > > general and for tomcat which is multi-webapp can be an issue in some > > contexts). > > So overall the main benefit is to enable to use the contextual thread > pool > > owner to execute any banalized task. > > This is a great advantage and shouldnt touch other applications (which > > stays in a thread pool executor) so it sounds hurtless to auto switch to > > loom when possible. > > > > However it means you do not use LoomExecutor but a configured loom > executor > > (default works while only using loom friendly and not blocking code but > as > > soon as you will break that statement it will not work anymore). > > Ideally it means using java/lang/ThreadBuilders(Executor) to configure it > > and pass a standard executor to it. > > > > Hope it makes sense. > > Not really, no. There is no thread pool with Loom. > There is an implicit default fork join pool, see https://github.com/openjdk/loom/blob/e9f05191c306b2af9d91397f8a5bfffd948e6d69/src/java.base/share/classes/java/lang/VirtualThread.java#L1081 . It defaults to the number of proc. Max is 256 and min number of proc/2. Similarly there is a scheduled pool of 1 by default for background tasks. So using loom without caution is using a JVM (with its classloader side effect) thread pool which is enabled for JVM continuations, nothing more. > > Mark > > > > > > 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 lun. 27 févr. 2023 à 17:53, Mark Thomas a écrit : > > > >> FYI > >> > >> https://spring.io/blog/2023/02/27/web-applications-and-project-loom > >> > >> Written for $dayjob but the data is based purely on Tomcat and a trivial > >> web application. > >> > >> I think this could prove useful when we need discuss what to do with the > >> Loom module code. > >> > >> Mark > >> > >> - > >> 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: Loom research
Hi, AFAIK loom or a standard thread pool are exactly the same except when you use loom you need to ensure you pass the contextual executor to use (scheduler in the API IIRC) otherwise the Thread.startVirtualThread will use the global JVM one (so you use 2 thread pools which is unintended in general and for tomcat which is multi-webapp can be an issue in some contexts). So overall the main benefit is to enable to use the contextual thread pool owner to execute any banalized task. This is a great advantage and shouldnt touch other applications (which stays in a thread pool executor) so it sounds hurtless to auto switch to loom when possible. However it means you do not use LoomExecutor but a configured loom executor (default works while only using loom friendly and not blocking code but as soon as you will break that statement it will not work anymore). Ideally it means using java/lang/ThreadBuilders(Executor) to configure it and pass a standard executor to it. Hope it makes sense. 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 lun. 27 févr. 2023 à 17:53, Mark Thomas a écrit : > FYI > > https://spring.io/blog/2023/02/27/web-applications-and-project-loom > > Written for $dayjob but the data is based purely on Tomcat and a trivial > web application. > > I think this could prove useful when we need discuss what to do with the > Loom module code. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [tomcat] 02/02: LongAdder is a better choice for statistics collection
Le mar. 24 janv. 2023 à 14:48, Rémy Maucherat a écrit :
> On Tue, Jan 24, 2023 at 2:37 PM Romain Manni-Bucau
> wrote:
> >
> > here is the idea https://github.com/apache/tomcat/pull/576
>
> People care about stats these days and the performance benefit of
> disabling this is simply not going to be there.
>
Depends, I'd say a few will take these data from there, others will take
just grab them from other kind of instrumentation so having it on by
default is just an useless overhead and if AtomicInteger -> LongAdder perf
is significant then disabling it is close in terms of perf but also mem
(long adder perf gain is at the cost of the mem). Concretely most embedded
cases + graalvm cases generally don't care about these ones and I think
they represent quite a lot of users so even if I agree with your statement
it does not discard the PR IMHO.
>
> Rémy
>
> >
> > 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 mar. 24 janv. 2023 à 14:24, Mark Thomas a écrit :
> >
> > > Patches welcome if that is an itch someone wants to scratch.
> > >
> > > Mark
> > >
> > >
> > > On 24/01/2023 13:22, Romain Manni-Bucau wrote:
> > > > If you care about the (perf) diff, shouldnt tomcat have a config to
> be
> > > able
> > > > to disable stats overhead at all (using a Runnable or Counter
> {incr(),
> > > > get()} as abstraction is sufficient) when it is not used (most of the
> > > time
> > > > in dev+prod - ie not sizing/tuning phases)?
> > > >
> > > > 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 mar. 24 janv. 2023 à 14:19, Rémy Maucherat a
> écrit
> > > :
> > > >
> > > >> On Tue, Jan 24, 2023 at 1:26 PM wrote:
> > > >>>
> > > >>> This is an automated email from the ASF dual-hosted git repository.
> > > >>>
> > > >>> markt pushed a commit to branch 9.0.x
> > > >>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> > > >>>
> > > >>> commit a7bf4d84f753d69acb66f5e45f5bc767a1d55e49
> > > >>> Author: Mark Thomas
> > > >>> AuthorDate: Tue Jan 24 12:22:01 2023 +
> > > >>>
> > > >>> LongAdder is a better choice for statistics collection
> > > >>
> > > >> Never heard of that before, but I see it's already there in Java 8.
> > > >>
> > > >> Rémy
> > > >>
> > > >>> ---
> > > >>> java/org/apache/catalina/webresources/Cache.java | 17
> > > +
> > > >>> 1 file changed, 9 insertions(+), 8 deletions(-)
> > > >>>
> > > >>> diff --git a/java/org/apache/catalina/webresources/Cache.java
> > > >> b/java/org/apache/catalina/webresources/Cache.java
> > > >>> index 949117f521..4893a289cb 100644
> > > >>> --- a/java/org/apache/catalina/webresources/Cache.java
> > > >>> +++ b/java/org/apache/catalina/webresources/Cache.java
> > > >>> @@ -22,6 +22,7 @@ import java.util.TreeSet;
> > > >>> import java.util.concurrent.ConcurrentHashMap;
> > > >>> import java.util.concurrent.ConcurrentMap;
> > > >>> import java.util.concurrent.atomic.AtomicLong;
> > > >>> +import java.util.concurrent.atomic.LongAdder;
> > > >>>
> > > >>> import org.apache.catalina.WebResource;
> > > >>> import org.apache.catalina.WebResourceRoot.CacheStrategy;
> > > >>> @@ -48,8
Re: [tomcat] 02/02: LongAdder is a better choice for statistics collection
here is the idea https://github.com/apache/tomcat/pull/576
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 mar. 24 janv. 2023 à 14:24, Mark Thomas a écrit :
> Patches welcome if that is an itch someone wants to scratch.
>
> Mark
>
>
> On 24/01/2023 13:22, Romain Manni-Bucau wrote:
> > If you care about the (perf) diff, shouldnt tomcat have a config to be
> able
> > to disable stats overhead at all (using a Runnable or Counter {incr(),
> > get()} as abstraction is sufficient) when it is not used (most of the
> time
> > in dev+prod - ie not sizing/tuning phases)?
> >
> > 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 mar. 24 janv. 2023 à 14:19, Rémy Maucherat a écrit
> :
> >
> >> On Tue, Jan 24, 2023 at 1:26 PM wrote:
> >>>
> >>> This is an automated email from the ASF dual-hosted git repository.
> >>>
> >>> markt pushed a commit to branch 9.0.x
> >>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >>>
> >>> commit a7bf4d84f753d69acb66f5e45f5bc767a1d55e49
> >>> Author: Mark Thomas
> >>> AuthorDate: Tue Jan 24 12:22:01 2023 +
> >>>
> >>> LongAdder is a better choice for statistics collection
> >>
> >> Never heard of that before, but I see it's already there in Java 8.
> >>
> >> Rémy
> >>
> >>> ---
> >>> java/org/apache/catalina/webresources/Cache.java | 17
> +
> >>> 1 file changed, 9 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/java/org/apache/catalina/webresources/Cache.java
> >> b/java/org/apache/catalina/webresources/Cache.java
> >>> index 949117f521..4893a289cb 100644
> >>> --- a/java/org/apache/catalina/webresources/Cache.java
> >>> +++ b/java/org/apache/catalina/webresources/Cache.java
> >>> @@ -22,6 +22,7 @@ import java.util.TreeSet;
> >>> import java.util.concurrent.ConcurrentHashMap;
> >>> import java.util.concurrent.ConcurrentMap;
> >>> import java.util.concurrent.atomic.AtomicLong;
> >>> +import java.util.concurrent.atomic.LongAdder;
> >>>
> >>> import org.apache.catalina.WebResource;
> >>> import org.apache.catalina.WebResourceRoot.CacheStrategy;
> >>> @@ -48,8 +49,8 @@ public class Cache {
> >>> private int objectMaxSize = (int) maxSize /
> OBJECT_MAX_SIZE_FACTOR;
> >>> private CacheStrategy cacheStrategy;
> >>>
> >>> -private AtomicLong lookupCount = new AtomicLong(0);
> >>> -private AtomicLong hitCount = new AtomicLong(0);
> >>> +private LongAdder lookupCount = new LongAdder();
> >>> +private LongAdder hitCount = new LongAdder();
> >>>
> >>> private final ConcurrentMap
> resourceCache =
> >> new ConcurrentHashMap<>();
> >>>
> >>> @@ -70,7 +71,7 @@ public class Cache {
> >>> }
> >>> }
> >>>
> >>> -lookupCount.incrementAndGet();
> >>> +lookupCount.increment();
> >>>
> >>> CachedResource cacheEntry = resourceCache.get(path);
> >>>
> >>> @@ -138,14 +139,14 @@ public class Cache {
> >>> cacheEntry.validateResource(useClassLoaderResources);
> >>> }
> >>> } else {
> >>> -hitCount.incrementAndGet();
> >>> +hitCount.increment();
> >>> }
> >>>
> >>> return cacheEntry;
> >>> }
> >>>
> >>> protected WebResource[] getResources(String path, boolean
> >> useClassLoa
Re: [tomcat] 02/02: LongAdder is a better choice for statistics collection
If you care about the (perf) diff, shouldnt tomcat have a config to be able
to disable stats overhead at all (using a Runnable or Counter {incr(),
get()} as abstraction is sufficient) when it is not used (most of the time
in dev+prod - ie not sizing/tuning phases)?
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 mar. 24 janv. 2023 à 14:19, Rémy Maucherat a écrit :
> On Tue, Jan 24, 2023 at 1:26 PM wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > markt pushed a commit to branch 9.0.x
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> > commit a7bf4d84f753d69acb66f5e45f5bc767a1d55e49
> > Author: Mark Thomas
> > AuthorDate: Tue Jan 24 12:22:01 2023 +
> >
> > LongAdder is a better choice for statistics collection
>
> Never heard of that before, but I see it's already there in Java 8.
>
> Rémy
>
> > ---
> > java/org/apache/catalina/webresources/Cache.java | 17 +
> > 1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/java/org/apache/catalina/webresources/Cache.java
> b/java/org/apache/catalina/webresources/Cache.java
> > index 949117f521..4893a289cb 100644
> > --- a/java/org/apache/catalina/webresources/Cache.java
> > +++ b/java/org/apache/catalina/webresources/Cache.java
> > @@ -22,6 +22,7 @@ import java.util.TreeSet;
> > import java.util.concurrent.ConcurrentHashMap;
> > import java.util.concurrent.ConcurrentMap;
> > import java.util.concurrent.atomic.AtomicLong;
> > +import java.util.concurrent.atomic.LongAdder;
> >
> > import org.apache.catalina.WebResource;
> > import org.apache.catalina.WebResourceRoot.CacheStrategy;
> > @@ -48,8 +49,8 @@ public class Cache {
> > private int objectMaxSize = (int) maxSize / OBJECT_MAX_SIZE_FACTOR;
> > private CacheStrategy cacheStrategy;
> >
> > -private AtomicLong lookupCount = new AtomicLong(0);
> > -private AtomicLong hitCount = new AtomicLong(0);
> > +private LongAdder lookupCount = new LongAdder();
> > +private LongAdder hitCount = new LongAdder();
> >
> > private final ConcurrentMap resourceCache =
> new ConcurrentHashMap<>();
> >
> > @@ -70,7 +71,7 @@ public class Cache {
> > }
> > }
> >
> > -lookupCount.incrementAndGet();
> > +lookupCount.increment();
> >
> > CachedResource cacheEntry = resourceCache.get(path);
> >
> > @@ -138,14 +139,14 @@ public class Cache {
> > cacheEntry.validateResource(useClassLoaderResources);
> > }
> > } else {
> > -hitCount.incrementAndGet();
> > +hitCount.increment();
> > }
> >
> > return cacheEntry;
> > }
> >
> > protected WebResource[] getResources(String path, boolean
> useClassLoaderResources) {
> > -lookupCount.incrementAndGet();
> > +lookupCount.increment();
> >
> > // Don't call noCache(path) since the class loader only caches
> > // individual resources. Therefore, always cache collections
> here
> > @@ -196,7 +197,7 @@ public class Cache {
> > cacheEntry.validateResources(useClassLoaderResources);
> > }
> > } else {
> > -hitCount.incrementAndGet();
> > +hitCount.increment();
> > }
> >
> > return cacheEntry.getWebResources();
> > @@ -291,11 +292,11 @@ public class Cache {
> > }
> >
> > public long getLookupCount() {
> > -return lookupCount.get();
> > +return lookupCount.sum();
> > }
> >
> > public long getHitCount() {
> > -return hitCount.get();
> > +return hitCount.sum();
> > }
> >
> > public void setObjectMaxSize(int objectMaxSize) {
> >
> >
> > -
> > 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: Tomcat 11 - minimum Java version
Guess it was more about default java for linux distro, build is only reproducible if target --release flag is <= java distro version which will not be the case for java 21 soon enough probably, not really a build issue by itself more an ecosystem one - distro consumming sources. Le mer. 11 janv. 2023 à 21:41, Mark Thomas a écrit : > On 11/01/2023 20:15, Michael Osipov wrote: > > Even if not, there is another problem with that: When you build with > > Java 17, that build cannot be reproduced on Java 11 or 8 because class > > file content will be different. > > Experience in the Tomcat project says otherwise. > > We can already reproduce builds across platforms. The current Tomcat > builds are reproducible across Windows and Linux (and I suspect MacOS > although I haven't tested that recently). > > We also know the only blocker to cross-Java version builds is the > MANIFEST.MF content. The class files are identical. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Tomcat 11 - minimum Java version
Side question from an user standpoint: does it mean tomcat 11 must not be used today too since it will abruptally switch its baseline (potentially against the app baseline)? Isnt it against the 11 releases idea? Thinking out loud and understanding jakarta decision is likely "weird"/inconsistent but not toncat responsability but think the point is valid for tomcat community which was happy to get early accesses AFAIK (at least i was in that camp). Le mer. 11 janv. 2023 à 17:01, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Mark, > > On 1/11/23 06:23, Mark Thomas wrote: > > The Jakarta EE platform group has announced that the minimum Java > > version for Jakarta EE 11 will be Java 21. [1] > > > > Given that the Java SecurityManager was deprecated in Java 17 and > > planned for removal I intend to remove all references to the > > SecurityManager from the Tomcat 11 code base. I plan to do this shortly. > > +0 > > This will complicate back-ports, but I suppose we must do it sometime. > > > We would normally make Java 21 the minimum Java version. Given that Java > > 21 is still in EA, I don't plan to do that yet. > > > > We could switch all branches to Java 17 as the the default build JRE now > > as that supports targeting Java 7 onwards. That would allow us to easily > > use some newer Java features in Tomcat 11 whilst still only requiring > > RMs to use a single JDK version. If there are no objections I'll do this > > shortly. > > Sure. > > > Java 21 supports targeting Java 8 onwards which means we won't be able > > to switch to that when available for all branches unless Tomcat 8.5.x > > has already reached EOL. > > > > The target date for Jakarta EE 11 is Q1 2024. Given that there are no > > Java 21 features we want to use in Tomcat 11 right now I suggest we wait > > until we need to build Tomcat 11 with Java 21 to decide what to do. > > Worst case, we'll need to build most branches with Java 21 and 8.5.x > > with Java 17 until 8.5.x reaches EOL (31 March 2024). > > On 1/11/23 08:00, Mark Thomas wrote: > > At the moment, I see the drivers for Java 21 as: > > - use new APIs (applications can do this even if the minimum version > >supported is lower) > > - non-preview versions of Panama and Loom (if available) > > I agree with Tim: If Jakarta EE 11 "requires" Java 21 (even if there are > no binary reasons why that is the case), then I think it's appropriate > to use that for builds and an API baseline. If we got a complaint from a > user that their application running on Tomcat 11 was failing due to some > weirdness in the application that was obviously caused by running it on > Java 11 or whatever, we'd first tell them that they must be using Java > 21, per spec. There is no reason to support Tomcat 11 in a pre-Java-21 > environment, so let's go ahead and use Java 21 for the whole process. > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Tomcat 11 - minimum Java version
Hi, As an user we are adopting Tomcat 11 (even if still "on the edge") with Java 17 (in particular for some lib/stacks) and the more reactive servlet 6.1 is very interesting so hope it can be made Java 17 compliant until technically blocked. 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. 11 janv. 2023 à 12:44, Mark Thomas a écrit : > On 11/01/2023 11:38, Rémy Maucherat wrote: > > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas wrote: > > > > >> The target date for Jakarta EE 11 is Q1 2024. Given that there are no > >> Java 21 features we want to use in Tomcat 11 right now I suggest we wait > >> until we need to build Tomcat 11 with Java 21 to decide what to do. > >> Worst case, we'll need to build most branches with Java 21 and 8.5.x > >> with Java 17 until 8.5.x reaches EOL (31 March 2024). > > > > If Java 21 is the baseline, I would like to propose to drop > > tomcat-native from Tomcat 11 and replace it with Panama. This is of > > course assuming Panama is non preview in 21, and this also needs to > > wait for some time (probably until June). > > Just playing devils advocate for a second, is Java 21 going to be too > big a leap for the majority of users? Might the Tomcat community be > better with Java 17 as the minimum version for Tomcat 11? > > Personally, I am in favour of Java 21 for Tomcat 11. There is always > Tomcat 10.1x for those that don't want to / can't move to Java 21. But I > did at least want to ask the question in case my views are in the minority. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Any graalvm diet planned?
Hi all,
It is quite easy to make tomcat running with graalvm these days even
without any tooling (it is mainly about enabling one reflection point [1]
and a few bundles [2]) however the outcoming binary is quite fat compared
to what I expected (~40M).
Checking with graalvm dashboard (-H:DashboardDump=g.dump -H:+DashboardAll)
I realized it is mainly about constants - the code itself is about 18M,
heap 23M).
One surprising thing is that the heap references
mbeanserver.ClassLoaderRepository even disabling JMX - probably because
even when disabled classes still references it.
So I wonder if there is any plan for Tomcat 11 to make it more modular and
enable to reduce all that to try to get back to a ~15M binary (for a hello
world servlet so only tomcat).
Guess it can only target Nio connector, drop JMX from the main codepath
(make it a plugin) and probably drop some start-only constant from the
constant pool.
I'm not sure the best way to do that for the project but think it can
benefit native-image users a lot and even java consumers since at the end
the project can be lighter to integrate in embedded mode since most of the
XML stuff is less and less set up.
[1] [{"name" : "org.apache.coyote.AbstractProtocol", "allPublicMethods" :
true}]
[2] {
"resources": {
"includes": [
{"pattern": ".+\\/LocalStrings\\.properties"},
{"pattern":
"org\\/apache\\/catalina\\/core\\/RestrictedServlets\\.properties"},
{"pattern":
"org\\/apache\\/catalina\\/core\\/RestrictedFilters\\.properties"},
{"pattern":
"org\\/apache\\/catalina\\/core\\/RestrictedListeners\\.properties"},
{"pattern": "org\\/apache\\/catalina\\/util\\/ServerInfo\\.properties"}
]
}
}
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>
Re: Extended access log valve merged with AbstractAccessLogValve?
Basically it seems a few "accessor" (access log element) are only in extended flavor and not the abstract one, for example servletContext.getAttribute accessor. The issue is then that abstract access log valve was created to enable to extend and forward the access log to anything else than the built-in file writer (a custom logger for ex). Now, with these differences you don't get this abstraction and either need to reimplement the pattern parsing or override a lot of the extended valve since it is quite bound to the writer (open for ex). So I'm looking to unify both worlds if possible. I don't see a big negative effect to support tomcat extensions in the abstract impl so I'm proposing it as an option. 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 lun. 12 déc. 2022 à 11:25, Mark Thomas a écrit : > Can you expand on what problem you are trying to solve that you can't > solve with the current code? > > Mark > > > On 12/12/2022 09:51, Romain Manni-Bucau wrote: > > Hi all, > > > > Wonder if there is any reason to not push supported element of > > ExtendedAccessLogValve in the abstract log valve. > > Rational would be to leverage "extensions" in a custom log sink impl > (protected > > abstract void log(CharArrayWriter message);). > > > > Wdyt? > > Let me know if you are interested and I need to do a PR, would be more > than > > happy to help if relevant. > > > > 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 > >
Extended access log valve merged with AbstractAccessLogValve?
Hi all, Wonder if there is any reason to not push supported element of ExtendedAccessLogValve in the abstract log valve. Rational would be to leverage "extensions" in a custom log sink impl (protected abstract void log(CharArrayWriter message);). Wdyt? Let me know if you are interested and I need to do a PR, would be more than happy to help if relevant. 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>
Re: [VOTE] Release Apache Tomcat 11.0.0-M1
[X] Stable (non binding) tested on a few downstream projects (like Yupiik Uship or Apache OpenWebBeans Meecrowave - based on 10.x as of today) and detected no issue. 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 ven. 2 déc. 2022 à 13:01, Han Li a écrit : > > > > On Dec 1, 2022, at 19:58, Mark Thomas wrote: > > > > The proposed Apache Tomcat 11.0.0-M1 release is now available for > > voting. > > > > Apache Tomcat 11.0.0-M1 is the first milestone release of the 11.0.x > > branch and has been made to provide users with early access to the new > > features in Apache Tomcat 11.0.x so that they may provide feedback. The > > notable changes compared to 10.1.x include: > > > > - Alignment with the current development versions of the Jakarta > > Servlet, Pages and Expression Language specifications. This includes > > removal of deprecated code and addition of the > > jakarta.servlet.error.query_string attribute for error dispatches > > > > - BASIC authentication now uses UTF-8 by default > > > > - Conversions from bytes to characters now trigger exceptions rather > > than replacement for invalid byte sequences for the given encoding > > > > For full details, see the change log: > > https://nightlies.apache.org/tomcat/tomcat-11.0.x/docs/changelog.html > > > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 11 > without changes. Java EE applications designed for Tomcat 9 and earlier may > be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will > automatically convert them to Jakarta EE and copy them to the webapps > directory. Applications using deprecated APIs may require further changes. > > > > It can be obtained from: > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M1/ > > > > The Maven staging repo is: > > https://repository.apache.org/content/repositories/orgapachetomcat-1408 > > > > The tag is: > > https://github.com/apache/tomcat/tree/11.0.0-M1 > > 59c81e30e2f64f5e8c1db78c4860c51850dfb0bd > > > > The proposed 11.0.0-M1 release is: > > [ ] Broken - do not release > > [X ] Stable - go ahead and release as 11.0.0-M1 > > Tests pass. > > Han > > > > - > > 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: CDI and injection issues
Le jeu. 24 nov. 2022 à 16:58, Rémy Maucherat a écrit :
> On Thu, Nov 24, 2022 at 10:19 AM Romain Manni-Bucau
> wrote:
> >
> > Le jeu. 24 nov. 2022 à 10:13, Rémy Maucherat a écrit :
> >
> > > On Wed, Nov 23, 2022 at 11:10 AM Romain Manni-Bucau
> > > wrote:
> > > >
> > > > Well, it is not that simple.
> > > >
> > > > Two notes on that:
> > > >
> > > > 1. One point is the API, injector and instance manager are the exact
> same
> > > > API if you want a generic API so not sure it should be duplicated
> with
> > > > different names (or said otherwise the Injector API is not generic
> enough
> > > > to be worth a tomcat "core" change IMHO)
> > >
> > > This is indeed the same API.
> > > Tomcat standalone handles Jakarta Annotations here:
> > >
> > >
> https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/core/DefaultInstanceManager.java#L174
> > > The owb integration is supposed to do the CDI annotations on the same
> > > spot. AFAIK, it works. Except that the PostConstruct will be done
> > > later.
> > > I don't want to duplicate DefaultInstanceManager since there are a lot
> > > of privileged actions and code in there. So adding the callback on
> > > line 174 does seem fine to me.
> > >
> > > > 2. the post construct is a conflict between tomcat world and cdi
> world
> > > > there but you have the same "conflict" (= concurrent world/handling)
> for
> > > > injections, i.e. tomcat handles persistence context, persistence
> unit,
> > > > webservice ref etc but CDI can also handle it so the injector is
> either
> > > > incomplete in one case (cdi without these handling) and should be
> > > combined
> > > > between tomcat and injector OR it is done twice, potentially
> differently.
> > > >
> > > > So at the end it looks like you don't have the choice to just own the
> > > > instance manager to ensure it is done properly so making it easier to
> > > > instantiate is likely the way to go but adding an abstraction which
> is
> > > not
> > > > generic is maybe not helping as much as it can look like upfront.
> > > >
> > > > Side note: meecrowave does a more cdi instantiation:
> > > >
> > >
> https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/CDIInstanceManager.java
> > > > and it is very few lines so not sure the injector would help much
> more
> > > for
> > > > a tomcat-cdi integration.
> > >
> > > Sure, but the problem is that I have to keep DefaultInstanceManager
> > > around, and I won't replace everything with a CDI implementation.
> > >
> >
> > Well, in the owb module you will have to - previous impl is more about
> > letting cdi handling the postconstruct but lack the JNDI support to be
> > complete - to solve the double/conflict injection point anyway. The
> > *Injector* API does not solve it so not sure there is much space for this
> > invalid by design API :s. Did you find a way to solve it?
>
> I don't understand everything in this area.
> I tried a Servlet with a @PostConstruct. Tomcat's
> DefaultInstanceManager invokes that method.
> If OWB is active through the listener on that webapp, and processes
> that Servlet instance for injection (there's nothing to inject of
> course), then it does not invoke that @PostConstruct. Why is that ?
> Does it only do it on beans where it actually did some injection ?
>
If you speak of the tomcat/module impl it is because it uses owb.inject
only and not the unmanaged API (or injectiontarget which is equivalent).
The issues start when you have such a bean (whatever component it is, a
servlet, filter, listener):
public class FooComponent ... {
@Inject MyBean service;
@Resource DataSource dataSource; // from web.xml for ex
@Resource(lookup = "entries/conf)" String conf; // from context.xml for
ex
@PostConstruct void onInit() {}
@PreDestroy void onDestroy() {}
}
Here you want:
1. newInstance somehow
2.a. inject cdi instances
2.b. inject tomcat instances
3. postconstruct
4. predestroy
5. release creation context if relevant (not normal scoped bean mainly)
2.a and b only work if you have 2 injectors (or chain the injections in
instance manager since it is equivalent) but the trick is that OWB can
handle tomcat injections - it has API/plugins for part of that - or tomcat
can handle OWB in
Re: CDI and injection issues
Le jeu. 24 nov. 2022 à 10:13, Rémy Maucherat a écrit : > On Wed, Nov 23, 2022 at 11:10 AM Romain Manni-Bucau > wrote: > > > > Well, it is not that simple. > > > > Two notes on that: > > > > 1. One point is the API, injector and instance manager are the exact same > > API if you want a generic API so not sure it should be duplicated with > > different names (or said otherwise the Injector API is not generic enough > > to be worth a tomcat "core" change IMHO) > > This is indeed the same API. > Tomcat standalone handles Jakarta Annotations here: > > https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/core/DefaultInstanceManager.java#L174 > The owb integration is supposed to do the CDI annotations on the same > spot. AFAIK, it works. Except that the PostConstruct will be done > later. > I don't want to duplicate DefaultInstanceManager since there are a lot > of privileged actions and code in there. So adding the callback on > line 174 does seem fine to me. > > > 2. the post construct is a conflict between tomcat world and cdi world > > there but you have the same "conflict" (= concurrent world/handling) for > > injections, i.e. tomcat handles persistence context, persistence unit, > > webservice ref etc but CDI can also handle it so the injector is either > > incomplete in one case (cdi without these handling) and should be > combined > > between tomcat and injector OR it is done twice, potentially differently. > > > > So at the end it looks like you don't have the choice to just own the > > instance manager to ensure it is done properly so making it easier to > > instantiate is likely the way to go but adding an abstraction which is > not > > generic is maybe not helping as much as it can look like upfront. > > > > Side note: meecrowave does a more cdi instantiation: > > > https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/CDIInstanceManager.java > > and it is very few lines so not sure the injector would help much more > for > > a tomcat-cdi integration. > > Sure, but the problem is that I have to keep DefaultInstanceManager > around, and I won't replace everything with a CDI implementation. > Well, in the owb module you will have to - previous impl is more about letting cdi handling the postconstruct but lack the JNDI support to be complete - to solve the double/conflict injection point anyway. The *Injector* API does not solve it so not sure there is much space for this invalid by design API :s. Did you find a way to solve it? > > Rémy > > > > > 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. 23 nov. 2022 à 10:56, Rémy Maucherat a écrit : > > > > > On Tue, Nov 22, 2022 at 6:08 PM Romain Manni-Bucau > > > wrote: > > > > > > > > Hmm, how is your injector different from an InstanceManager? ( > > > > > > > > https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/InstanceManager.java > > > > ) > > > > Only by not having all `newInstance` flavors? > > > > > > The plan is to keep on using DefaultInstanceManager since OWB only > > > needs a callback for injection (before PostConstruct) and destroy (to > > > remove the instance from the map). Otherwise the whole InstanceManager > > > has to be replaced (and done better than the current one since the > > > PostConstruct calls cannot be in the right order otherwise). > > > > > > > Will also need the backgroundProcess (cache cleanup, same as instance > > > > manager) and similarly the calling context (new instance params), in > > > > particular the classloader. > > > > This is why I said it sounds more like a single API and more hooking > the > > > > default instance to enable what you want or just redo it is likely > > > simpler > > > > _on an API standpoint_. > > > > Guess postConstruct() method as in TomEE impl - but using tomcat in > place > > > > method, just exposing it - can be sufficient and keep the API clean > if > > > you > > > > don't want to reimpl anything. &
Re: CDI and injection issues
Well, it is not that simple. Two notes on that: 1. One point is the API, injector and instance manager are the exact same API if you want a generic API so not sure it should be duplicated with different names (or said otherwise the Injector API is not generic enough to be worth a tomcat "core" change IMHO) 2. the post construct is a conflict between tomcat world and cdi world there but you have the same "conflict" (= concurrent world/handling) for injections, i.e. tomcat handles persistence context, persistence unit, webservice ref etc but CDI can also handle it so the injector is either incomplete in one case (cdi without these handling) and should be combined between tomcat and injector OR it is done twice, potentially differently. So at the end it looks like you don't have the choice to just own the instance manager to ensure it is done properly so making it easier to instantiate is likely the way to go but adding an abstraction which is not generic is maybe not helping as much as it can look like upfront. Side note: meecrowave does a more cdi instantiation: https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/CDIInstanceManager.java and it is very few lines so not sure the injector would help much more for a tomcat-cdi integration. 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. 23 nov. 2022 à 10:56, Rémy Maucherat a écrit : > On Tue, Nov 22, 2022 at 6:08 PM Romain Manni-Bucau > wrote: > > > > Hmm, how is your injector different from an InstanceManager? ( > > > https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/InstanceManager.java > > ) > > Only by not having all `newInstance` flavors? > > The plan is to keep on using DefaultInstanceManager since OWB only > needs a callback for injection (before PostConstruct) and destroy (to > remove the instance from the map). Otherwise the whole InstanceManager > has to be replaced (and done better than the current one since the > PostConstruct calls cannot be in the right order otherwise). > > > Will also need the backgroundProcess (cache cleanup, same as instance > > manager) and similarly the calling context (new instance params), in > > particular the classloader. > > This is why I said it sounds more like a single API and more hooking the > > default instance to enable what you want or just redo it is likely > simpler > > _on an API standpoint_. > > Guess postConstruct() method as in TomEE impl - but using tomcat in place > > method, just exposing it - can be sufficient and keep the API clean if > you > > don't want to reimpl anything. > > This is only a callback for injection with DefaultInstanceManager. > Implementing your own InstanceManager in TomEE is still needed and > since it is not using DefaultInstanceManager this callback API is not > available at all. Also it will not break existing InstanceManager > implementations (even ones that extend DefaultInstanceManager), so > that's another thing I had to consider. > > The user who got me into this is here: > https://lists.apache.org/thread/1g4bpj3jnmmmxkh37qvwzoplqo65ldot > This is about Weld, but after having a look the > OpenWebBeansInstanceManager does the same thing. Then I realized > unless the InstanceManager was fully replaced there would be no way to > implement the proper ordering. > > > About JSP hack, it is more general but hits mainly JSP: it is about > tomcat > > specific JNDI injections, the workaround and wiring used elsewhere for > > beans didn't work properly for JSP. Guess you don't have this issue but > > something making it easier to handle can also probably be welcomed by > > consumers. > > Ok. > > Rémy > > > > > > > Le mar. 22 nov. 2022 à 17:26, Rémy Maucherat a écrit : > > > > > On Tue, Nov 22, 2022 at 4:30 PM Romain Manni-Bucau > > > wrote: > > > > > > > > Hi Rémy, > > > > > > > > I put a few comments inline hoping it helps > > > > > > > > > > > > Le mar. 22 nov. 2022 à 16:11, Rémy Maucherat a > écrit : > > > > > > > > > Hi, > > > > > > > > > > Following a post on the user list, I have looked into CDI and > > > > > injection processing in Tomcat standalone (or standalone extended > by > >
Re: CDI and injection issues
Hmm, how is your injector different from an InstanceManager? (
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/InstanceManager.java
)
Only by not having all `newInstance` flavors?
Will also need the backgroundProcess (cache cleanup, same as instance
manager) and similarly the calling context (new instance params), in
particular the classloader.
This is why I said it sounds more like a single API and more hooking the
default instance to enable what you want or just redo it is likely simpler
_on an API standpoint_.
Guess postConstruct() method as in TomEE impl - but using tomcat in place
method, just exposing it - can be sufficient and keep the API clean if you
don't want to reimpl anything.
About JSP hack, it is more general but hits mainly JSP: it is about tomcat
specific JNDI injections, the workaround and wiring used elsewhere for
beans didn't work properly for JSP. Guess you don't have this issue but
something making it easier to handle can also probably be welcomed by
consumers.
Le mar. 22 nov. 2022 à 17:26, Rémy Maucherat a écrit :
> On Tue, Nov 22, 2022 at 4:30 PM Romain Manni-Bucau
> wrote:
> >
> > Hi Rémy,
> >
> > I put a few comments inline hoping it helps
> >
> >
> > Le mar. 22 nov. 2022 à 16:11, Rémy Maucherat a écrit :
> >
> > > Hi,
> > >
> > > Following a post on the user list, I have looked into CDI and
> > > injection processing in Tomcat standalone (or standalone extended by
> > > CDI) and found the following issues:
> > >
> > > a) metadata-complete is done wrong. The spec got retconned some time
> > > ago and metadata-complete only means Servlet spec defining metadata,
> > > such as @WebServlet (= the ones that require scanning all classes just
> > > in case). So in practice inside DefaultInstanceManager the
> > > ignoreAnnotations flag shouldn't be used at all and it should simply
> > > be removed. I am ok on only doing this in 11 ;)
> > >
> > > b) CDI is not intertwined with the DefaultInstanceManager. Basically
> > > as the user said, injections should be done *before* @PostConstruct,
> > > and it . There's a (minor) problem with the DefaultInstanceManager
> > > API, a method needs to be protected and then integrations will then be
> > > able to hack inside the DefaultInstanceManager. You can see this here
> > > in the OWB integration:
> > >
> > >
> https://github.com/apache/tomcat/blob/main/modules/owb/src/main/java/org/apache/webbeans/web/tomcat/OpenWebBeansInstanceManager.java#L102
> > > (basically, first call newInstance, because there's no other way, then
> > > inject, but newInstance will have already invoked @PostConstruct). To
> > > fix this, I plan to add an Injector interface to
> > > DefaultInstanceManager since this is pretty much the only way to do
> > > this cleanly in Tomcat standalone (taking over the whole
> > > DefaultInstanceManager is clearly not the best idea).
> > >
> >
> > Yeah, TomEE ([1]) had some hard time with JSP due to that and its
> > re-implementation of the instantiation.
> > Basically the idea was to implement it aside Tomcat default impl but for
> > some classes it was not convenient enough.
> > That said I have to admit I'm not sure it needs a new concept (injector)
> > because basically it will copy the instance manager API (inject, release
> or
> > something like that since it is not only about the inject phase so either
> > you define the lifecycle or you store a Runnable you call at release time
> > too - isnt the abstraction too complex then?).
>
> For EE or some other similar embedded, the assumption was that
> InstanceManager would be fully reimplemented. But this is more work
> for a lighter weight integration, ok.
>
> The change to add the API to DefaultInstanceManager would be:
> --- a/java/org/apache/catalina/core/DefaultInstanceManager.java
> +++ b/java/org/apache/catalina/core/DefaultInstanceManager.java
> @@ -109,6 +109,7 @@ public class DefaultInstanceManager implements
> InstanceManager {
> new ManagedConcurrentWeakHashMap<>();
> private final Map postConstructMethods;
> private final Map preDestroyMethods;
> +private Injector injector = null;
>
> public DefaultInstanceManager(Context context,
> Map> injectionMap,
> @@ -172,6 +173,9 @@ public class DefaultInstanceManager implements
> InstanceManager {
> Map injections =
> assembleInjectionsFromClassHierarchy(clazz);
> populateAnnotationsCache(clazz, injections);
> processAnnot
Re: CDI and injection issues
Hi Rémy, I put a few comments inline hoping it helps Le mar. 22 nov. 2022 à 16:11, Rémy Maucherat a écrit : > Hi, > > Following a post on the user list, I have looked into CDI and > injection processing in Tomcat standalone (or standalone extended by > CDI) and found the following issues: > > a) metadata-complete is done wrong. The spec got retconned some time > ago and metadata-complete only means Servlet spec defining metadata, > such as @WebServlet (= the ones that require scanning all classes just > in case). So in practice inside DefaultInstanceManager the > ignoreAnnotations flag shouldn't be used at all and it should simply > be removed. I am ok on only doing this in 11 ;) > > b) CDI is not intertwined with the DefaultInstanceManager. Basically > as the user said, injections should be done *before* @PostConstruct, > and it . There's a (minor) problem with the DefaultInstanceManager > API, a method needs to be protected and then integrations will then be > able to hack inside the DefaultInstanceManager. You can see this here > in the OWB integration: > > https://github.com/apache/tomcat/blob/main/modules/owb/src/main/java/org/apache/webbeans/web/tomcat/OpenWebBeansInstanceManager.java#L102 > (basically, first call newInstance, because there's no other way, then > inject, but newInstance will have already invoked @PostConstruct). To > fix this, I plan to add an Injector interface to > DefaultInstanceManager since this is pretty much the only way to do > this cleanly in Tomcat standalone (taking over the whole > DefaultInstanceManager is clearly not the best idea). > Yeah, TomEE ([1]) had some hard time with JSP due to that and its re-implementation of the instantiation. Basically the idea was to implement it aside Tomcat default impl but for some classes it was not convenient enough. That said I have to admit I'm not sure it needs a new concept (injector) because basically it will copy the instance manager API (inject, release or something like that since it is not only about the inject phase so either you define the lifecycle or you store a Runnable you call at release time too - isnt the abstraction too complex then?). Another issue there is that newInstance assumes a "new" which means you can not use a CDI instance generally speaking, only a banalised instance which gets injections so it means you can just impl yourself a newInstance+whatever you want+postconstruct call (this is light actually). This is where setting ignoreAnnotations would be quite fancy in your own instance manager and wouldnt need any new API. That said, enabling to use a CDI instance would be way more powerful and is not against the spec - it is actually not specified AFAIK. Indeed it would need a toggle on the OWBIM of Tomcat integration but it would also open way more doors in terms of usage because your servlet (filter, ...) is now a CDI beans with a connection to its bus and interceptors. I know it can already be done by using a container initializer which gets beans injected and the instances directly passed to the addServlet() (instead of the class) but it would also be a very valuable addition to the module if the instantiation is reworked so I'm just mentionning it as an opportunity. [1] https://github.com/apache/tomee/blob/main/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/JavaeeInstanceManager.java > > The impact of fixing these for users should be non-existent: it is > really a Tomcat standalone only thing impacting users with some very > precise EE needs. A full EE integration will simply take over the > whole annotation processing and instance manager from Tomcat, and > hopefully do The Right Thing already. > > Although this is not super critical, I plan to address these issues in > the OWB integration (after adding the needed API change in Tomcat's > DefaultInstanceManager). > > Comments ? > > Rémy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Security manager support
Hi, If it helps, commons weaver ( https://commons.apache.org/proper/commons-weaver/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/index.html) can help for the backport part (enable or not the run in build.xml). Romain Le dim. 2 oct. 2022 à 06:42, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Emmanuel, > > On 9/28/22 11:05, Emmanuel Bourg wrote: > > The security manager has been deprecated for removal in Java 17 [1], and > > at some point Tomcat will have to stop supporting it. > > > > Do we want to wait until it's no longer available in the JDK to remove > > it from Tomcat, or should we remove it earlier, maybe in Tomcat 10.1 or > 11? > > > > I tend to think there are better solutions at the OS level to isolate a > > Tomcat instance nowadays, and I lean toward dropping it before its > > removal from the JDK. > > > > What do you think? > > My only concern is that it may cause some headaches for anything we want > to back-port. > > Mark has a separate thread about Loom and there will obviously be some > significant changes and incompatibilities introduced by that as well. > Doing them together makes sense to me. > > But the SM code permeates all of Tomcat where the Loom stuff is likely > to be much more isolated. I think it will have farther-reaching impacts. > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: jakarta.el, useless getResource?
Hi Chris, My x10 dropping it was on java 17. Romain Le ven. 26 août 2022 à 02:39, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Mark, > > On 8/22/22 07:54, Mark Thomas wrote: > > On 22/08/2022 11:48, Mark Thomas wrote: > >> On 22/08/2022 10:20, Romain Manni-Bucau wrote: > > > > > > > >>> So overall I wonder if this check can be dropped now we have concurrent > >>> classloaders and cache almost everywhere. If not, should the missed > >>> items > >>> be cached in some (webapp) classloader to help to exit faster? > >> > >> We need to test with various JDKs but if the results are comparable to > >> those for Java 11, I'd have no objection to simplifying the code. > > > > I've just run the performance test with Java 7, Java 8 and Java 11 with > > 8.5.x and in all three cases, the average time to run the test was less > > without the performance fix than with it. > > > > Given these, results, I think we remove this performance hack for all > > current versions. > > > > Objections? > > I would run under Java 17 just to make sure that whatever optimizations > were done in Java 11 are still there. I suspect there will be no change > in behavior, but as we have seen over the last 20 years, sometimes > things do change wrt performance. > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: jakarta.el, useless getResource?
Hi Went ahead and created https://github.com/apache/tomcat/pull/547 (if it helps) 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 lun. 22 août 2022 à 14:25, Romain Manni-Bucau a écrit : > +1 > > To answer the proxy reference: it affects other cases - loading classes > from a "database", proxies is just a well known case I used to illustrate > my point. By contract a classloader is not always an URLClassLoader which > is the assumption of the impl right now. Also CDS changes the perf there > too - a lot when enabled. > > Side note: graalvm integration is way easier without that check ;). > > 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 lun. 22 août 2022 à 13:54, Mark Thomas a écrit : > >> On 22/08/2022 11:48, Mark Thomas wrote: >> > On 22/08/2022 10:20, Romain Manni-Bucau wrote: >> >> >> >> >> So overall I wonder if this check can be dropped now we have concurrent >> >> classloaders and cache almost everywhere. If not, should the missed >> items >> >> be cached in some (webapp) classloader to help to exit faster? >> > >> > We need to test with various JDKs but if the results are comparable to >> > those for Java 11, I'd have no objection to simplifying the code. >> >> I've just run the performance test with Java 7, Java 8 and Java 11 with >> 8.5.x and in all three cases, the average time to run the test was less >> without the performance fix than with it. >> >> Given these, results, I think we remove this performance hack for all >> current versions. >> >> Objections? >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >>
Re: jakarta.el, useless getResource?
+1 To answer the proxy reference: it affects other cases - loading classes from a "database", proxies is just a well known case I used to illustrate my point. By contract a classloader is not always an URLClassLoader which is the assumption of the impl right now. Also CDS changes the perf there too - a lot when enabled. Side note: graalvm integration is way easier without that check ;). 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 lun. 22 août 2022 à 13:54, Mark Thomas a écrit : > On 22/08/2022 11:48, Mark Thomas wrote: > > On 22/08/2022 10:20, Romain Manni-Bucau wrote: > > > > >> So overall I wonder if this check can be dropped now we have concurrent > >> classloaders and cache almost everywhere. If not, should the missed > items > >> be cached in some (webapp) classloader to help to exit faster? > > > > We need to test with various JDKs but if the results are comparable to > > those for Java 11, I'd have no objection to simplifying the code. > > I've just run the performance test with Java 7, Java 8 and Java 11 with > 8.5.x and in all three cases, the average time to run the test was less > without the performance fix than with it. > > Given these, results, I think we remove this performance hack for all > current versions. > > Objections? > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
jakarta.el, useless getResource?
Hi all, I just spotted that in jakarta.el.ImportHandler#findClass there is a cl.getResource(path) == null (similar code exists when there is a security manager). One line later there is a clazz = cl.loadClass(name);. I assume the intent is to check the class is physically accessible but I have a few questions about that: 1. It seems it does not respect the classloader API since this one enables by contract to define a class (loadclass) without having a resource - it is often used by proxies for ex, 2. getResource is insanely slow (dropping it by using a subclass which overrides ImportHandler by reflection I got a x10 ops/s on a 4 lines template with one import) 3. Why would getResource fail but loadClass succeed - I ignore any configuration error which is "fixable"? >From the comment on top of the getResource check it seems it is for performances (getresource being cheaper than loadClass) but I wonder if it is still accurate (from my window it depends on the classpath size plus loadClass will mainly go through getResource). So overall I wonder if this check can be dropped now we have concurrent classloaders and cache almost everywhere. If not, should the missed items be cached in some (webapp) classloader to help to exit faster? 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>
Re: Tomcat embed packaging clarification
Le ven. 20 mai 2022 à 12:10, Mark Thomas a écrit : > On 20/05/2022 10:36, Romain Manni-Bucau wrote: > > Hi all, > > > > Checking a project with multiple tomcat integrators (spring boot, uship, > > meecrowave, tomee, ...) I realised Tomcat ecosystem is quite exploded > with > > tomcat-embed packaging but I kind of fail to see the benefit from there > > since using plain tomcat artifacts works well > > Not sure I understand your concern. There are a handful of extra JARs in > the embedded namespace that provide an alternative packaging. > > There was a specific user request for the embedded packaging. They > wanted fewer, larger JARs. > > It costs us very little to maintain those JARs. > Where I can envision to make it easy to use as a fatjar or something like that, here embed packaging is kind of duplicating tomcat packaging and I fail to see any benefit. > > > plus embed is still marked as > > experimental in the build descriptors. > > That is an easy fix. > not yet, see next ;) > > > From my window it would be great to deprecate embed jar usage, > potentially > > make some gap converging with default packaging, and focus on the main > > packaging only and maybe drop embed one for the final 10.1 but not sure I > > missed something critical. > > Why? What is the benefit of removing that packaging? > What does happen when you have tomcat + tomcat-embed in your classpath because your libraries decided embed was better than default or the opposite? Luckily it can work but it can also just fail and identifying it is not always trivial for everyone. Guess if default distro not full fatjar don't work well enough it can be a need to integrate in main distribution, this is why I think it should converge at some point. That said, relocating embedded artifacts using org.apache.tomcat.embed would mitigate the issue too and be okish for me too. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Tomcat embed packaging clarification
Hi all, Checking a project with multiple tomcat integrators (spring boot, uship, meecrowave, tomee, ...) I realised Tomcat ecosystem is quite exploded with tomcat-embed packaging but I kind of fail to see the benefit from there since using plain tomcat artifacts works well plus embed is still marked as experimental in the build descriptors. >From my window it would be great to deprecate embed jar usage, potentially make some gap converging with default packaging, and focus on the main packaging only and maybe drop embed one for the final 10.1 but not sure I missed something critical. 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>
Re: Tomcat mitigations for CVE-2022-21449
Hi Openj9 is not affected I think so version wouldnt be enough, jvm name should be tested too. Le sam. 30 avr. 2022 à 00:18, Mark Thomas a écrit : > On 29/04/2022 19:41, Christopher Schultz wrote: > > > > > 1. The underlying JVM is affected > > 2. A Connector is defined with uses mutual TLS > > 3. The client's key is ECDSA > > > > > I was thinking that on startup, we could check for a vulnerable > > environment and simply refuse to start the server. > > > > If there are no objections, I was thinking of putting this into the > > SecurityListener. I assume that all the necessary information is > > available to a LifecycleListener such as being able to enumerate the > > Connectors to check on items #2 and #3 above? > > My understanding is that a CA with an RSA key can sign a client cert > with an ECDSA key. In that scenario, if the Tomcat system has been > configured with just the CA's trusted cert (a likely scenario since you > don't want to have to updated the trusted certs every time you add a > user) then test #3 won't work. > > I'm wondering if we want to introduce a Java version equivalent of the > checks we have for Tomcat Native version. i.e. for each major Java > version, have a minimum required version where Tomcat won't start if > used and a recommended version where Tomcat starts with a warning. > > One of the arguments against adding checks like these is that they only > work if folks update Tomcat. If folks are updating Tomcat regularly then > they are likely updating the JRE too. So I wonder what the return on the > investment is. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: ULRStreamHandlerFactory proposal
Hi all
It is a very valid point, since tomcat started to use this API it got
worked around in all integrations (bypassed to disable war: url handling
basically).
I never fully got why tomcat integrated at that level since in standalone
mode it owns the deployment so it does not need at all AFAIK so anything
making it optional would be a +1 from me.
That said I would avoid a shared lib which will create new issues and
conflicts quite easily so I would probably encourage to implement the war:
support different (likely testing the protocol only? should be sufficient
in tomcat land).
Anyway +1 to encourage Oracle to make the JVM support nicer and plural but
I'm not sure it will happen tomorrow so there are still rooms to enhance
tomcat "integrability" way before IMHO.
Hope it makes sense.
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 jeu. 17 févr. 2022 à 10:57, Rémy Maucherat a écrit :
> On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
> wrote:
> >
> > Hello all,
> >
> > There has been a long standing limitation in the JDK w.r.t. the handling
> of
> > URLStreamHandlerFactory. Beyond Java 17 this API becomes even more locked
> > down making dynamic use cases or coordination among frameworks next to
> > impossible. It appears unlikely to ever be resolved in the JDK.
> >
> > The OSGi community shares a desire [1] (with others in the wider Java
> > community) to address this. We were thinking this might happen in a way
> > that Tomcat may benefit from, since it appears to also have the same
> issue
> > [2].
> >
> > Here is the idea.
> >
> > We thought that a library could become the de facto implementation which,
> > by acting as the primordial URLStreamHandlerFactory (which directly
> > integrates with the JVM), provides the dynamism necessary for any number
> of
> > downstream consumers are able to orchestrate a set of protocol handlers
> > without clobbering everyone else or worse failing outright in those
> > scenarios where someone else beat you to the punch.
> >
> > How might this be accomplished? Tom Watson from IBM suggested that by
> > providing a protocol of it's own which one could obtain by doing
> something
> > like `new URL("ushfm:").openConnection()` returning an instance which is
> > castable (or used reflectively) to a management-like interface.
> >
> > We imagined that such a library could potentially replace the current
> > implementation in tomcat, or at least help it to accomplish its goals.
> This
> > would enable scenarios where OSGi is embedded in a WAR (my company for
> > instance), or where tomcat is embedded (and that env already has said
> > library deployed) or any combination of those. Of course there is room
> here
> > for all fallbacks to kick in. If the "lookup" fails, then obviously there
> > is no such implementation present and you keep doing what you were doing.
> >
> > Ideally such a library would live in an open source project where there
> is
> > credibility for a wide audience, such as Apache.
> >
> > Thoughts?
>
> It should be fixed by the Java platform. How hard is it to add
> URL.setURLStreamHandlerFactory(String protocol,
> URLStreamHandlerFactory fac) ? I think the problem is that nobody was
> really asking, so Oracle did nothing. Given the amount of improvements
> and additions to the platform since the stagnation of Java 8, why
> would they still refuse it ? They've even been rewriting NIO !
>
> Also, and more importantly, you can very very easily use
> TomcatURLStreamHandlerFactory.addUserFactory (doing it through
> reflection if needed) as all currently supported Tomcat versions have
> this API. You're already integrating Tomcat using some integration
> code, so your integration code should be using this.
>
> Rémy
>
> > Ray
> >
> > [1] https://github.com/osgi/osgi/issues/226
> > [2]
> >
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/webresources/TomcatURLStreamHandlerFactory.java
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: Reproducible builds update
Hi Mark, It is possible to use jdk.javadoc/jdk.compiler as libs and plug in through the Context class forcing a JavaFileManager to force a DocFileFactory in the HtmlConfiguration but it will be way more complex than unzipping/rezipping the jar. Another option can be a light javaagent patching the few classes you want. Also wonder if you tried -notimestamp option. 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 mar. 18 janv. 2022 à 23:34, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Mark, > > On 1/18/22 15:03, Mark Thomas wrote: > > On 18/01/2022 19:39, Mark Thomas wrote: > > > > > > > >> The first issue looks relatively simple to fix. I don't see an easy > >> fix for the second. My best idea so far is some sort of > >> post-processing for the Javadoc generation that extracts the file from > >> the zip, sets the timestamp and then re-zips it. Suggestions for a > >> better solution welcome. > > > > Yep, I think I fixed the first issue. > > > > I'm wondering about second issue. It would be nice to have a complete > > fix but if the full docs package isn't reproducible how much of an issue > > is that? > > I'm -0 on any efforts to make the javadoc builds reproducible. They > aren't exactly binary artifacts and anyone performing an audit isn't > going to treat documentation as in-scope anyways (at least not at this > point). > > Does javadoc (or ant's javadoc task) not support explicit timestamps to > use (like javac does)? I haven't looked-into how javadoc (the CLI tool) > does things lately, but I wasn't aware it produced ZIP files. Is that > javadoc itself, or is that some ant post-processing step? If it's ant, > can't we just run on all those files before zipping them? > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Enable to "json stringify" access logs
Le jeu. 23 déc. 2021 à 22:53, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
> Romain,
>
> On 12/18/21 14:28, Romain Manni-Bucau wrote:
> > I wonder if you would be interested in an access log "function" enabling
> to
> > make an access log element a valid json string.
> >
> > Idea is to enable to have access logs patterns producing valid JSON
> > whatever the dynamic string content, maybe something like
> >
> > "key":"jsonEscaped(%r)",
> >
> > or more tomcat style:
> >
> > "key":"%{json}r)",
>
> If you tried that today, you'd get the value of the request attribute
> named "json". I think we need a different syntax.
>
> The closest thing to this I see in the current configuration is
> specifying the date-format of a timestamp like this:
>
> %{pattern}t where %{...}t gets you the end-of-request timestamp.
>
> I think it's going to be ugly no matter what we do.
>
> Maybe instead of putting the escaping in the pattern, we could put the
> type of escaping into another attribute like this:
>
> ...
> escaping="json"
> pattern="..." />
>
> Then, when any %{...}? replacement will be done, it can be JSON-escaped.
This has a perf drawback (several %{} dont need it) I'd like to avoid if
possible and some %x would need escaping so fear it is not precise enough,
no?
> Any literal text in the pattern itself is up to the admin; specifically,
> it will not have any escaping applied to the pattern text, only the
> replacements.
>
> > What do you think? Is it worth proposing something or is it always
> handled
> > differently in your opinion (I tend to workaround it today so not 100%
> sure
> > it would be accepted if I do a PR)?
>
> Actually, this could easily be done by subclassing AccessLogValve and
> overriding AbstractAccessLogValve.escapeAndAppend to provide the proper
> escaping.
>
> I'd be +1 on accepting a JSONAccessLogValve class.
>
Let me try to PoC it after Xmas, sounds like a good option avoiding the
identification issue of enhancing current valve.
Thanks Chris
> -chris
>
> > Another location which would benefit from some json encoding
> > is org.apache.catalina.valves.JsonErrorReportValve#report since currently
> > it produces invalid json depending the message value.
> >
> > 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
> >
> >
>
Enable to "json stringify" access logs
Hi all,
I wonder if you would be interested in an access log "function" enabling to
make an access log element a valid json string.
Idea is to enable to have access logs patterns producing valid JSON
whatever the dynamic string content, maybe something like
"key":"jsonEscaped(%r)",
or more tomcat style:
"key":"%{json}r)",
What do you think? Is it worth proposing something or is it always handled
differently in your opinion (I tend to workaround it today so not 100% sure
it would be accepted if I do a PR)?
Another location which would benefit from some json encoding
is org.apache.catalina.valves.JsonErrorReportValve#report since currently
it produces invalid json depending the message value.
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>
Re: default context path
Hi, We got a similar issue @johnzon and we went with option d) which was to create a very minimalistic SPI enabling users to get compliance by adding a jar in the classpath (common.lib for tomcat). Guess it can be an option enabling any hack (and likely move STRICT_SERVLET_COMPLIANCE there which would enable servers like tomee to be compliant with a system prop instead of additional hacks but still aligned on tomcat behavior by default). So overall, even if it is not limited to this particular issue, idea could be to move the compliance hacks in a dedicated SPI and jar. Hope it makes sense. 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 jeu. 25 nov. 2021 à 23:18, Mark Thomas a écrit : > Hi all, > > I am working on updating the Servlet TCK for Servlet 6 and I have been > discussing with the Jakarta Servlet community whether or not we could > disable the TCK test that checks default-context-path support. > > Tomcat doesn't implement this feature as the container is allowed to > override this default and we always do - primarily to avoid a bunch of > edge cases. > > Other containers do implement the feature and the preference looks to be > keeping the TCK test enabled. > > If we want to fully pass the TCK, one option is to hard-code the > deployer to deploy the specific TCK WAR to the correct path if > STRICT_SERVLET_COMPLIANCE was enabled. This is a fairly ugly hack but it > would enable Tomcat to fully pass the TCK. > > What do we think? > a) Do we want to fully pass the TCK? Is a hack along the lines I > described an acceptable way to do this? > b) Do we do nothing now and keep this as an option if we get to the > point where we do want to fully pass the TCK and certify compliance? > c) Do we make a formal challenge of the TCK test on the grounds the > little documentation there is says the container can override this > default so the test is invalid on the basis it doesn't allow for the > override? > > Assuming the Servlet team decides to keep the test, I am leaning towards > b) or maybe a) > > Thoughts? > > The last time we discussed this: > https://tomcat.markmail.org/thread/4g7nb36fzf4byrej > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Drop module-info from tomcat*.jar?
Le mer. 15 sept. 2021 à 13:13, Mark Thomas a écrit : > On 15/09/2021 11:07, Romain Manni-Bucau wrote: > > I think the last option is maybe the target: modularize tomcat properly. > > "Properly" is a highly subjective judgement. There are going to be > wildly differing views on what constitutes a "proper" degree of modularity. > Ok, "properly" regarding the dependency graph, ie no reflection done nor code relying on an optional dependency (all that replaced by a SPI or alike). > > > The people willing to have as few as possible modules would just use a > new > > "bundle" module (this is what we do at openjpa, tomee, meecrowave etc) > > which provides a bundle way of building apps but is not flexible. > > So regarding JPMS I think it is either being really modular or not being > > modular since the in between state leads to unsatisfied people and the > > biggest constraints come from JPMS. > > Is it something targettable or do you think it is too much work? > > Don't know until we try. > > My instinct is that making more modules optional and then logging > warnings if users try to use Tomcat features that depend on a missing > optional module is doable - but I haven't done any analysis to back that > up. > > I don't have a sense of how many more modules like SSI could be > realistically created. > > Broadly, embedded is going to be the "bundle" module (well, modules) and > if folks want a finer-grained selection then they can use the JARs from > the standard distribution. > To be honest I never understood why the org.apache.tomcat.embed artifacts, they are generally the same as org.apache.tomcat ones and embedded server works very well with org.apache.tomcat artifacts so can be good to drop embed groupId and replace it by an all in one? Still thinking out loud indeed but current modularisation is surprising for consumers ;). > > Mark > > > > > > side note: fine for me if it targets only 10.1. > > > > 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. 15 sept. 2021 à 11:17, Mark Thomas a écrit : > > > >> On 15/09/2021 08:34, Romain Manni-Bucau wrote: > >>> Hi all, > >>> > >>> I was trying to strim down a JDK, all was smooth until I started to > work > >>> with Tomcat. > >> > >> I am assuming this is with embedded. > >> > >>> The issues I hit: > >>> > >>> - Tomcat is designed to be fully used with JPMS whereas I would like to > >> be > >>> able to use it in the CP if a jlink custom distro (without > >> forking/patching > >>> tomcat jar indeed) > >>> - module-info use "requires" and no optional dependent modules which > lead > >>> to way too much dependencies (open the module-info from tomcat-catalina > >> for > >>> ex) > >>> > >>> Indeed there are always workaround and way to achieve what I wanted > but I > >>> think the JPMS deliveries of Tomat are not friendly so think it is > worth > >>> thinking about: > >>> > >>> 1. dropping it > >> > >> Not an option as we have users that have requested it. > >> > >>> 2. making it optional (I assume it can be released in jars with > >> classifiers > >>> only) > >> > >> Maybe, but it adds a bunch of artefacts. > >> > >>> 3. making it more accurate - but this highly depends how the user > >> consumes > >>> it (in particular for tomcat embed flavor) > >> > >> I think a variation of this is the way to go. > >> > >> Looking at the list of dependencies, I suspect most of them can be made > >> optional. That involves fine-tuning the bnd configuration files. > >> > >> That does raise the question what we do when a user tries to use the > >> optional features. I think we need to: > >> - identify those Tomcat features that depend on optional modules > >> - add a check for the presence of the module before using the feature > >> and log an appropriate error message if the module is missing. > >> > >> Splitting embedded into lots of little modules where all the > >> dependencies are correctly declared is another solution but we have > >> users that have requested we provide Tomcat in as few JARs as possible. > >> > >> I think we are approaching "can't please all of the people, all of the > >> time" territory here. > >> > >> Mark > >> > >> - > >> 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: Drop module-info from tomcat*.jar?
I think the last option is maybe the target: modularize tomcat properly. The people willing to have as few as possible modules would just use a new "bundle" module (this is what we do at openjpa, tomee, meecrowave etc) which provides a bundle way of building apps but is not flexible. So regarding JPMS I think it is either being really modular or not being modular since the in between state leads to unsatisfied people and the biggest constraints come from JPMS. Is it something targettable or do you think it is too much work? side note: fine for me if it targets only 10.1. 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. 15 sept. 2021 à 11:17, Mark Thomas a écrit : > On 15/09/2021 08:34, Romain Manni-Bucau wrote: > > Hi all, > > > > I was trying to strim down a JDK, all was smooth until I started to work > > with Tomcat. > > I am assuming this is with embedded. > > > The issues I hit: > > > > - Tomcat is designed to be fully used with JPMS whereas I would like to > be > > able to use it in the CP if a jlink custom distro (without > forking/patching > > tomcat jar indeed) > > - module-info use "requires" and no optional dependent modules which lead > > to way too much dependencies (open the module-info from tomcat-catalina > for > > ex) > > > > Indeed there are always workaround and way to achieve what I wanted but I > > think the JPMS deliveries of Tomat are not friendly so think it is worth > > thinking about: > > > > 1. dropping it > > Not an option as we have users that have requested it. > > > 2. making it optional (I assume it can be released in jars with > classifiers > > only) > > Maybe, but it adds a bunch of artefacts. > > > 3. making it more accurate - but this highly depends how the user > consumes > > it (in particular for tomcat embed flavor) > > I think a variation of this is the way to go. > > Looking at the list of dependencies, I suspect most of them can be made > optional. That involves fine-tuning the bnd configuration files. > > That does raise the question what we do when a user tries to use the > optional features. I think we need to: > - identify those Tomcat features that depend on optional modules > - add a check for the presence of the module before using the feature >and log an appropriate error message if the module is missing. > > Splitting embedded into lots of little modules where all the > dependencies are correctly declared is another solution but we have > users that have requested we provide Tomcat in as few JARs as possible. > > I think we are approaching "can't please all of the people, all of the > time" territory here. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Drop module-info from tomcat*.jar?
Hi all, I was trying to strim down a JDK, all was smooth until I started to work with Tomcat. The issues I hit: - Tomcat is designed to be fully used with JPMS whereas I would like to be able to use it in the CP if a jlink custom distro (without forking/patching tomcat jar indeed) - module-info use "requires" and no optional dependent modules which lead to way too much dependencies (open the module-info from tomcat-catalina for ex) Indeed there are always workaround and way to achieve what I wanted but I think the JPMS deliveries of Tomat are not friendly so think it is worth thinking about: 1. dropping it 2. making it optional (I assume it can be released in jars with classifiers only) 3. making it more accurate - but this highly depends how the user consumes it (in particular for tomcat embed flavor) Personally I tend to priviledge 1 cause 3 makes it hard to do right but happy with other solutions not requiring to fork. 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>
Re: Graal now supports JMX?
Le jeu. 8 juil. 2021 à 15:36, Rémy Maucherat a écrit : > On Thu, Jul 8, 2021 at 1:21 PM Romain Manni-Bucau > wrote: > > > > Hi Mark, > > > > My understanding of the issue is that the isGraal test is not sufficient > > and should be precised to be isGraalNative (just using the naming to > > express the idea). > > Graal is a plain JVM and this does not need any hack but when > native-image > > is used it needs all current hacks so guess the test is not precise > enough > > but that the disabling should stay by default for native-image. > > This is more complex since the "Graal native" mode must also be > enabled when using the agent, and that's basically what the flag does. > If running Graal without the agent, then the isGraal flag returns > false. The "org.graalvm.nativeimage.imagecode" system property > override might get in the way however since the Spring code hacks it. > The check could be refined there maybe. > Well it is only true when tomcats itself uses the agent to generate the json config files so guess the CLI arg or any other config works as well there. (for end users you still have to tune a tons of things after so not sure it is that used and should be considered for that issue) > > Rémy > > > > > 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 jeu. 8 juil. 2021 à 13:01, Mark Thomas a écrit : > > > > > Hi, > > > > > > I got pinged on this issue yesterday: > > > > > > > https://github.com/spring-projects-experimental/spring-native/issues/805#issuecomment-875335648 > > > > > > That reads to me as if Graal now supports the use of JMX. If that is > the > > > case I think we can remove this code: > > > > > > > > > > https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/modeler/Registry.java#L139 > > > > > > and go back to the standard --no-jmx or calling > > > Registry.disableRegistry() for those users that don't want JMX support. > > > > > > Thoughts? > > > > > > I plan to make this change early next week if there are no objections. > > > > > > Mark > > > > > > - > > > 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: Graal now supports JMX?
Hi Mark, My understanding of the issue is that the isGraal test is not sufficient and should be precised to be isGraalNative (just using the naming to express the idea). Graal is a plain JVM and this does not need any hack but when native-image is used it needs all current hacks so guess the test is not precise enough but that the disabling should stay by default for native-image. 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 jeu. 8 juil. 2021 à 13:01, Mark Thomas a écrit : > Hi, > > I got pinged on this issue yesterday: > > https://github.com/spring-projects-experimental/spring-native/issues/805#issuecomment-875335648 > > That reads to me as if Graal now supports the use of JMX. If that is the > case I think we can remove this code: > > > https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/modeler/Registry.java#L139 > > and go back to the standard --no-jmx or calling > Registry.disableRegistry() for those users that don't want JMX support. > > Thoughts? > > I plan to make this change early next week if there are no objections. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Time to create Tomcat 10.1.x and master->main migration
+1 to move forward even if jakarta is not yet adopted (there is a single time direction - at least at our scale ;)) -0 to break all clones and related toolings/automotion for hypothetical reasons, didn't pay in all projects which did AFAIK 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 mar. 18 mai 2021 à 14:13, Emmanuel Bourg a écrit : > Le 2021-05-18 14:10, Emmanuel Bourg a écrit : > > >> Comments? > > > > I don't think the 7.0.x branch should be removed, there is no harm > > keeping it. > > > > As for the master->main change I think that's a waste of time for all > > of us. i don't buy the argument that "master" is offensive, but by > > moving awa > > Grr message sent too quickly, sorry. > > I don't want to reopen the debate, please ignore my comment. > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 10.0.6
+1, new instance manager usage for websocket layer works perfectly! 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 lun. 10 mai 2021 à 03:36, Igal Sapir a écrit : > On Sat, May 8, 2021 at 9:18 AM Mark Thomas wrote: > > > The proposed Apache Tomcat 10.0.6 release is now available for > > voting. > > > > > > > > The proposed 10.0.6 release is: > > [ ] Broken - do not release > > [X] Stable - go ahead and release as 10.0.6 (stable) > > > > +1 > > Igal > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
server.json?
Hi all, I noticed KubernetesMembershipProvider implied the addition of a JSONParser in tomcat codebase and wonder if there is some plan to support a server.json (server.xml but in json format). Since tomcat server.xml does not really use namespaces i guess it can be rewritten wiring the parser to a string output and applying the Digester on an in memory xml or so (point is it does not look crazy as bridge). The rational behind that is that JSON is always well supported in all languages but not XML and config files are rarely generated from java (where XML is a no brainer) but more from ruby, python and more recently typescript where XML is not so lovely to use so think JSON can help automotion there. Wdyt? 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>
Re: Implementing web.xml default-context-path
Le mer. 5 mai 2021 à 11:19, Mark Thomas a écrit : > On 05/05/2021 09:58, Rémy Maucherat wrote: > > On Sun, May 2, 2021 at 3:17 PM Jean-Louis MONTEIRO > > wrote: > > > >> Hi, > >> > >> Still working on getting TomEE certified for Jakarta EE 9.1 > >> We are using latest Tomcat 10.x and we indeed see now only one failure > as > >> described here > >> > >> https://cwiki.apache.org/confluence/display/TOMCAT/Servlet+TCK+5.0 > >> > >> I understand this is not really a critical thing to be certified for > >> Tomcat. > >> And I also understand this is not something the community agrees on. > >> > >> But I'd like, for the sake of getting TomEE certified, to pass this test > >> and therefore I'm looking at a way to patch it on our side. > >> > >> Would you be able to help in giving pointers on how to do it? > >> > >> Any help is appreciated at this point. > >> > > > > We already talked about this (bad) "feature" quite a bit in the past. > > Unless there's a big surprise: > > - This needs intrusive and annoying change to the deployer > > - The benefit to actual users seems to be zero > > - The feature is optional > > As a result, I doubt Mark will change his mind [I am not enthusiastic > > either] and I still don't understand how it is a mandatory TCK test. > > +1 allowing this feature opens up a huge mess of deployment edge cases > that the Tomcat deployment process was designed very carefully to avoid. > > > So ... I think you can come up with a hack instead: a Catalina listener > > could be added to the Context, then it could configure the rewrite valve > to > > do the url mapping. It should be enough to make this work. > > Another option would be to challenge the TCK test on the grounds the > spec allows containers to override any default-context-path setting but > the TCK assumes this isn't going to happen (in Tomcat it will always > happen). > +1 to challenge this test, if there is a consensus it is wrong no point to keep it year after year IMHO. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.0
+1, xml fix is helping 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 mar. 4 mai 2021 à 14:52, Rémy Maucherat a écrit : > On Tue, May 4, 2021 at 2:06 PM Mark Thomas wrote: > > > The proposed Apache Tomcat migration tool for Jakarta EE 1.0.0 is now > > available for voting. > > > > The significant changes since 0.2.0 are: > > > > - Further fixes to exclude javax.xml packages that are not part of > >Java EE from the migration > > > > - The class transformer now validates that the target classes in the > >Jakarta namespace exist in the runtime environment > > > > > > It can be obtained from: > > > https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v1.0.0/ > > > > The Maven staging repo is: > > https://repository.apache.org/content/repositories/orgapachetomcat-1308/ > > > > The tag is: > > https://github.com/apache/tomcat-jakartaee-migration/tree/1.0.0 > > 2a27b633f456710dc5d51680344ca7f047642a60 > > > > The proposed 1.0.0 release is: > > > > [ ] -1: Broken. Do not release because... > > [X] +1: Acceptable. Go ahead and release. > > > > Rémy >
Re: mod_headers as a Filter
Isnt the response buffer size giving a sufficient hint or callback like (dont rewrite before it is reached or body starts to be read)? Guess filter must force some size if not set but sounds like something to check, no? Le mar. 27 avr. 2021 à 21:32, Raymond Augé a écrit : > Couldn't you add a callback/hook to commit() impl and trigger the rules > during that callback/hook? > > But with that the filter is merely a shell for pushing rules into that > callback/hook registry. > > - Ray > > On Tue, Apr 27, 2021 at 1:04 PM Mark Thomas wrote: > > > Hi all, > > > > I've started to look at this and I am struggling to see a way to > > implement something that looks like mod_headers as a Filter. > > > > Request headers are fairly simple. The process looks something like: > > a) take a copy of all the headers received > > b) apply all the rules for request headers > > c) wrap the request, overriding the various getHeader... methods and > > return values appropriate for the modified set of headers > > > > Response headers are where I am currently stuck. > > A similar model to request headers might look like: > > a) wrap the response > > b) intercept all the headers set by the application > > c) apply all the rules for response headers > > d) call the appropriate setHeader... methods on the wrapped response > > for the modified set of headers > > > > The problem is that d) (and hence c) needs to be done immediately before > > the response is committed and - short of buffering the entire response > > body - there is no way to know when that is going to happen. > > > > Is the answer we need to buffer the entire response body? > > > > Any cunning ideas on how to detect (in a Filter or wrapped response) > > that the response is about to be committed? > > > > I guess we could try and track bytes (about to be) written and compare > > that to the known buffer size. That seems a little fragile on first > > impression. > > > > Another option is to abandon the mod_headers clone aim and do something > > simpler along the lines of blocking applications from setting specific > > headers and/or header/value combinations. > > > > Thoughts? > > > > Mark > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > -- > *Raymond Augé* (@rotty3000) > Senior Software Architect *Liferay, Inc.* (@Liferay) > OSGi Fellow >
Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x
Thinking out loud: can't it become a jaspic jaas impl delivered on central (this point is crucial), can be tomcat-jaas or so but not bundled by default in the distribution? Jaspic enables to do from the app so it becomes an option it seems which enables the use case so limit a lot the required "glue" to compensate a drop or is it still "too much" to maintain in your opinion? 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 lun. 26 avr. 2021 à 21:46, Jean-Louis MONTEIRO a écrit : > Le lun. 26 avr. 2021 à 20:48, Mark Thomas a écrit : > > > On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote: > > > JAAS, JASPIC and Jakarta Security are all different. > > > > My mistake. I knew JASPIC had a slightly bigger rename than most specs > > and incorrectly thought it became Jakarta Security. It actually became > > Jakarta Authentication. All previous references from me in this thread > > to "Jakarta Security" should be read as "Jakarta Authentication". > > > > No problem. > > > > > > > Tomcat does not implement Jakarta Security so removing JAAS creates a > gap > > > in my opinion. > > > > > > I'd second Romain, JASPIC requires a SAM to be implemented by the > > > application. > > > > > > Long story short, I'd probably deprecate for 10.x and target a removal > > for > > > 11.x > > > > In the normal course of things 10.1 would have been 11.0 but we are > > taking the opportunity align Jakarta EE major version and Tomcat major > > version as well as have a (much) shorter support lifespan for 10.0 > > (Jakarta EE 9) as that is seen as a transitional release. > > > > Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10. > > > > Sorry I missed that information. > So it appeared to be a bit too aggressive to deprecate and remove. > > > > > > Mark > > > > > > > Le lun. 26 avr. 2021 à 18:17, Mark Thomas a écrit : > > > > > >> In reviewing references to Java EE (and J2EE) remaining in the Tomcat > 10 > > >> repo I found the following: > > >> > > >> > > >> JAASRealm is prototype for Tomcat of the JAAS-based J2EE > authentication > > >> framework for J2EE v1.4, based on the > >> href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification > > >> Request 196 to enhance container-managed security and promote > > >> 'pluggable' authentication mechanisms whose implementations would be > > >> container-independent. > > >> > > >> > > >> JSR became JASPIC (now Jakarta Security) and Tomcat has an > > implementation. > > >> > > >> Searching through the mailing lists I found the following references > to > > >> usage of the JAASRealm (going back ~5 years). > > >> > > >> [1] Tomcat 7 user using JAAS based auth to an LDAP server > > >> [2] Tomcat 9 user using SPNEGO with the JAAS realm > > >> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm > > >> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm > > >> [5] User wanting access to HttpServletRequest during auth > > >> > > >> Most, if not all, of those have better solutions available than the > JAAS > > >> Realm. And those wanting some form of custom auth do have the "proper" > > >> Jakarta Security API to work with. > > >> > > >> Therefore, I'm not currently seeing a good reason to keep the > JAASRealm. > > >> Any objections to immediate deprecation with removal planned for > 10.1.x? > > >> > > >> Mark > > >> > > >> > > >> [1] http://markmail.org/message/ndvr5ilxovoo4ins > > >> [2] http://markmail.org/message/5ocdnmqvvlvjsxas > > >> [3] http://markmail.org/message/wki275i5yhlg3yyo > > >> [4] http://markmail.org/message/av2sv6g4kgm6ouu4 > > >> [5] http://markmail.org/message/fm4ggo3ge4r47gar > > >> > > >> - > > >> 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 > > > > > > -- > Jean-Louis >
Re: Websocket server configurator as @ServiceProvider: a bug?
What about the system property container orders (.priority or so)? Le lun. 26 avr. 2021 à 20:31, Mark Thomas a écrit : > Ah. That is a general problem with the ServiceLoader mechanism. It is > good for situations where you have one, unknown implementation. If there > are multiple implementations there is no mechanism for the user to > express a preference - short of hacking the class loader to ensure the > "right" one is found first. > > Generally, I don't like the idea of hard-coding assumptions regarding > priority. Whether those assumptions put Tomcat's implementation first or > last. > > As you point out, with Java 9+ a solution that allows a Comparator to be > provided to the ContainerProvider that would sort the ServiceLoader > results would be possible. But that will need API changes. I created: > > https://github.com/eclipse-ee4j/websocket-api/issues/365 > > Meanwhile what to do for Tomcat 10 and earlier? > > What if we added a static method to o.a.t.w.WsContainerProvider that > caused getContainer() to return null rather than an instance. That would > essentially hide the Tomcat implementation from the ServiceLoader > mechanism but not block its use as a default. > > Expanding on that slightly, a static getter and setter for > disableGetContainer would - assuming you control when the ServiceLoader > mechanism is invoked- allow disabling/enabling of the Tomcat > implementation on a case by case basis. > > Thoughts? > > Mark > > > > On 22/04/2021 18:48, Romain Manni-Bucau wrote: > > It is not wrong per se but it is not usable to plug a custom impl which > is > > my issue. > > > > > > @Mark: what about ignoring the default if there is another impl in > > serviceloader iteration? Would fix it even if it would create some > useless > > stuff but recent serviceloader api solves it if we want to avoid it (with > > Provider support). If not, the alternative is to make the spi > registration > > in another jar usable when not relying on tomcat-ws-api. Both options > work > > too even if first one would be simpler probably. > > > > Le jeu. 22 avr. 2021 à 18:29, Raymond Augé .invalid> > > a écrit : > > > >> Romain are you saying that having a service descriptor in this case is > >> wrong? > >> > >> On Thu., Apr. 22, 2021, 11:47 a.m. Mark Thomas, > wrote: > >> > >>> On 22/04/2021 16:18, Romain Manni-Bucau wrote: > >>>> I am not in JPMS Ray. > >>>> > >>>> About I think the issue is a "double bug" (well one bug, two step > >>>> resolutions) since I can drop the SPI registration but > >>>> then @ServiceProvider will recreate it so I propose: > >>>> > >>>> 1. to drop the explicit SPI registration and keep the default which is > >>> 1-1 > >>>> (even faster but that's more than minor) since it is not needed at all > >>> and > >>>> will enable to use the SPI properly (at least when a single impl is > >>> there, > >>>> when multiple are there a system property can help but that's another > >>> topic > >>>> and rare enough to be ignored for now probably) > >>>> 2. to drop ServiceProvider annotation and replace it by the needed > OSGi > >>>> metadata rather than this particular API > >>>> > >>>> Wdyt? > >>> > >>> I don't see what problem you are attempting to solve. > >>> > >>> The SPI registration is required in case the Tomcat implementation is > >>> used with an API that doesn't have the Tomcat implementation as the > >>> hard-coded default. > >>> > >>> What is the concern with using the @ServiceProvider annotation to > enable > >>> Bnd to generate the correct meta data? > >>> > >>> Mark > >>> > >>> > >>>> > >>>> > >>>> Le jeu. 22 avr. 2021 à 16:10, Raymond Augé >>> .invalid> > >>>> a écrit : > >>>> > >>>>> Are you maybe in JPMS mode? > >>>>> > >>>>> On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, < > >>> raymond.a...@liferay.com> > >>>>> wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, < > >>>>> raymond.a...@liferay.com> > >>>>>> wr
Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x
Le lun. 26 avr. 2021 à 18:57, Mark Thomas a écrit : > On 26/04/2021 17:38, Romain Manni-Bucau wrote: > > JAASRealm is quite commonly used whereas JASPIC is almost never used > > References? > Sadly not public but all project not using a custom valve/auth where using jaas and some good part of it (Id say 35%) sharing a login module. > In my trawl of the Tomcat archives those using the JAAS realm appeared > to have better solutions available whereas those using JASPIC were doing > so for the "right" reasons. > > If there is evidence that the JAAS realm is meeting a user need I'd like > to see it (and understand why JAAS is a better solution than the > alternatives). > Mainly cause it has impl and shareable modules between apps (karaf, tomcat, standalone) whereas jaspic is not. At least being able to enable jaas is important I'd say cause it reduces cost compare to jaspic dev which must be redone for other env (not spread enough). > Mark > > > > (and > > not even speaking of Jakarta Security which has no link with two previous > > ones). > > Main difference is the fact JAAS is in the JVM (with some impl like OS > one > > which is not always trivial to do portably) whereas two others are not so > > it means you easily find a JAAS login module implementation and you don't > > find integrations for others so think it makes sense to keep JAAS > > integration more than others in default delivery. > > > > 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 lun. 26 avr. 2021 à 18:31, Filip Hanik a écrit : > > > >> On Mon, Apr 26, 2021 at 09:17 Mark Thomas wrote: > >> > >>> In reviewing references to Java EE (and J2EE) remaining in the Tomcat > 10 > >>> repo I found the following: > >>> > >>> > >>> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication > >>> framework for J2EE v1.4, based on the >>> href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification > >>> Request 196 to enhance container-managed security and promote > >>> 'pluggable' authentication mechanisms whose implementations would be > >>> container-independent. > >>> > >>> > >>> JSR became JASPIC (now Jakarta Security) and Tomcat has an > >> implementation. > >>> > >>> Searching through the mailing lists I found the following references to > >>> usage of the JAASRealm (going back ~5 years). > >>> > >>> [1] Tomcat 7 user using JAAS based auth to an LDAP server > >>> [2] Tomcat 9 user using SPNEGO with the JAAS realm > >>> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm > >>> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm > >>> [5] User wanting access to HttpServletRequest during auth > >>> > >>> Most, if not all, of those have better solutions available than the > JAAS > >>> Realm. And those wanting some form of custom auth do have the "proper" > >>> Jakarta Security API to work with. > >>> > >>> Therefore, I'm not currently seeing a good reason to keep the > JAASRealm. > >>> Any objections to immediate deprecation with removal planned for > 10.1.x? > >> > >> > >> No objections, > >> go for it > >> > >> > >>> > >>> Mark > >>> > >>> > >>> [1] http://markmail.org/message/ndvr5ilxovoo4ins > >>> [2] http://markmail.org/message/5ocdnmqvvlvjsxas > >>> [3] http://markmail.org/message/wki275i5yhlg3yyo > >>> [4] http://markmail.org/message/av2sv6g4kgm6ouu4 > >>> [5] http://markmail.org/message/fm4ggo3ge4r47gar > >>> > >>> - > >>> 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 > >
