Re: [PROPOSAL] Remove JSP file from ROOT web application

[Raymond Augé]

My 2c.

I think a new static page could easily make it clear what happened without
too much discomfort.

"Welcome to the NEW Apache Tomcat static landing page (replace this webapp
with your own... the old one, if deployed, is probably [here](/quickstart))"

etc. etc.

I would think that in a large portion of "enterprise" cases (a.k.a. those
having long maintenance expectations, as is the case at $myworkplace$),
Tomcat is being repackaged and the default ROOT is being overridden before
the default one is ever seen, in which case the fancy landing page isn't
really a problem to begin with and so you're mainly focusing on the stock
deployments and new users where, honestly, would they really know any
difference?

On Fri, Jun 7, 2024 at 9:24 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 6. Juni 2024 17:26:27 MESZ schrieb Konstantin Kolinko <
> knst.koli...@gmail.com>:
> >чт, 6 июн. 2024 г. в 17:44, Christopher Schultz <
> ch...@christopherschultz.net>:
> >>
> >> All,
> >>
> >> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
> >> remove the dynamic elements. Currently, the only truly dynamic element
> >> in the whole file is this:
> >>
> >> "
> >> Copyright ©1999-${year} Apache Software
> >> Foundation.  All Rights Reserved
> >> "
> >>
> >> I don't see any particular reason that the Copyright information must
> >> always show the "current year". We can simply set this to "the current
> >> year" during the release process.
> >>
> >> This will mean that the default application will be completely static.
> >> Not much of an upgrade, *but* if a user would prefer to completely
> >> remove Jasper, it means that the default home page will be readable.
> >
> >Hi, Chris!
> >
> >Being involved in moderation of one of our mailing lists, I suspect that
> >some amount of spam is caused by our default web page,
> >when it is de-facto used as the front page of a third-party web site.
> >
> >That is, ASF is wrongly interpreted as an owner of that web site.
> >
> >My thoughts were:
> >a) Replace it with a simple static page that just says "It works" or
> similar.
> >b) Make content dynamic, so that the current content is shown to
> >localhost clients only,
> >and show the "simple" page for anyone else.
> >
> >An example of "a)" is Apache HTTPD:
> >
> >
> https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/docroot/index.html?revision=1200966&view=markup
> >https://svn.apache.org/viewvc?view=revision&revision=105393
> >Oct 2004 (19 years, 8 months ago)
> >
> >My preference is for "a)".
>
> +1 for a simple (but still nice to look at) it-works page, when bundled
> into distribution package.
>
> Maybe a link to follow up steps on that page would be good.
>
> The old site could be used for development builds.
>
> Or as suggested moved into another context.
>
> I think b) would add too much surprise possibilities for admins/users to
> be worth it.
>
> Felix
>
> >
> >Maybe move the old shiny "root" page to the examples web application.
> >
> >Best regards,
> >Konstantin Kolinko
> >
> >-
> >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
>
>

-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion

Re: [VOTE] Release Apache Tomcat 8.5.79

[Raymond Augé]

[X] Stable - go ahead and release as 8.5.79 (stable)

On Mon, May 16, 2022 at 6:16 PM Filip Hanik  wrote:

> On Mon, May 16, 2022 at 9:14 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > The proposed Apache Tomcat 8.5.79 release is now available for voting.
> >
> > The notable changes compared to 8.5.78 are:
> >
> > - Provide a property source that sources values from Kubernetes service
> > bindings. Provided by Sumit Kulhadia and Gareth Evans.
> >
> > - The root cause of the Linux kernel duplicate accept bug has been
> > identified along with the version of the kernel that includes the
> fix.
> > The error message displayed when this bug occurs has been updated to
> > reflect this new information and to advise users to update to a
> > version of the OS that uses kernel 5.10 or later. Thanks to
> > Christopher Gual for the research into this issue.
> >
> > - Update the packaged version of the Tomcat Native Library to 1.2.33 to
> > pick up Windows binaries built with OpenSSL 1.1.1o.
> >
> > - Add support for encrypted PKCS#1 formatted private keys when
> > configuring the internal, in memory key store.
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.79/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1375
> > The tag is:
> > https://github.com/apache/tomcat/tree/8.5.79
> > 1af5f227ae591e601a9426d3788bf6a60a1b75a3
> >
> > The proposed 8.5.79 release is:
> > [ ] Broken - do not release
> >
> [X] Stable - go ahead and release as 8.5.79 (stable)
>
> Filip
>


-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion

Re: [VOTE] Release Apache Tomcat 9.0.63

[Raymond Augé]

[X] Stable - go ahead and release as 9.0.63 (stable)

On Wed, May 11, 2022 at 10:09 AM Mark Thomas  wrote:

> On 11/05/2022 09:26, Rémy Maucherat wrote:
> > The proposed Apache Tomcat 9.0.63 release is now available for voting.
> >
> > The notable changes compared to 9.0.62 are:
> >
> > - Provide a property source that sources values from Kubernetes service
> > bindings. Provided by Sumit Kulhadia and Gareth Evans.
> >
> > - The root cause of the Linux kernel duplicate accept bug has been
> > identified along with the version of the kernel that includes the
> fix.
> > The error message displayed when this bug occurs has been updated to
> > reflect this new information and to advise users to update to a
> > version of the OS that uses kernel 5.10 or later. Thanks to
> > Christopher Gual for the research into this issue.
> >
> > - Update the packaged version of the Tomcat Native Library to 1.2.33 to
> > pick up Windows binaries built with OpenSSL 1.1.1o.
> >
> > - Add support for encrypted PKCS#1 formatted private keys when
> configuring
> > the internal, in memory key store.
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.63/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1374
> > The tag is:
> > https://github.com/apache/tomcat/tree/9.0.63
> > 538ed3896852b3608561ba6f3d0bc8890ae15de1
> >
> > The proposed 9.0.63 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 9.0.63 (stable)
>
> Unit tests pass on Linux, Windows and MacOS.
>
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 10.0.21

[Raymond Augé]

[x] Stable - go ahead and release as 10.0.21 (stable)

On Tue, May 10, 2022 at 6:39 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.21 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.20 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.21/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1373
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.21
> feb577944dee2ac7cc9839638e9388d90067f1cb
>
> The proposed 10.0.21 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 10.0.21 (stable)
>
> ---------
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 10.1.0-M15

[Raymond Augé]

[x] Alpha - go ahead and release as 10.1.0-M15 (alpha)



On Tue, May 10, 2022 at 4:24 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M15 release is now available for
> voting.
>
> 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.
>
> The notable changes compared to 10.1.0-M14 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M15/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1371
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M15
> dcf3e81b2e709574971c7a9592614d70c1b55bf7
>
>
> The proposed 10.1.0-M15 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 10.1.0-M15 (alpha)
>
> -
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 8.5.78

[Raymond Augé]

> [X] Stable - go ahead and release as 8.5.78 (stable)

On Thu, Mar 31, 2022 at 12:56 PM Mark Thomas  wrote:

> On 31/03/2022 17:54, Mark Thomas wrote:
>
> > The proposed 8.5.78 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 8.5.78 (stable)
>
> Tests pass with Linux, Windows and MacOS
>
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 9.0.62

[Raymond Augé]

> [X] Stable - go ahead and release as 9.0.62 (stable)

Ray

On Thu, Mar 31, 2022 at 11:23 AM Rémy Maucherat  wrote:

> On Thu, Mar 31, 2022 at 4:56 PM Rémy Maucherat  wrote:
> >
> > The proposed Apache Tomcat 9.0.62 release is now available for voting.
> >
> > The notable changes compared to 9.0.60 are:
> >
> > - Update the packaged version of the Tomcat Native Library to 1.2.32 to
> >pick up Windows binaries built with OpenSSL 1.1.1n.
> >
> > - Improve logging of unknown HTTP/2 settings frames. Pull request by
> >Thomas Hoffmann.
> >
> > - Add additional warnings if incompatible TLS configurations are used
> >such as HTTP/2 with CLIENT-CERT authentication
> >
> > - Harden the class loader to provide a mitigation for CVE-2022-22965
> >a Spring Framework vulnerability
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.62/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1368
> > The tag is:
> > https://github.com/apache/tomcat/tree/9.0.62
> > 85113741042dcce9e9792bdbc3d498172bc31291
> >
> > The proposed 9.0.62 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 9.0.62 (stable)
>
> Rémy
>
> -
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 10.1.0-M14

[Raymond Augé]

> [X] Alpha - go ahead and release as 10.1.0-M14 (alpha)

Ray

On Thu, Mar 31, 2022 at 11:13 AM 
wrote:

> Thank you Mark. I know it's not a Tomcat vulnerability, but if the
> Hardening mitigates the other, then that had me wondering was all.
>
> Thanks for the position clarification.
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
> He/His
>
> Middleware Product Engineering
> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein. If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message. Thank you for your cooperation.
>
>
> > -Original Message-
> > From: Mark Thomas 
> > Sent: Thursday, March 31, 2022 10:08 AM
> > To: dev@tomcat.apache.org
> > Subject: Re: [VOTE] Release Apache Tomcat 10.1.0-M14
> >
> > On 31/03/2022 15:56, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > > Noting the Hardening of the class loader, is this going to require
> this to be a
> > security release of the newest Tomcat releases (forthcoming), or will
> they
> > still just be standard releases?
> >
> > That change does not address a security vulnerability in Apache Tomcat.
> >
> > There will be no CVE for this change.
> >
> > We generally use hardening to refer to things that do not address a
> > vulnerability but improve the overall security posture. Typically, these
> > changes provide additional defense in depth.
> >
> > In this instance, it mitigates CVE-2022-22965 which is a Spring Framework
> > vulnerability. The main purpose of the release is to provide end users
> with an
> > alternative option if updating Tomcat is simpler than updating the
> version of
> > Spring they are using.
> >
> > To provide some context, similar recent hardening changes include:
> >
> > - Using a constant time algorithm to compare passwords. Analysis showed
> >that a timing attack wasn't feasible but we switched now in case it
> >became feasible as some point in the future
> >
> > - We changed the BeanFactory in 10.1.x (and might back-port the change)
> >to prevent it from being used if an application has a JNDI injection
> >vulnerability
> >
> > Finally, we will either keep completely silent about security
> vulnerabilities
> > until they are published or we will be completely open about them up
> front
> > (e.g. if there is a zero day).
> >
> > HTH,
> >
> > 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
>
>

-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion

Re: [VOTE] Release Apache Tomcat 10.0.20

[Raymond Augé]

> [X] Stable - go ahead and release as 10.0.20 (stable)

Ray

On Thu, Mar 31, 2022 at 11:23 AM Rémy Maucherat  wrote:

> On Thu, Mar 31, 2022 at 5:20 PM Mark Thomas  wrote:
> >
> > The proposed Apache Tomcat 10.0.20 release is now available for
> > voting.
> >
> > Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> > package for all the specification APIs has changed from javax.* to
> jakarta.*
> >
> > Applications that run on Tomcat 9 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
> >
> > The notable changes compared to 10.0.18 are:
> >
> > - Update the packaged version of the Tomcat Native Library to 1.2.32 to
> >pick up Windows binaries built with OpenSSL 1.1.1n.
> >
> > - Improve logging of unknown HTTP/2 settings frames. Pull request by
> >Thomas Hoffmann.
> >
> > - Add additional warnings if incompatible TLS configurations are used
> >such as HTTP/2 with CLIENT-CERT authentication
> >
> > - Harden the class loader to provide a mitigation for CVE-2022-22965
> >a Spring Framework vulnerability
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.20/
> >
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1369
> >
> > The tag is:
> > https://github.com/apache/tomcat/tree/10.0.20
> > 2a46c651529a9d237b4d6beb1ef846922d949342
> >
> > The proposed 10.0.20 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 10.0.20 (stable)
>
> Rémy
>
> -
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 9.0.61

[Raymond Augé]

[ X ] Stable - go ahead and release as 9.0.61 (stable)

Unzip and run worked fine on Linux.

On Wed, Mar 30, 2022 at 4:22 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.61 release is now available for voting.
>
> The notable changes compared to 9.0.60 are:
>
> - Fix a potential thread-safety issue that could cause HTTP/1.1 request
>processing to pause, and potentially timeout, waiting for additional
>data when the full request has been received.
>
> - Fix a regression introduced with 65757 bugfix which better identified
>non request threads but which introduced a similar problem when user
>code was doing sequential operations in a single thread.
>
> - When resolving methods in EL expressions that use beans and/or static
>fields, ensure that any custom type conversion is considered when
>identifying the method to call.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.61/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1366
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.61
> 6c6432ac1416ed369f892b9ce76e10c7eb10b91c
>
> The proposed 9.0.61 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.61 (stable)
>
> Rémy
>
> -
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 10.0.19

[Raymond Augé]

[ X ] Stable - go ahead and release as 10.0.19 (stable)

Simple unzip & run on Linux seems to work fine!


On Tue, Mar 29, 2022 at 7:49 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.19 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.18 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Add additional warnings if incompatible TLS configurations are used
>such as HTTP/2 with CLIENT-CERT authentication
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.19/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1365
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.19
> 0b4fe866e5a4e06481e5019be9468e10790647ba
>
> The proposed 10.0.19 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 10.0.19 (stable)
>
> -----
> 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, Java Champion

Re: [VOTE] Release Apache Tomcat 10.1.0-M13

[Raymond Augé]

[ X ] Alpha - go ahead and release as 10.1.0-M13 (alpha)

Simple unzip & run on Linux seems to work fine!

Ray

On Tue, Mar 29, 2022 at 7:06 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M13 release is now available for
> voting.
>
> 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.
>
> The notable changes compared to 10.1.0-M12 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Update the JASPIC 2.0 API to Jakarta Authentication 3.0 (JASPIC was
>renamed for Jakarta EE 10)
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M13/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1364
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M13
> faa2582152d9dcbcb444700df340e10a85fc375f
>
>
> The proposed 10.1.0-M13 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 10.1.0-M13 (alpha)
>
> -
> 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, Java Champion

is org.apache.tomcat.jakartaee meant to be optional dependency

[Raymond Augé]

Hey all,

Regarding tomcat 10.x+

I'm wondering if org.apache.tomcat.jakartaee usage in tomcat-catalina is
intended to be optional?

By the looks of it, I'm thinking not, so it begs the question whether it
should be a proper module; both JPMS and OSGi? Otherwise tomcat-catalina
can never be used in either.

Ray

Re: tomcat-coyote vs. tomcat-catalina modularity problem

[Raymond Augé]

👍 I'll prepare a pr.

On Sun., Mar. 13, 2022, 1:11 p.m. Mark Thomas,  wrote:

> On 13/03/2022 03:07, Raymond Augé wrote:
> > tomcat-catalina imports org.apache.tomcat.util.http.fileupload.impl [1]
> > tomcat-coyote however does not export
> > org.apache.tomcat.util.http.fileupload.impl
> >
> > How would you like to address this?
> >
> > Should tomcat-coyote simply export the package?
>
> Seems like the obvious choice.
>
> > or should the classes (two
> > Exceptions) be made part of the Coyote API (not a breaking change to
> > outsiders since it's like adding never before seen types.)
>
> Do you mean move those classes to a new package? If so, exporting looks
> better as these classes are a packaged renamed form of Commons File
> Upload so keeping classes in the existing is preferred.
>
> Mark
>
>
> > This affects all versions from what I can see. It's not a critical issue,
> > just a packaging and modularity one. It WOULD however come into play in
> > OSGi or JPMS use cases.
> >
> > Thoughts?
> >
> > Ray
> >
> > [1]
> >
> https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/connector/Request.java#L110-L111
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

tomcat-coyote vs. tomcat-catalina modularity problem

[Raymond Augé]

tomcat-catalina imports org.apache.tomcat.util.http.fileupload.impl [1]
tomcat-coyote however does not export
org.apache.tomcat.util.http.fileupload.impl

How would you like to address this?

Should tomcat-coyote simply export the package? or should the classes (two
Exceptions) be made part of the Coyote API (not a breaking change to
outsiders since it's like adding never before seen types.)

This affects all versions from what I can see. It's not a critical issue,
just a packaging and modularity one. It WOULD however come into play in
OSGi or JPMS use cases.

Thoughts?

Ray

[1]
https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/connector/Request.java#L110-L111

Re: Attention non-committers: a word about [VOTE] threads

[Raymond Augé]

Thank you Christopher for the reminder and for the record, this doesn't
just apply to non-committer.. but even more so to committers.

I feel guilty that I haven't taken action on this front other than a few
times in the beginning and it's not right. I pledge to take more action
from now on.

Sincerely,
Ray

On Sat, Mar 12, 2022 at 12:13 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> In case you (read reader) are not a Tomcat committer, please don't
> ignore the [VOTE] emails that come out for each release. *Everyone* is
> welcome to vote on a proposed release, and, honestly, we'd prefer more
> feedback than less.
>
> If you have a problem, we'll help you solve it.
>
> If you're interested in becoming involved in votes, I would recommend
> that you watch this video of a presentation from ApacheCon @Home 2020
> which describes how to build Tomcat from source and run the unit tests,
> etc.
>
> https://www.youtube.com/watch?v=O2wXAldxQWA
>
> We'd love to have more input on releases, honestly. So if you have any
> questions, please post to this list for help.
>
> All you need to do in order to participate in a VOTE is to reply to the
> VOTE thread. You should try to use the release-build in a way that has
> meaning for you (like maybe with a development version of your own
> product) and let us know if everything is working as expected (or not!).
>
> Thanks,
> -chris
>
>
> -
> 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, Java Champion

Re: ULRStreamHandlerFactory proposal

[Raymond Augé]

Lastly, I do agree that if fixed in Java that would be the best case
scenario. However, I am not hopeful.

On Thu, Feb 17, 2022 at 9:08 AM Raymond Augé 
wrote:

> Another small point is that the issue is with cleanup more than with
> registration. The Java 17 API has no way to remove factories. This tied to
> the lack of a coordination model means that you risk classloader pinning.
> Sure tomcat has a work around. But there is no portable API anywhere to do
> it. Each product has it's own design an quirks.
>
> On Thu, Feb 17, 2022 at 9:02 AM Raymond Augé 
> wrote:
>
>> I would like to clarify one small point which may have been missed in my
>> description.
>>
>> The issue is that there is not only tomcat. There are other frameworks in
>> the Java ecosystem having a desire to manage URLStreamHandlerFactories. The
>> problem is coordination between them when they are peers, or when they form
>> any type of hierarchy. The current API simply cannot cope with that. We
>> have an issue with tomcat as it is to be honest because we are downstream
>> from it, and if tomcat did it's binding we are screwed in our downstream
>> use case. The same if a framework were to do it and tomcat were downstream
>> of it (embedded).
>>
>> Anyhow, thank you for your consideration.
>>
>> Ray
>>
>>
>>
>> On Thu, Feb 17, 2022 at 6:10 AM Romain Manni-Bucau 
>> wrote:
>>
>>> 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 

Re: ULRStreamHandlerFactory proposal

[Raymond Augé]

Another small point is that the issue is with cleanup more than with
registration. The Java 17 API has no way to remove factories. This tied to
the lack of a coordination model means that you risk classloader pinning.
Sure tomcat has a work around. But there is no portable API anywhere to do
it. Each product has it's own design an quirks.

On Thu, Feb 17, 2022 at 9:02 AM Raymond Augé 
wrote:

> I would like to clarify one small point which may have been missed in my
> description.
>
> The issue is that there is not only tomcat. There are other frameworks in
> the Java ecosystem having a desire to manage URLStreamHandlerFactories. The
> problem is coordination between them when they are peers, or when they form
> any type of hierarchy. The current API simply cannot cope with that. We
> have an issue with tomcat as it is to be honest because we are downstream
> from it, and if tomcat did it's binding we are screwed in our downstream
> use case. The same if a framework were to do it and tomcat were downstream
> of it (embedded).
>
> Anyhow, thank you for your consideration.
>
> Ray
>
>
>
> On Thu, Feb 17, 2022 at 6:10 AM Romain Manni-Bucau 
> wrote:
>
>> 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 embed

Re: ULRStreamHandlerFactory proposal

[Raymond Augé]

I would like to clarify one small point which may have been missed in my
description.

The issue is that there is not only tomcat. There are other frameworks in
the Java ecosystem having a desire to manage URLStreamHandlerFactories. The
problem is coordination between them when they are peers, or when they form
any type of hierarchy. The current API simply cannot cope with that. We
have an issue with tomcat as it is to be honest because we are downstream
from it, and if tomcat did it's binding we are screwed in our downstream
use case. The same if a framework were to do it and tomcat were downstream
of it (embedded).

Anyhow, thank you for your consideration.

Ray



On Thu, Feb 17, 2022 at 6:10 AM Romain Manni-Bucau 
wrote:

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

ULRStreamHandlerFactory proposal

[Raymond Augé]

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?

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

Re: Reproducible builds update

[Raymond Augé]

Hey Mark,

bnd is in ramp down phase targetting a release in Feb so if you do find an
issue soon-ish we can work to get it in the release.

Ray

On Wed, Jan 26, 2022 at 4:05 AM Mark Thomas  wrote:

> I have made some progress on this over the last few days. The current
> status is:
>
> - Builds are reproducible (excluding signing of Windows binaries) when
>using the same OS / Java / Ant combination.
>
> - JSign gives us what we need to handling the signing of the Windows
>binaries. "Just" need to implement it.
>
> - No solution yet for the zipped JSON files created by the Javadoc tool.
>This is low priority. If we decide to address it, the short-term fix
>will be to unpack and rebuild the zip. The long term fix will be to
>get the Javadoc tool changed.
>
> - The Ant archive cross-platform ordering issues (".../..." vs
>"...\...") have been worked around with some renaming. The long term
>fix is to address this in Ant.
>
> - I think there is another BND issue. I've seen one instance of
>module-info.class being generated differently. I'm not sure if this is
>a pure BND issue or if cross-platform builds were a factor.
>
> - I have also seen one issue where XReflectionIntrospectionUtils.class
>was generated differently. I haven't looked into that yet.
>
>
> I have a few commits to push to improve cross-platform reproducibility.
> One is for the Ant archive ordering issue. The rest are various LF vs
> CRLF issues.
>
> My plan is to push these changes and back-port them - probably later today.
>
> I intend to continue working on making the Tomcat build reproducible
> cross-platform but I anticipate that this work will be on the
> back-burner for a while as I have a couple of other things I want to
> look at first.
>
> 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, Java Champion

Re: Time to create Tomcat 10.1.x and master->main migration

[Raymond Augé]

+1

I think it's a great plan.

Ray

On Tue., May 18, 2021, 8:16 a.m. Romain Manni-Bucau, 
wrote:

> +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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | 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: mod_headers as a Filter

[Raymond Augé]

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: Clarify what Tomcat means with "Jakarta EE 9 "mention

[Raymond Augé]

I believe the distinction might be w.r.t. what used to be referred to as
"Web Profile" vs. "Full Profile".

Is that correct Romain?

- Ray

On Mon, Apr 26, 2021 at 9:33 AM Mark Thomas  wrote:

> We need to find a way to re-work the first paragraph on the home page to
> reference both Java EE and Jakarta EE. There are probably the places in
> the site, and probably the docs, where we need to address this.
>
> I'll take a look this afternoon.
>
> Mark
>
>
>
> On 26/04/2021 14:02, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > Going on http://tomcat.apache.org/ you can read "The Apache Tomcat
> Project
> > is proud to announce the release of version 10.0.5 of Apache Tomcat. This
> > release is targeted at Jakarta EE 9." and later "Java EE applications
> > designed for Tomcat 9 ".
> >
> > It seems it is a very common phrasing and I get regularly (not for all
> > releases but often enough) pinged offline to know what is the difference
> > between Apache TomEE and Apache Tomcat if Tomcat supports JakartaEE.
> >
> > I don't have a clear solution but do you think the phrasing can be
> reworked
> > a bit to clarify it only concerns a few specs and avoid this
> > misunderstanding (guess a link to a reference page can work without being
> > too heavy)?
> >
> > 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
>
>

-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow

Re: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

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>
> >>> wrote:
> >>>
> >>>> @ServiceProvider is just a hint no?
> >>>>
> >>>> It does not change the implementation behavior... Unless you've found
> >>>> otherwise, which would be surprising.
> >>>>
> >>>
> >>> To be clear, there is no runtime behavior associated with
> >> @ServiceProvider
> >>> _unless_ you are running tomcat in OSGi, which would bring in the
> Service
> >>> Loader Mediator to handle the SPI call, BUT still would not change to
> >> logic
> >>> around using a fallback impl if so coded.
> >>>
> >>>
> >>>> Ray
> >>>>
> >>>> On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, <
> >>>> rmannibu...@gmail.com> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Websocket server configurator uses the SPI to load the impl and if
> not
> >>>>> found fallbacks on the hardcoded tomcat default.
> >>>>> Isn't the SPI intended to override the default and
> >>>>> therefore @ServiceProvider breaks this feature?
> >>>>> If not, how to override it globally without doing it on a per
> endpoint
> >>>>> basis?
> >>>>>
> >>>>> 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: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, 
wrote:

> @ServiceProvider is just a hint no?
>
> It does not change the implementation behavior... Unless you've found
> otherwise, which would be surprising.
>

To be clear, there is no runtime behavior associated with @ServiceProvider
_unless_ you are running tomcat in OSGi, which would bring in the Service
Loader Mediator to handle the SPI call, BUT still would not change to logic
around using a fallback impl if so coded.


> Ray
>
> On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, <
> rmannibu...@gmail.com> wrote:
>
>> Hi all,
>>
>> Websocket server configurator uses the SPI to load the impl and if not
>> found fallbacks on the hardcoded tomcat default.
>> Isn't the SPI intended to override the default and
>> therefore @ServiceProvider breaks this feature?
>> If not, how to override it globally without doing it on a per endpoint
>> basis?
>>
>> 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: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

Are you maybe in JPMS mode?

On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, 
wrote:

>
>
> On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, 
> wrote:
>
>> @ServiceProvider is just a hint no?
>>
>> It does not change the implementation behavior... Unless you've found
>> otherwise, which would be surprising.
>>
>
> To be clear, there is no runtime behavior associated with @ServiceProvider
> _unless_ you are running tomcat in OSGi, which would bring in the Service
> Loader Mediator to handle the SPI call, BUT still would not change to logic
> around using a fallback impl if so coded.
>
>
>> Ray
>>
>> On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, <
>> rmannibu...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Websocket server configurator uses the SPI to load the impl and if not
>>> found fallbacks on the hardcoded tomcat default.
>>> Isn't the SPI intended to override the default and
>>> therefore @ServiceProvider breaks this feature?
>>> If not, how to override it globally without doing it on a per endpoint
>>> basis?
>>>
>>> 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: Websocket server configurator as @ServiceProvider: a bug?

[Raymond Augé]

@ServiceProvider is just a hint no?

It does not change the implementation behavior... Unless you've found
otherwise, which would be surprising.

Ray

On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, 
wrote:

> Hi all,
>
> Websocket server configurator uses the SPI to load the impl and if not
> found fallbacks on the hardcoded tomcat default.
> Isn't the SPI intended to override the default and
> therefore @ServiceProvider breaks this feature?
> If not, how to override it globally without doing it on a per endpoint
> basis?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: TCK Signature for EL API

[Raymond Augé]

Great news! I'm both sad that the annotations caused you pain (the complete
opposite was intended) and happy that you managed to work around the
problem.

It's not by coincidence that BND uses the intermediate state of the
manifest to go between the annotations and the module info. However, I
wasn't sure that this would cover all cases particularly w.r.t. the service
loader handling. However, it appears it does.

Sincerely,
Ray


On Tue, Apr 6, 2021 at 10:39 AM Mark Thomas  wrote:

> On 02/04/2021 13:58, Raymond Augé wrote:
> > I just wanted to make a note that removing the annotation will also mean
> > that the module-info.java will need to be manually managed since bnd also
> > generated that based on the annotations.
>
> Good news. I compared the module-info.class files for the EL API jar and
> the WebSocket API jar between the 9.0.45 release (that used the
> annotation) and a current build from source (that doesn't use the
> annotation) and they are identical. On that basis I think we have a
> working solution.
>
> Mark
>
>
> >
> > Just FYI,
> > - Ray
> >
> > On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO 
> > wrote:
> >
> >> That's awesome news.
> >>
> >> I'm glad it's something that can be achieved without too much effort.
> >> I understand and buy the pragmatic approach.
> >>
> >> But at the same time, if we can do a step forward and get even closer to
> >> being certified, that'd be great.
> >>
> >> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas  a écrit :
> >>
> >>> I've been playing with this a bit more and it appears we can simply
> >>> hard-code the "Require-Capability" header in el-api.jar.bnd
> >>>
> >>> Having taken the time to look at the actual values generated for these
> >>> API JARs, this does look like something that would be simple to
> maintain
> >>> manually - especially for the API JARs where adding a new use of
> >>> ServiceLoader is likely to happen fairly rarely.
> >>>
> >>> We should be able to remove the Bnd annotation in
> >>> - 10.0.x for 10.0.6 onwards
> >>> - 9.0.x for 9.0.46 onwards
> >>>
> >>> We'll certainly do this for the API JARs. I think we'll leave it in
> >>> place for the implementation JARs
> >>>
> >>> I have a few things on my TODO list at the moment but I don't see why I
> >>> shouldn't be able to get this done for the May set of releases.
> >>>
> >>> Mark
> >>>
> >>>
> >>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> >>>> Hi,
> >>>>
> >>>> AFAIK TomEE will try to be certified and will try to not fork as much
> >> as
> >>>> possible Tomcat code so can be neat to solve it in particular when
> >>>> relatively easy:
> >>>>
> >>>> 1. compile tomcat classes with bnd as of today
> >>>> 2. run bnd to get the manifest.mf (
> >>>> 3. post process tomcat classes to remove bnd from the .class
> >>>> 4. jar it
> >>>>
> >>>> should solve the process and does not look crazy compared to what
> >> tomcat
> >>>> already does, no?
> >>>>
> >>>> Alternative is indeed to drop bnd since the manifest is quite easy to
> >>> write
> >>>> manually or with an ant task to filter the version for tomcat case, at
> >>>> least for spec jars (it is harder for the impl but here bnd is fine).
> >>>>
> >>>> 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. 1 avr. 2021 à 09:19, Mark Thomas  a écrit :
> >>>>
> >>>>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> >>>>>> and I&

Re: TCK Signature for EL API

[Raymond Augé]

I just wanted to make a note that removing the annotation will also mean
that the module-info.java will need to be manually managed since bnd also
generated that based on the annotations.

Just FYI,
- Ray

On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO 
wrote:

> That's awesome news.
>
> I'm glad it's something that can be achieved without too much effort.
> I understand and buy the pragmatic approach.
>
> But at the same time, if we can do a step forward and get even closer to
> being certified, that'd be great.
>
> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas  a écrit :
>
> > I've been playing with this a bit more and it appears we can simply
> > hard-code the "Require-Capability" header in el-api.jar.bnd
> >
> > Having taken the time to look at the actual values generated for these
> > API JARs, this does look like something that would be simple to maintain
> > manually - especially for the API JARs where adding a new use of
> > ServiceLoader is likely to happen fairly rarely.
> >
> > We should be able to remove the Bnd annotation in
> > - 10.0.x for 10.0.6 onwards
> > - 9.0.x for 9.0.46 onwards
> >
> > We'll certainly do this for the API JARs. I think we'll leave it in
> > place for the implementation JARs
> >
> > I have a few things on my TODO list at the moment but I don't see why I
> > shouldn't be able to get this done for the May set of releases.
> >
> > Mark
> >
> >
> > On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> > > Hi,
> > >
> > > AFAIK TomEE will try to be certified and will try to not fork as much
> as
> > > possible Tomcat code so can be neat to solve it in particular when
> > > relatively easy:
> > >
> > > 1. compile tomcat classes with bnd as of today
> > > 2. run bnd to get the manifest.mf (
> > > 3. post process tomcat classes to remove bnd from the .class
> > > 4. jar it
> > >
> > > should solve the process and does not look crazy compared to what
> tomcat
> > > already does, no?
> > >
> > > Alternative is indeed to drop bnd since the manifest is quite easy to
> > write
> > > manually or with an ant task to filter the version for tomcat case, at
> > > least for spec jars (it is harder for the impl but here bnd is fine).
> > >
> > > 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. 1 avr. 2021 à 09:19, Mark Thomas  a écrit :
> > >
> > >> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> > >>> Hello,
> > >>>
> > >>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> > >>> and I'm wondering how Tomcat will proceed with the bnd annotation in
> > >>> the EL API? Will it be removed in the next release?
> > >>
> > >> Currently, there are no plans to change the Tomcat code.
> > >>
> > >> We do run the TCKs but take a pragmatic view of any failures. For
> > >> example, the Servlet TCK test that tests setting a context path in
> > >> web.xml always fails because Tomcat always overrides any such setting.
> > >> The Servlet spec allows this setting to be overridden but the TCK test
> > >> doesn't consider the possibility that a container will always do this.
> > >> Therefore we simply treat this as an expected failure. Full details
> for
> > >> all the TCKs we run can be found on the Wiki:
> > >>
> > >> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> > >>
> > >> The EL signature test failure is another example of a failure that we
> > >> consider can be safely ignored.
> > >>
> > >> Tomcat does not, and has not for many, many years, formally certified
> > >> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> > >> request at any point in that time to complete formal certification.
> > >> Therefore, I expect that Tomcat will continue following its current
> > >> pragmatic approach to the TCKs.
> > >>
> > >> 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
> >
> >
>
> --
> Jean-Louis
>


-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow