[ANN] Apache Tomcat 9.0.95 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.95.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.95 is a bugfix and feature release. The notable
changes compared to 9.0.94 include:

  - Fix the regression in HTTP/2 support introduced in 9.0.94.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE][RESULT] Release Apache Tomcat 9.0.95

[Rémy Maucherat]

The following votes were cast:

Binding:
+1: remm, markt, jfclere

Non-binding:
+1: dsoumis

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.95

[Rémy Maucherat]

On Fri, Sep 13, 2024 at 9:18 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.95 release is now available for voting.
>
> The notable changes compared to 9.0.94 are:
>
> - Fix the regression in HTTP/2 support introduced in 9.0.94.
>
> 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.95/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1515
>
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.95
> 9f8c522e2a556002ecb356ed71dcaf788da6aa5f
>
> The proposed 9.0.95 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.95

Rémy

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

[Rémy Maucherat]

On Sat, Sep 14, 2024 at 1:10 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 10.1.30 release is now available for
> voting.
>
> All committers and PMC members are kindly requested to provide a vote if
> possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes are
> binding. We welcome non-committer votes or comments on release builds.
>
> The notable changes compared to 10.1.29 are:
>
> - Fix the regression in HTTP/2 support introduced in 10.1.29.
>
> 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.30/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1516
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.30
> https://github.com/apache/tomcat/commit/08bb04e1711e9856479596403b38cccf8287bc5b
>
> Please reply with a +1 for release or +0/-0/-1 with an explanation.

+1

Maybe you can upgrade your Ant to 1.10.15 for the next build ? Java 23
will be out so I plan to try upgrading that as well.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 11.0.0-M26

[Rémy Maucherat]

On Fri, Sep 13, 2024 at 8:03 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 11.0.0-M26 release is now available for
> voting.
>
> Apache Tomcat 11.0.0-M26 is a 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 11.0.0-M25 include:
>
> - Fix the regression in HTTP/2 support introduced in 11.0.0-M25.
>
> 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-M26/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1514
>
> The tag is:
> https://github.com/apache/tomcat/tree/11.0.0-M26
> e9935d107776339a4a48cf4e32195a763fbf8379
>
> The proposed 11.0.0-M26 release is:
> [ ] -1 Broken - do not release
> [X] +1 Beta   - go ahead and release as 11.0.0-M26

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE] Release Apache Tomcat 9.0.95

[Rémy Maucherat]

The proposed Apache Tomcat 9.0.95 release is now available for voting.

The notable changes compared to 9.0.94 are:

- Fix the regression in HTTP/2 support introduced in 9.0.94.

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.95/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1515

The tag is:
https://github.com/apache/tomcat/tree/9.0.95
9f8c522e2a556002ecb356ed71dcaf788da6aa5f

The proposed 9.0.95 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.95

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Future of JNI in Tomcat

[Rémy Maucherat]

On Fri, Sep 13, 2024 at 4:46 PM Christopher Schultz
 wrote:
>
> Mark,
>
> On 9/12/24 12:48, Mark Thomas wrote:
> > On 12/09/2024 15:15, Rémy Maucherat wrote:
> >> Hi,
> >>
> >> This JEP has the potential to have a significant impact with Tomcat's
> >> JNI use starting with Java 26.
> >> https://openjdk.org/jeps/471
> >>
> >> Unsafe.invokeCleaner will be removed, which will effectively prevent
> >> using the direct ByteBuffers that are needed for tomcat-native. The
> >> solution is to use a memory segment from FFM, then call
> >> MemorySegment.asByteBuffer, which creates a direct ByteBuffer with a
> >> controllable lifecycle. So using JNI would require FFM and using the
> >> full FFM code instead should make more sense.
> >
> > +1.
> >
> >> We will of course have to see how things turn out ...
> >
> > FFM is looking more and more like the way to go.
> >
> >> Another, less problematic, yet still annoying change will be
> >> https://openjdk.org/jeps/472 in Java 24+. Basically, the native access
> >> flag use will become mandatory. This is a bit annoying since it is not
> >> possible to add "--enable-native-access=ALL-UNNAMED" in the default
> >> command line without breaking on older Java.
> >
> > So we have issues when running older Tomcats that have to work with JREs
> > that don't have FFM - hence they need JNI.
> >
> > We have had issues like this before and have managed to hack around
> > them. Maybe it is time for slightly more robust solution. I was thinking
> > something like:
> >
> > - new class in bootstrap JAR with a main method that just returns the
> > current major java version as the exit code
>
> Could this be done without any custom code? I suppose running "java
> -version" and parsing the output using grep/sed/awk/Perl/whatever would
> be error-prone.

This does not look like it is super portable. So yes, having a utility
class in buildutils and then bootstrap could help clean things up.

> I suppose the performance difference between running "java -version" and
> "java GetMajorVersion" is negligible.
>
> > - the startup scripts call java with that class and store exit code in a
> > variable
> >
> > - we use that variable to select what to include when composing the main
> > command line to start Tomcat.
>
> +1 this should work

Yes, it would.

For my javac version in Tomcat 9, it is doing:

  

This utility class could also cover parsing of the javac output maybe ...

Rémy

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

Future of JNI in Tomcat

[Rémy Maucherat]

Hi,

This JEP has the potential to have a significant impact with Tomcat's
JNI use starting with Java 26.
https://openjdk.org/jeps/471

Unsafe.invokeCleaner will be removed, which will effectively prevent
using the direct ByteBuffers that are needed for tomcat-native. The
solution is to use a memory segment from FFM, then call
MemorySegment.asByteBuffer, which creates a direct ByteBuffer with a
controllable lifecycle. So using JNI would require FFM and using the
full FFM code instead should make more sense.

We will of course have to see how things turn out ...

Another, less problematic, yet still annoying change will be
https://openjdk.org/jeps/472 in Java 24+. Basically, the native access
flag use will become mandatory. This is a bit annoying since it is not
possible to add "--enable-native-access=ALL-UNNAMED" in the default
command line without breaking on older Java.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Architecture UML diagrams - startup

[Rémy Maucherat]

On Tue, Sep 10, 2024 at 6:15 PM Mark Thomas  wrote:
>
> All,
>
> I have finished the first pass at updating the startup architecture
> diagrams.
>
> The previous (5.5.x based) PDF can be found at
>
> https://github.com/apache/tomcat/blob/main/webapps/docs/architecture/startup/serverStartup.pdf
>
> along with a text description at
>
> https://github.com/apache/tomcat/blob/main/webapps/docs/architecture/startup/serverStartup.txt
>
> The new UML diagrams are numbers 1 to 7 and can be found in:
>
> https://github.com/apache/tomcat/tree/main/webapps/docs/architecture/startup
>
> alongside the PlantUML source.

Well, the end result is excellent given the relative simplicity of the
input. Great tool and great work.

Rémy

> The focus isn't exactly the same. I haven't covered the Digester and how
> it uses RuleSets but there is more detail on component start and
> configuration.
>
> Before I start on the request processing diagrams, I'd welcome feedback
> on the work so far.
>
> Mark
>
> PS Another hat tip to Felix as I am finding PlantUML more and more
> impressive as I use it.
>
> -
> 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

[ANN] Apache Tomcat 9.0.94 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.94.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.94 is a bugfix and feature release. The notable
changes compared to 9.0.93 include:

- If an HTTP/2 client resets a stream before the request body is fully
   written, ensure that any ReadListener is notified via a call to
   ReadListener.onErrror()

- An Exception being thrown during WebSocket message processing (e.g. in
   a method annotated with @onMessage) should not automatically cause the
   connection to close. The application should handle the exception and
   make the decision whether or not to close the connection.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: (tomcat) branch main updated: Use constant

[Rémy Maucherat]

On Mon, Sep 9, 2024 at 4: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 1fb42bae8b Use constant
> 1fb42bae8b is described below
>
> commit 1fb42bae8bb6e1eaf3ca494bcb98fef134ac59b0
> Author: Mark Thomas 
> AuthorDate: Mon Sep 9 15:50:58 2024 +0100
>
> Use constant

Thanks !

Rémy

> ---
>  test/org/apache/tomcat/util/net/TestCustomSsl.java   | 2 ++
>  test/org/apache/tomcat/util/net/TestSSLHostConfigCompat.java | 8 
>  test/org/apache/tomcat/util/net/TesterSupport.java   | 3 ++-
>  3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/test/org/apache/tomcat/util/net/TestCustomSsl.java 
> b/test/org/apache/tomcat/util/net/TestCustomSsl.java
> index fc458cf14e..f4311a9e03 100644
> --- a/test/org/apache/tomcat/util/net/TestCustomSsl.java
> +++ b/test/org/apache/tomcat/util/net/TestCustomSsl.java
> @@ -62,6 +62,8 @@ public class TestCustomSsl extends TomcatBaseTest {
>  File keystoreFile = new File(TesterSupport.LOCALHOST_RSA_JKS);
>  
> certificate.setCertificateKeystoreFile(keystoreFile.getAbsolutePath());
>
> +certificate.setCertificateKeyPassword(TesterSupport.JKS_PASS);
> +
>  connector.setSecure(true);
>  Assert.assertTrue(connector.setProperty("SSLEnabled", "true"));
>
> diff --git a/test/org/apache/tomcat/util/net/TestSSLHostConfigCompat.java 
> b/test/org/apache/tomcat/util/net/TestSSLHostConfigCompat.java
> index 3c185ea3fe..9d5c8ecbf8 100644
> --- a/test/org/apache/tomcat/util/net/TestSSLHostConfigCompat.java
> +++ b/test/org/apache/tomcat/util/net/TestSSLHostConfigCompat.java
> @@ -244,7 +244,7 @@ public class TestSSLHostConfigCompat extends 
> TomcatBaseTest {
>  case KEYSTORE: {
>  SSLHostConfigCertificate sslHostConfigCertificateRsa = new 
> SSLHostConfigCertificate(sslHostConfig, Type.RSA);
>  
> sslHostConfigCertificateRsa.setCertificateKeystoreFile(getPath(TesterSupport.LOCALHOST_RSA_JKS));
> -
> sslHostConfigCertificateRsa.setCertificateKeystorePassword("changeit");
> +
> sslHostConfigCertificateRsa.setCertificateKeystorePassword(TesterSupport.JKS_PASS);
>  sslHostConfig.addCertificate(sslHostConfigCertificateRsa);
>  break;
>  }
> @@ -252,7 +252,7 @@ public class TestSSLHostConfigCompat extends 
> TomcatBaseTest {
>  SSLHostConfigCertificate sslHostConfigCertificateRsa = new 
> SSLHostConfigCertificate(sslHostConfig, Type.RSA);
>  
> sslHostConfigCertificateRsa.setCertificateFile(getPath(TesterSupport.LOCALHOST_RSA_CERT_PEM));
>  
> sslHostConfigCertificateRsa.setCertificateKeyFile(getPath(TesterSupport.LOCALHOST_RSA_KEY_PEM));
> -
> sslHostConfigCertificateRsa.setCertificateKeyPassword("changeit");
> +
> sslHostConfigCertificateRsa.setCertificateKeystorePassword(TesterSupport.JKS_PASS);
>  sslHostConfig.addCertificate(sslHostConfigCertificateRsa);
>  break;
>  }
> @@ -266,7 +266,7 @@ public class TestSSLHostConfigCompat extends 
> TomcatBaseTest {
>  case KEYSTORE: {
>  SSLHostConfigCertificate sslHostConfigCertificateEc = new 
> SSLHostConfigCertificate(sslHostConfig, Type.EC);
>  
> sslHostConfigCertificateEc.setCertificateKeystoreFile(getPath(TesterSupport.LOCALHOST_EC_JKS));
> -
> sslHostConfigCertificateEc.setCertificateKeystorePassword("changeit");
> +
> sslHostConfigCertificateEc.setCertificateKeystorePassword(TesterSupport.JKS_PASS);
>  sslHostConfig.addCertificate(sslHostConfigCertificateEc);
>  break;
>  }
> @@ -274,7 +274,7 @@ public class TestSSLHostConfigCompat extends 
> TomcatBaseTest {
>  SSLHostConfigCertificate sslHostConfigCertificateEc = new 
> SSLHostConfigCertificate(sslHostConfig, Type.EC);
>  
> sslHostConfigCertificateEc.setCertificateFile(getPath(TesterSupport.LOCALHOST_EC_CERT_PEM));
>  
> sslHostConfigCertificateEc.setCertificateKeyFile(getPath(TesterSupport.LOCALHOST_EC_KEY_PEM));
> -sslHostConfigCertificateEc.setCertificateKeyPassword("changeit");
> +
> sslHostConfigCertificateEc.setCertificateKeyPassword(TesterSupport.JKS_PASS);
>  sslHostConfig.addCertificate(sslHostConfigCertificateEc);
>  break;
>  }
> diff --git a/test/org/apache/tomcat/util/net/TesterSupport.java 
> b/test/org/apache/tomcat/util/net/TesterSupport.java
> index ca3a4cee6d..308f28acc2 100644
> --- a/test/org/apache/tomcat/util/net/TesterSupport.java
> +++ b/test/org/apache/tomcat/util/net/TesterSupport.java
> @@ -109,6 +109,7 @@ public final class TesterSupport {
>  }
>
>  public static void initSsl(Tomcat tomcat) {
> +/

[VOTE] Release Apache Tomcat 9.0.94

[Rémy Maucherat]

The proposed Apache Tomcat 9.0.94 release is now available for voting.

The notable changes compared to 9.0.93 are:

- If an HTTP/2 client resets a stream before the request body is fully
   written, ensure that any ReadListener is notified via a call to
   ReadListener.onErrror()

- An Exception being thrown during WebSocket message processing (e.g. in
   a method annotated with @onMessage) should not automatically cause the
   connection to close. The application should handle the exception and
   make the decision whether or not to close the connection.

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.94/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1512

The tag is:
https://github.com/apache/tomcat/tree/9.0.94
ce248107f21c2cdaa723855d5453f6d75b84204f

The proposed 9.0.94 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.94

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tagging the September releases and 11.0.x stability

[Rémy Maucherat]

On Tue, Sep 3, 2024 at 4:00 PM Mark Thomas  wrote:
>
> Hi all,
>
> I'm just wrapping up the fix for BZ 69302. Once that is committed, I
> expect to tag 11.0.0-M25.
>
> I also think we need to start thinking about declaring 11.0.x stable.
> The specs are implemented, the TCKs are passing, 11.0.x is pretty close
> to 10.1.x.
>
> A thought that has been forming is that we could announce the first
> 11.0.x stable release at Community Over Code in Denver. If we engage
> with M&P we might even get some press out of it. (And the Apache Tomcat
> project is 25 years old this year.)
>
> Thoughts?

+1, sounds like a great plan given the timing of everything.

Rémy

> 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: [QUESTION] Purchase UML tool using Google security funding

[Rémy Maucherat]

On Tue, Aug 27, 2024 at 6:05 PM Mark Thomas  wrote:
>
> On 26/08/2024 15:41, Christopher Schultz wrote:
>
> 
>
> >> Personally, I am leaning towards spending the $99 so we can remove the
> >> watermark from the Tomcat docs.
> >
> > 1. $99 is nothing, even if it ends up being tied to a single person.
>
> I've been thinking about this some more and I'd prefer the floating
> license since that is what we really want - so anyone on the PMC can use
> it. There might be a few hoops to jump through to use it but I think it
> is worth it to ensure we can edit these docs going forward.
>
> That is $129. Which is still not very much.
>
> > 2. Maybe they would give ASF one of more licenses at no charge?
>
> I suspect not. They have a free non-commercial edition. It just adds the
> watermark.
>
> > I wouldn't want to put the burden of updating all diagrams on just one
> > committer, even if you are kind of volunteering, here.
>
> Hence my leaning more towards the floating option. While I am happy to
> do this now, should someone else need to update these diagrams a few
> years down the line I'd like everything they need to do that to be in
> the PMC private repo.
>
> There is no great rush here but I'd like to get this sorted while it is
> top of mind. Therefore, I plan to purchase 1 floating license for the
> Tomcat PMC with the Google funding early next week unless there are
> objections.

Very good idea overall, +1 for the purchase of that flexible license.

Rémy

> 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: (tomcat) branch main updated: Expected behaviour has been clarified when writing >= c-l bytes to body

[Rémy Maucherat]

On Thu, Aug 22, 2024 at 2:33 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 69eff83577 Expected behaviour has been clarified when writing >= c-l 
> bytes to body
> 69eff83577 is described below
>
> commit 69eff83577f7c00cbaaca9384ab4b1989f516797
> Author: Mark Thomas 
> AuthorDate: Thu Aug 22 13:33:10 2024 +0100
>
> Expected behaviour has been clarified when writing >= c-l bytes to body

I'm not sure yet whether this is a good idea. Usually we want to keep
things open for further processing.

Maybe we should be doing it using the suspended flag instead and in the facades.

Rémy

> ---
>  .../catalina/connector/LocalStrings.properties |  1 +
>  .../apache/catalina/connector/OutputBuffer.java| 30 ++---
>  .../catalina/connector/TestCoyoteOutputStream.java | 50 
> ++
>  3 files changed, 76 insertions(+), 5 deletions(-)
>
> diff --git a/java/org/apache/catalina/connector/LocalStrings.properties 
> b/java/org/apache/catalina/connector/LocalStrings.properties
> index 077cf46136..d20cd26bc4 100644
> --- a/java/org/apache/catalina/connector/LocalStrings.properties
> +++ b/java/org/apache/catalina/connector/LocalStrings.properties
> @@ -83,6 +83,7 @@ coyoteResponse.setBufferSize.ise=Cannot change buffer size 
> after data has been w
>  inputBuffer.requiresNonBlocking=Not available in non blocking mode
>  inputBuffer.streamClosed=Stream closed
>
> +outputBuffer.closed=The response may not be written to once it has been 
> closed
>  outputBuffer.writeNull=The String argument to write(String,int,int) may not 
> be null
>
>  request.asyncNotSupported=A filter or servlet of the current chain does not 
> support asynchronous operations.
> diff --git a/java/org/apache/catalina/connector/OutputBuffer.java 
> b/java/org/apache/catalina/connector/OutputBuffer.java
> index b185561ef3..04cf82e632 100644
> --- a/java/org/apache/catalina/connector/OutputBuffer.java
> +++ b/java/org/apache/catalina/connector/OutputBuffer.java
> @@ -358,11 +358,11 @@ public class OutputBuffer extends Writer {
>  private void writeBytes(byte b[], int off, int len) throws IOException {
>
>  if (closed) {
> -return;
> +throw new IOException(sm.getString("outputBuffer.closed"));
>  }
>
>  append(b, off, len);
> -bytesWritten += len;
> +updateBytesWritten(len);
>
>  // if called from within flush(), then immediately flush
>  // remaining bytes
> @@ -376,12 +376,12 @@ public class OutputBuffer extends Writer {
>  private void writeBytes(ByteBuffer from) throws IOException {
>
>  if (closed) {
> -return;
> +throw new IOException(sm.getString("outputBuffer.closed"));
>  }
>
>  int remaining = from.remaining();
>  append(from);
> -bytesWritten += remaining;
> +updateBytesWritten(remaining);
>
>  // if called from within flush(), then immediately flush
>  // remaining bytes
> @@ -394,6 +394,10 @@ public class OutputBuffer extends Writer {
>
>  public void writeByte(int b) throws IOException {
>
> +if (closed) {
> +throw new IOException(sm.getString("outputBuffer.closed"));
> +}
> +
>  if (suspended) {
>  return;
>  }
> @@ -403,8 +407,24 @@ public class OutputBuffer extends Writer {
>  }
>
>  transfer((byte) b, bb);
> -bytesWritten++;
> +updateBytesWritten(1);
> +}
> +
>
> +private void updateBytesWritten(int increment) throws IOException {
> +bytesWritten += increment;
> +int contentLength = coyoteResponse.getContentLength();
> +
> +/*
> + * Handle the requirements of section 5.7 of the Servlet 
> specification - Closure of the Response Object.
> + *
> + * Currently this just handles the simple case. There is work in 
> progress to better define what should happen if
> + * an attempt is made to write > content-length bytes. When that 
> work is complete, this is likely where the
> + * implementation will end up.
> + */
> +if (contentLength != -1 && bytesWritten >= contentLength) {
> +close();
> +}
>  }
>
>
> diff --git a/test/org/apache/catalina/connector/TestCoyoteOutputStream.java 
> b/test/org/apache/catalina/connector/TestCoyoteOutputStream.java
> index d808db76f7..bf282f5d67 100644
> --- a/test/org/apache/catalina/connector/TestCoyoteOutputStream.java
> +++ b/test/org/apache/catalina/connector/TestCoyoteOutputStream.java
> @@ -21,6 +21,7 @@ import java.io.IOException;
>  import java.io.RandomAccessFile;
>  import java.nio.channels.FileChannel.MapMode;
>  import java.nio.charset.StandardCharsets;
> +import java.util.conc

Re: Cookie parsing and upcoming updates to RFC6265

[Rémy Maucherat]

On Fri, Aug 16, 2024 at 5:25 PM Mark Thomas  wrote:
>
> On 16/08/2024 13:40, Tim Funk wrote:
> > How about  missingEqualsCookie="allow | ignore"?
>
> The proposed options were:
> - ignore
> - name
> - value

Ok, I think your proposed options are very good. Thanks for the
summary. Personally I would have interpreted these as name rather than
value, so it helped clarify.

I also think you are right about not changing the behavior for current
branches. It could be changed to ignore already in 11, and we could
see if people start complaining ?

Rémy

> > By using [allow | ignore] instead of yes/no, it opens the door to
> > additional behaviors. (such as reject which triggers a http error)
>
> Agreed.
>
> 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: Create a Tomcat 12 branch?

[Rémy Maucherat]

On Mon, Aug 12, 2024 at 8:30 PM Mark Thomas  wrote:
>
> All,
>
> As I mentioned earlier, I am starting work on some new EL API features
> that will be part of Jakarta EE 12 so implemented in Tomcat 12.
>
> How do we want to handle this?
>
> My current thinking is:
>
> - create a 11.0.x branch from current main
> - main becomes 12.0.x
>
> I'm not expecting releases to start from 12.0.x any time soon. Users
> that want to experiment with the new features can use snapshots. If we
> reach a point where snapshots would be useful we can re-assess.
>
> The other alternative I thought of was creating my own 12.0.x branch in
> my fork but that seems wrong.
>
> Yes, it means a little more back-porting but (for me at least) that is
> all scripted and I'm not expecting many conflicts between 12.0.x and 11.0.x.
>
> I'd update the CI systems to build 12.0.x.
>
> Part of me thinks it is a little odd to be thinking about 12.0.x before
> 11.0.x is stable but on reflection I think it is a good thing that there
> is momentum already for new features in Jakarta EE 12.
>
> Oh, there is also a small change to the Servlet API we could pick up.
>
> Thoughts?

This is unavoidable if there are already new EE features to include.
So +1

Rémy

> 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: TLD scanner and debug logging

[Rémy Maucherat]

On Tue, Aug 6, 2024 at 10:19 AM Mark Thomas  wrote:
>
> The current TLD scanner logs the following message if JARs are scanned
> but not TLDs are found:
>
> 
> At least one JAR was scanned for TLDs yet contained no TLDs. Enable
> debug logging for this logger for a complete list of JARs that were
> scanned but no TLDs were found in them. Skipping unneeded JARs during
> scanning can improve startup time and JSP compilation time.
> 
>
> However, the detailed log messages are now logged at trace level. This
> creates a couple of issues:
>
> 1. The message above is incorrect
>
> 2. With the message above corrected, and the correct logger level set,
> the messages still are not displayed because the logger handlers are
> configured to drop all messages below DEBUG level.
>
>
> I'd like to propose the following changes:
>
> - Change the default handler level to ALL. This should not change the
>current log output but should ensure messages are not dropped if a
>logger is explicitly configured to output trace (FINEST) messages.
>
> - Change the message above to say "Enable trace logging..."
>
>
> The only issue is that all the translations would need to be updated. I
> can mark them as fuzzy in POEditor which should mean they get flagged
> for review/update but whether anyone will update them is a different
> question. The alternative is to switch the TLDScanner back to logging at
> debug level.
>
> Thoughts?

So I downgraded these because they did not really look like debug to
me, but more like traces. The separation between the two is quite
subtle ;) Sorry for the trouble ...

So instead of doing too much for this, and since this log is likely
useful, I would upgrade back the noTldInJar to debug since most likely
admin action is needed.

Otherwise +1 for the idea of enabling ALL by default, there would be
less fiddling around when trying to enable trace.

Rémy

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

[Rémy Maucherat]

On Mon, Aug 5, 2024 at 11:22 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> On 8/2/24 19:02, Rémy Maucherat wrote:
> > The proposed Apache Tomcat 9.0.93 release is now available for voting.
> >
> > The notable changes compared to 9.0.91 are:
> >
> > - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
> > and response processing objects by default. This behaviour can be
> > controlled via the new discardRequestsAndResponses attribute on the
> > HTTP/2 upgrade protocol.
> >
> > - Add OpenSSL support for FFM. Using this feature requires Java 22
> > or newer.
> >
> > - Add support for RFC 8297 (Early Hints). Applications can use this
> > feature by casting the HttpServletResponse to
> > org.apache.catalina.connector.Reponse and then calling the method
> > void sendEarlyHints()
> >
> > 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.93/
> >
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1510
> >
> > The tag is:
> > https://github.com/apache/tomcat/tree/9.0.93
> > a33d708d9b078e0d7bc8abda91c8634c4f338d99
> >
> > The proposed 9.0.93 release is:
> > [ ] -1, Broken - do not release
> > [ ] +1, Stable - go ahead and release as 9.0.93
>
> +1 for stable release.
>
> Build is reproducible and the unit tests pass on MacOS x86-64.
>
> I still see a weird difference in the -fulldocs package that do not make
> any sense to me:
>
> In the file list:
> │ │ --rw-r--r--   000  9426093 2024-08-02
> 21:24:59.00 tomcat-9.0-doc/api/index-all.html
> │ │ +-rw-r--r--   000  9426102 2024-08-02
> 21:24:59.00 tomcat-9.0-doc/api/index-all.html
>
> In the file index-all.html:
> │ │ - href="org/apache/tomcat/util/compat/Jre22Compat.html#addBootModulePath(java.util.Deque)"
> class="member-name-link">addBootModulePath(Deque<URL>) -
> Method in class org.apache.tomcat.util.compat. href="org/apache/tomcat/util/compat/Jre22Compat.html" title="class in
> org.apache.tomcat.util.compat">Jre22Compat
> │ │ + href="org/apache/tomcat/util/compat/Jre19Compat.html#addBootModulePath(java.util.Deque)"
> class="member-name-link">addBootModulePath(Deque<URL>) -
> Method in class org.apache.tomcat.util.compat. href="org/apache/tomcat/util/compat/Jre19Compat.html" title="class in
> org.apache.tomcat.util.compat">Jre19Compat
>
> The "left file" is the one I generated locally while the "right file" is
> the release artifact. So my build uses Jre22Compat in this javadoc file
> while yours references Jre19Compat.
>
> The file tomcat-9.0-doc/api/member-search-index.js has a similar
> exchange of Jre22Compat for Jre19Compat.

Neither option seems particularly wrong to me here.

> Note that I am using the same 17.0.12+7 compiler you are using plus Java
> 22.0.2 for the FFM bits. The details below are for my fully-automated
> tests which always use my latest JRE for everything.

Only the main Java is used for javadoc.

Rémy

> I am seeing some unit tests skipped that I am not expecting to be
> skipped. I wonder if my native components builds are working as expected.
>
> Details:
>
> * Environment
> *  Testing Apache Tomcat  9.0.93
> *  Java (build):openjdk version "22.0.2" 2024-07-16 OpenJDK Runtime
> Environment Temurin-22.0.2+9 (build 22.0.2+9) OpenJDK 64-Bit Server VM
> Temurin-22.0.2+9 (build 22.0.2+9, mixed mode)
> *  Java (test): 22 ( openjdk version "22.0.2" 2024-07-16
> *  OS:  Darwin 23.5.0 x86_64
> *  cc:  Apple clang version 12.0.5 (clang-1205.0.22.9)
> *  make:GNU Make 3.81
> *  OpenSSL: OpenSSL 3.3.1 4 Jun 2024 (Library: OpenSSL 3.3.1 4
> Jun 2024)
> *  APR: 1.7.4
> *
> * Valid SHA-512 signature for apache-tomcat-9.0.93.zip
> * Valid GPG signature for apache-tomcat-9.0.93.zip
> * Valid SHA-512 signature for apache-tomcat-9.0.93.tar.gz
> * Valid GPG signature for apache-tomcat-9.0.93.tar.gz
> * Valid SHA-512 signature for apache-tomcat-9.0.93.exe
> * Valid GPG signature for apache-tomcat-9.0.93.exe
> * Valid Windows Digital Signature for apache-tomcat-9.0.93.exe
> * Valid SHA512 signature for apache-tomcat-9.0.93-src.zip
> * Valid GPG signature for apache-tomcat-9.0.93-src.zip
> * Valid SHA512 signature for apache-tomcat-9.0.93-src.tar.gz
> * Valid GPG signature fo

[ANN] Apache Tomcat 9.0.93 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.93.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.93 is a bugfix and feature release. The notable
changes compared to 9.0.91 include:

- Align HTTP/2 with HTTP/1.1 and recycle the container internal request
   and response processing objects by default. This behaviour can be
   controlled via the new discardRequestsAndResponses attribute on the
   HTTP/2 upgrade protocol.

- Add OpenSSL support for FFM. Using this feature requires Java 22
   or newer.

- Add support for RFC 8297 (Early Hints). Applications can use this
   feature by casting the HttpServletResponse to
   org.apache.catalina.connector.Reponse and then calling the method
   void sendEarlyHints().

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE][RESULT] Release Apache Tomcat 9.0.93

[Rémy Maucherat]

The following votes were cast:

Binding:
+1: isapir, remm, rjung, funkman, markt, schultz

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

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

[Rémy Maucherat]

On Fri, Aug 2, 2024 at 7:28 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 10.1.28 release is now available for
> voting.
>
> All committers and PMC members are kindly requested to provide a vote if
> possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes are
> binding. We welcome non-committer votes or comments on release builds.
>
> Note that release 10.1.27 was cancelled due to a regression to HTTP/2
> handling. That regression has been fixed in this release along with
> these additional items:
>
> The notable changes compared to 10.1.26 are:
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Ensure statements returned from Statement methods executeQuery(),
>getResultSet() and getGeneratedKeys() are correctly wrapped before
>being returned to the caller.
>
> 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.28/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1508
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.28
> https://github.com/apache/tomcat/commit/aae1e30f78ba5ace25848084a500662ecff0b75f
>
> Please reply with a +1 for release or +0/-0/-1 with an explanation.

+1

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 11.0.0-M24

[Rémy Maucherat]

On Fri, Aug 2, 2024 at 4:15 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 11.0.0-M24 release is now available for
> voting.
>
> Apache Tomcat 11.0.0-M24 is a 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 11.0.0-M22 include:
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Add FFM compatibility methods for LibreSSL and BoringSSL support.
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> 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-M24/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1507
>
> The tag is:
> https://github.com/apache/tomcat/tree/11.0.0-M24
> 5301df36454fcf22081108e25199f29904cadc79
>
> The proposed 11.0.0-M24 release is:
> [ ] -1 Broken - do not release
> [X] +1 Beta   - go ahead and release as 11.0.0-M24

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.93

[Rémy Maucherat]

On Sat, Aug 3, 2024 at 1:02 AM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.93 release is now available for voting.
>
> The notable changes compared to 9.0.91 are:
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Add OpenSSL support for FFM. Using this feature requires Java 22
>or newer.
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> 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.93/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1510
>
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.93
> a33d708d9b078e0d7bc8abda91c8634c4f338d99
>
> The proposed 9.0.93 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.93

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE] Release Apache Tomcat 9.0.93

[Rémy Maucherat]

The proposed Apache Tomcat 9.0.93 release is now available for voting.

The notable changes compared to 9.0.91 are:

- Align HTTP/2 with HTTP/1.1 and recycle the container internal request
   and response processing objects by default. This behaviour can be
   controlled via the new discardRequestsAndResponses attribute on the
   HTTP/2 upgrade protocol.

- Add OpenSSL support for FFM. Using this feature requires Java 22
   or newer.

- Add support for RFC 8297 (Early Hints). Applications can use this
   feature by casting the HttpServletResponse to
   org.apache.catalina.connector.Reponse and then calling the method
   void sendEarlyHints()

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.93/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1510

The tag is:
https://github.com/apache/tomcat/tree/9.0.93
a33d708d9b078e0d7bc8abda91c8634c4f338d99

The proposed 9.0.93 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.93

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.92

[Rémy Maucherat]

On Tue, Jul 30, 2024 at 5:32 AM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.92 release is now available for voting.
>
> The notable changes compared to 9.0.91 are:
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Add OpenSSL support for FFM. Using this feature requires Java 22
>or newer.
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> 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.92/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1505
>
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.92
> b6ca266795a4245f3c3308a619987136ad46e19a
>
> The proposed 9.0.92 release is:
> [ ] -1, Broken - do not release
> [ ] +1, Stable - go ahead and release as 9.0.92

The vote is cancelled due to HTTP/2 regressions.

Rémy

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

[Rémy Maucherat]

On Tue, Jul 30, 2024 at 5:57 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 10.1.27 release is now available for
> voting.
>
> All committers and PMC members are kindly requested to provide a vote if
> possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes are
> binding. We welcome non-committer votes or comments on release builds.
>
> The notable changes compared to 10.1.26 are:
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Ensure statements returned from Statement methods executeQuery(),
>getResultSet() and getGeneratedKeys() are correctly wrapped before
>being returned to the caller.
>
> 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.27/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1506
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.27
> https://github.com/apache/tomcat/commit/50d264f3bc6c8595a1e611940668fb46d076e0ba
>
> Please reply with a +1 for release or +0/-0/-1 with an explanation.

+1, no issue with this round of releases.

Rémy

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

[Rémy Maucherat]

On Tue, Jul 30, 2024 at 7:06 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> Thanks for RMing.
>
> On 7/29/24 11:32 PM, Rémy Maucherat wrote:
> > The proposed Apache Tomcat 9.0.92 release is now available for voting.
> >
> > The notable changes compared to 9.0.91 are:
> >
> > - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
> > and response processing objects by default. This behaviour can be
> > controlled via the new discardRequestsAndResponses attribute on the
> > HTTP/2 upgrade protocol.
> >
> > - Add OpenSSL support for FFM. Using this feature requires Java 22
> > or newer.
> >
> > - Add support for RFC 8297 (Early Hints). Applications can use this
> > feature by casting the HttpServletResponse to
> > org.apache.catalina.connector.Reponse and then calling the method
> > void sendEarlyHints()
> >
> > 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.92/
> >
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1505
> >
> > The tag is:
> > https://github.com/apache/tomcat/tree/9.0.92
> > b6ca266795a4245f3c3308a619987136ad46e19a
> >
> > The proposed 9.0.92 release is:
> > [ ] -1, Broken - do not release
> > [ ] +1, Stable - go ahead and release as 9.0.92
>
> +1 for stable release.
>
> The build is reproducible[*] and the unit tests pass on MacOS x86-64.
>
> [*] The fulldocs package is not identical. Usually this is because of
> LICENSE files and stuff like that, but this is not the case this time.
> Instead, the documentation is actually different. My locally-built
> fulldocs package includes references to the Jre22Compat class while
> yours includes references to the Jre19Compat class and some other
> semingly-related differences.

The fulldocs at
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.92/bin/apache-tomcat-9.0.92-fulldocs.tar.gz
does have Jre22Compat. Jre19Compat has not been removed.

Rémy

>
> Since the fulldocs package is not executable, I don't think there is any
> reason to block the release.
>
> Works with a vanilla servlet-based application in a development environment.
>
> Details:
> * Environment
> *  Java (build):openjdk version "22.0.1" 2024-04-16 OpenJDK Runtime
> Environment Temurin-22.0.1+8 (build 22.0.1+8) OpenJDK 64-Bit Server VM
> Temurin-22.0.1+8 (build 22.0.1+8, mixed mode)
> *  Java (test): openjdk version "22.0.1" 2024-04-16 OpenJDK Runtime
> Environment Temurin-22.0.1+8 (build 22.0.1+8) OpenJDK 64-Bit Server VM
> Temurin-22.0.1+8 (build 22.0.1+8, mixed mode)
> *  Ant: Apache Ant(TM) version 1.10.14 compiled on August 16
> 2023
> *  OS:  Darwin 21.6.0 x86_64
> *  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
> *  make:GNU Make 3.81
> *  OpenSSL: OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30
> Jan 2024)
> *  APR: 1.7.4
> *
> * Valid SHA-512 signature for apache-tomcat-9.0.92.zip
> * Valid GPG signature for apache-tomcat-9.0.92.zip
> * Valid SHA-512 signature for apache-tomcat-9.0.92.tar.gz
> * Valid GPG signature for apache-tomcat-9.0.92.tar.gz
> * Valid SHA-512 signature for apache-tomcat-9.0.92.exe
> * Valid GPG signature for apache-tomcat-9.0.92.exe
> * Valid SHA512 signature for apache-tomcat-9.0.92-src.zip
> * Valid GPG signature for apache-tomcat-9.0.92-src.zip
> * Valid SHA512 signature for apache-tomcat-9.0.92-src.tar.gz
> * Valid GPG signature for apache-tomcat-9.0.92-src.tar.gz
> *
> * Binary Zip and tarball: Same
> * Source Zip and tarball: Same
> *
> * Building dependencies returned: 0
> * tcnative builds cleanly
> * Tomcat builds cleanly
> * Junit Tests: PASSED
>
>
> -
> 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 11.0.0-M23

[Rémy Maucherat]

On Mon, Jul 29, 2024 at 8:27 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 11.0.0-M23 release is now available for
> voting.
>
> Apache Tomcat 11.0.0-M23 is a 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 the previous milestone include:
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Add FFM compatibility methods for LibreSSL and BoringSSL support.
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> 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-M23/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1504
>
> The tag is:
> https://github.com/apache/tomcat/tree/11.0.0-M23
> 2bf2c6a691ad9f2cf68363123419909cebbb308a
>
> The proposed 11.0.0-M23 release is:
> [ ] -1 Broken - do not release
> [X] +1 Beta   - go ahead and release as 11.0.0-M23

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.92

[Rémy Maucherat]

On Tue, Jul 30, 2024 at 5:32 AM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.92 release is now available for voting.
>
> The notable changes compared to 9.0.91 are:
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Add OpenSSL support for FFM. Using this feature requires Java 22
>or newer.
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> 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.92/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1505
>
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.92
> b6ca266795a4245f3c3308a619987136ad46e19a
>
> The proposed 9.0.92 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.92

For building a release, don't forget to set the "java-ffm.home"
property in build.properties. This then gets documented in
build.properties.release: # Javac with FFM version: javac 22.0.2
So I used Java 22.0.2 there.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE] Release Apache Tomcat 9.0.92

[Rémy Maucherat]

The proposed Apache Tomcat 9.0.92 release is now available for voting.

The notable changes compared to 9.0.91 are:

- Align HTTP/2 with HTTP/1.1 and recycle the container internal request
   and response processing objects by default. This behaviour can be
   controlled via the new discardRequestsAndResponses attribute on the
   HTTP/2 upgrade protocol.

- Add OpenSSL support for FFM. Using this feature requires Java 22
   or newer.

- Add support for RFC 8297 (Early Hints). Applications can use this
   feature by casting the HttpServletResponse to
   org.apache.catalina.connector.Reponse and then calling the method
   void sendEarlyHints()

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.92/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1505

The tag is:
https://github.com/apache/tomcat/tree/9.0.92
b6ca266795a4245f3c3308a619987136ad46e19a

The proposed 9.0.92 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.92

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 11.0.0-M23

[Rémy Maucherat]

On Mon, Jul 29, 2024 at 8:27 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 11.0.0-M23 release is now available for
> voting.
>
> Apache Tomcat 11.0.0-M23 is a 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 the previous milestone include:
>
> - Align HTTP/2 with HTTP/1.1 and recycle the container internal request
>and response processing objects by default. This behaviour can be
>controlled via the new discardRequestsAndResponses attribute on the
>HTTP/2 upgrade protocol.
>
> - Add FFM compatibility methods for LibreSSL and BoringSSL support.
>
> - Add support for RFC 8297 (Early Hints). Applications can use this
>feature by casting the HttpServletResponse to
>org.apache.catalina.connector.Reponse and then calling the method
>void sendEarlyHints()
>
> 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-M23/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1504

The Maven repository has not been closed so it is not accessible.

Rémy

> The tag is:
> https://github.com/apache/tomcat/tree/11.0.0-M23
> 2bf2c6a691ad9f2cf68363123419909cebbb308a
>
> The proposed 11.0.0-M23 release is:
> [ ] -1 Broken - do not release
> [ ] +1 Beta   - go ahead and release as 11.0.0-M23
>
> -
> 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: Simplifying JreCompat

[Rémy Maucherat]

On Thu, Jul 25, 2024 at 10:34 PM Mark Thomas  wrote:
>
> As per Rémy's suggestion, I've been looking simplifying JreCompat to
> only support LTS versions and anything more recent than the newest LTS.
>
> That would mean:
> - Tomcat 9 only
>- Jre9Compat is renamed to Jre11Compat
> - Tomcat 9 and 10
>- Jre16Compat is renamed to Jre17Compat
> - All versions
>- Jre18Compat and Jre19Compat are merged into the existing Jre21Compat
>
> Jre22Compat would be unchanged.
>
> So the only real change is merging Jre18Compat, Jre19Compat and
> Jre21Compat into a single, larger Jre21Compat.
>
> I'm on the fence as to whether this is worth doing. Thoughts?

Changing the existing does not seem that worthwhile. I sent the idea
because adding a Java 18 class now seemed weird.

Remy

> 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: (tomcat) 01/03: Add JreCompat support for Subject.callAs()

[Rémy Maucherat]

On Thu, Jul 25, 2024 at 10:44 AM  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
>
> commit a2384804c527c64290cfae1fa988f1f394890e91
> Author: Mark Thomas 
> AuthorDate: Wed Jul 24 17:51:24 2024 +0100
>
> Add JreCompat support for Subject.callAs()
>
> With the changes coming in Java 23 we need to move away from
> Subject.doAs() but the replacement isn't available in Java 17. Hence use
> JreCompat.
> ---
>  .../org/apache/tomcat/util/compat/Jre18Compat.java | 71 
> ++

This could be needlessly fancy to add this now. Maybe JreCompat could
be rounded up to the next LTS once they are released. Nobody is going
to use 18 or 19 anymore (21 will be used instead).

Rémy

>  .../org/apache/tomcat/util/compat/Jre19Compat.java |  2 +-
>  java/org/apache/tomcat/util/compat/JreCompat.java  | 39 
>  .../tomcat/util/compat/LocalStrings.properties |  1 +
>  4 files changed, 112 insertions(+), 1 deletion(-)
>
> diff --git a/java/org/apache/tomcat/util/compat/Jre18Compat.java 
> b/java/org/apache/tomcat/util/compat/Jre18Compat.java
> new file mode 100644
> index 00..b83999f179
> --- /dev/null
> +++ b/java/org/apache/tomcat/util/compat/Jre18Compat.java
> @@ -0,0 +1,71 @@
> +/*
> + *  Licensed to the Apache Software Foundation (ASF) under one or more
> + *  contributor license agreements.  See the NOTICE file distributed with
> + *  this work for additional information regarding copyright ownership.
> + *  The ASF licenses this file to You under the Apache License, Version 2.0
> + *  (the "License"); you may not use this file except in compliance with
> + *  the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + *  Unless required by applicable law or agreed to in writing, software
> + *  distributed under the License is distributed on an "AS IS" BASIS,
> + *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + *  See the License for the specific language governing permissions and
> + *  limitations under the License.
> + */
> +package org.apache.tomcat.util.compat;
> +
> +import java.lang.reflect.InvocationTargetException;
> +import java.lang.reflect.Method;
> +import java.util.concurrent.Callable;
> +import java.util.concurrent.CompletionException;
> +
> +import javax.security.auth.Subject;
> +
> +import org.apache.juli.logging.Log;
> +import org.apache.juli.logging.LogFactory;
> +import org.apache.tomcat.util.res.StringManager;
> +
> +public class Jre18Compat extends JreCompat {
> +
> +private static final Log log = LogFactory.getLog(Jre18Compat.class);
> +private static final StringManager sm = 
> StringManager.getManager(Jre18Compat.class);
> +
> +private static final Method callAsMethod;
> +
> +static {
> +Method m1 = null;
> +
> +try {
> +m1 = Subject.class.getMethod("classAS", Subject.class, 
> Callable.class);
> +} catch (NoSuchMethodException e) {
> +// Must before-Java 18
> +log.debug(sm.getString("jre18Compat.javaPre18"), e);
> +}
> +
> +callAsMethod = m1;
> +}
> +
> +
> +static boolean isSupported() {
> +return callAsMethod != null;
> +}
> +
> +
> +@SuppressWarnings("unchecked")
> +@Override
> +public  T callAs(Subject subject, Callable action) throws 
> CompletionException {
> +try {
> +return (T) callAsMethod.invoke(null, subject, action);
> +} catch (IllegalAccessException e) {
> +throw new CompletionException(e);
> +} catch (InvocationTargetException e) {
> +Throwable cause = e.getCause();
> +if (cause instanceof CompletionException) {
> +throw (CompletionException) cause;
> +}
> +throw new CompletionException(e);
> +}
> +}
> +}
> diff --git a/java/org/apache/tomcat/util/compat/Jre19Compat.java 
> b/java/org/apache/tomcat/util/compat/Jre19Compat.java
> index 60ee0c2dc1..fd9b85c515 100644
> --- a/java/org/apache/tomcat/util/compat/Jre19Compat.java
> +++ b/java/org/apache/tomcat/util/compat/Jre19Compat.java
> @@ -22,7 +22,7 @@ import org.apache.juli.logging.Log;
>  import org.apache.juli.logging.LogFactory;
>  import org.apache.tomcat.util.res.StringManager;
>
> -public class Jre19Compat extends JreCompat {
> +public class Jre19Compat extends Jre18Compat {
>
>  private static final Log log = LogFactory.getLog(Jre19Compat.class);
>  private static final StringManager sm = 
> StringManager.getManager(Jre19Compat.class);
> diff --git a/java/org/apache/tomcat/util/compat/JreCompat.java 
> b/java/org/apache/tomcat/util/compat/JreCompat.java
> index 743f76e64f..9227c2deac 100644
> --- a/java/org/apache/tomcat/util/compat/JreCompat.java
> +++ b/java/org/apache/tomcat/util/compat/JreC

Re: Performance improvements for HTTP/2

[Rémy Maucherat]

On Wed, Jul 24, 2024 at 8:31 AM Mark Thomas  wrote:
>
> On 23/07/2024 21:30, Christopher Schultz wrote:
> > Mark,
> >
> > On 7/23/24 13:13, Mark Thomas wrote:
> >> Prompted by some folks at $dayjob, I have been looking at the
> >> performance of Tomcat's HTTP/2 implementation using [1]
> >>
> >> Initially, I was seeing ~79k req/s.
> >>
> >> Restoring lazy init for the StreamInputBuffer increased that to ~106k
> >> req/s.
> >
> > O_O
> >
> >> Moving the HttpParser from Processor to Protocol increased that to
> >> ~108k req/s.
> >>
> >> Now I am looking at recycling and reusing the coyote request and
> >> response. That increases throughput to 124k req/s.
> >
> > This information would be good to put (with a datestamp and
> > environmental details) into the documentation for discardFacades and/or
> > similar capabilities.
> >
> > In Bratislava, we idly speculated that "throwing those objects away
> > should not affect performance much and improve security" but if it
> > really is a 15% speed improvement, it might be really critical for some
> > applications.
>
> It really does depend on which objects you are talking about. Looking at
> the flame graph for HTTP/2, it appears that the objects that require the
> creation of buffers are the expensive ones to create. I thought we were
> talking about the (inexpensive) facades in Bratislava.
>
> Someone (I forget who) tested the performance impact of not recycling
> the processors and it was horrible.

That would be me.

> >> Given the significant performance increase I am considering the
> >> following:
> >> - switching HTTP/2 to recycle and reuse coyote request and response
> >>objects by default
> >
> > Note that we just changed that default in the other direction for
> > HTTP/1.1. I think we should probably be consistent.
>
> I think you might be getting your objects mixed up. There are three sets:
> a) coyote request/response
> b) catalina request/response
> c) catalina request/response facade
>
> Currently HTTP/2 recreates all of the above for every stream.
>
> HTTP/1.1 always recycles and re-uses a) and b). It is c) that we changed
> to always create new objects by default for 9.0.x (to align with 10.1.x
> and 11.0.x).
>
> This proposal would align HTTP/2 with HTTP/1.1 and recycle and re-use a)
> and b) by default but with an option to re-create every time (mainly in
> case there is a regression due to an application and/or Tomcat issue).

+1

> >> - providing an option to restore the current behaviour of creating a new
> >>coyote request and response object for every HTTP/2 stream
> >
> > +1 but with a different default.
>
> If that is for alignment with HTTP/1.1 then I disagree. We should
> recycle and re-use a) and b). If it is to avoid possible regressions
> then I think there is a discussion to be had due to the the performance
> benefits vs regression risk trade off.

+1
Having the extra setting is good, but there's no huge incentive for it
to be the default.

Rémy

> 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: Performance improvements for HTTP/2

[Rémy Maucherat]

On Tue, Jul 23, 2024 at 7:15 PM Mark Thomas  wrote:
>
> Prompted by some folks at $dayjob, I have been looking at the
> performance of Tomcat's HTTP/2 implementation using [1]
>
> Initially, I was seeing ~79k req/s.
>
> Restoring lazy init for the StreamInputBuffer increased that to ~106k req/s.
>
> Moving the HttpParser from Processor to Protocol increased that to ~108k
> req/s.
>
> Now I am looking at recycling and reusing the coyote request and
> response. That increases throughput to 124k req/s.

Big difference, not surprising it is quite similar to the difference
seen with HTTP/1.1 when trying to drop reuse.

> Given the significant performance increase I am considering the following:
> - switching HTTP/2 to recycle and reuse coyote request and response
>objects by default
> - providing an option to restore the current behaviour of creating a new
>coyote request and response object for every HTTP/2 stream
>
> Thoughts?

+1, great !

Rémy

> Mark
>
>
> [1] https://github.com/sdeleuze/spring-boot-http2
>
> -
> 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: TCK CI runs

[Rémy Maucherat]

On Mon, Jul 22, 2024 at 6:54 PM Mark Thomas  wrote:
>
> All,
>
> Today I have configured the tomcat-tck repository to run the EL,
> Servlet, Pages and WebSocket TCKs once every day for all combinations of
> JDK 17 & 21, Ubuntu latest, MacOS latest and Windows latest using GitHub
> actions.
>
> There were a few issues to iron out but these should now all be resolved.
>
> The TCK will run at just after 08.00 UTC every day and it will use the
> latest Tomcat 11 SNAPSHOT (these are updated on every commit by buildbot).
>
> Windows seems to take a little longer than the others but the full TCK
> run (all four TCKs) is complete in just under 25 minutes. Considering it
> used to take longer than that to run any of the old TCKs, kudos to the
> Jakarta EE folks that have been working on the refactoring.

I'm on vacation right now (and sick too ;) ), so I apologize for not
immediately chiming in on this one. Congrats on this amazing
achievement !
Running the TCK was indeed extremely annoying and resource intensive ...

> Tomcat 11.0.x currently passes the TCK (as it should).
>
> I have no plans to formally certify Tomcat as passing the TCK over and
> above what I have already completed as part of the release process for
> each of the specifications (the specification release process requires
> at least one compatible implementation).

+1, no extra steps needed IMO. Getting the logo simply for a handful
of specs is a bit "meh".

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Short and long term plans for Tomcat Native

[Rémy Maucherat]

On Thu, Jul 18, 2024 at 2:41 PM Rainer Jung  wrote:
>
> Am 18.07.24 um 14:15 schrieb Michael Osipov:
> > On 2024/07/17 15:33:02 Mark Thomas wrote:
> >> All,
> >>
> >> I've spent some time today trying to build Tomcat Native with Visual
> >> Studio 2022 rather then the current, more involved process without success.
> >>
> >> Therefore, my short-term plan for Tomcat Native is to get the next 2.0.x
> >> and 1.3.x releases completed using the existing build process. I'll be
> >> starting that shortly.
> >>
> >> Longer term, thinking about Tomcat Native and FFM I have the following
> >> rough plan in mind:
> >>
> >> - stop providing x86 binaries for Windows
> >> - require Windows 10 onwards
> >> - provide:
> >> - libssl.dll
> >> - libcrypto.dll
> >> - tomcat-native-2.dll
> >> - openssl.exe
> >>
> >> along with appropriate debug symbols.
> >
> > This sounds reasonable...but did you rename tcnative on purpose?
> >
> >> I'm not sure if we'd need an apr.dll in there as well.
> >>
> >> The idea is that users can then use either the AprLifecycleListener or
> >> OpenSSLLifecycleListener.
> >>
> >> This would probably require moving Tomcat Native to 2.1.x and 1.4.x
> >>
> >> This really needs someone more familiar with building C libraries
> >> generally and these libraries in particular - i.e. Mladen - to say
> >> whether the above is possible and to provide some pointers on how to do it.
> >
> > I would prefer that all APR-related stuff in the build is also removed in 
> > 2.1.x. Why does one need it if it is not used? That is weird.
>
> I'll try to clarify a few things: we have a few different cases where
> native libraries are used. Please correct me where I am wrong:
>
> - the APR connector; only supported in TC 9.0. Implemented via tcnative
> 1.3. Needs code from tcnative and the APR libraries.
>
> - doing OpenSSL crypto instead of JSSE crypto in a connector using
> tcnative. supported in TC 9+; Implemented via tcnative 1.3 and 2.0.
> Needs code from tcnative, the APR library and the OpenSSL library. The
> APR library is needed, because tcnative uses the memory pool
> implementation of APR for its own memory management.
>
> - doing OpenSSL crypto instead of JSSE crypto in a connector using the
> new Java 22+ foreign function interface. Supported in TC 10.1+;
> Implemented via FFM plus OpenSSL library. Only needs code from the
> OpenSSL library.

I was able to port the FFM support to Tomcat 9.0 (will be in 9.0.92)
with very little actual trouble, along with all the improvements in
TLS testing from 10.1. As suggested by someone (can't remember who,
maybe you ?), Ant's javac task allows specifying another javac
executable and it worked well to solve the blocker issue about the
Java 8 release target.
This really improves the long term support prospects for 9.0 as far as
I am concerned.

Rémy


> Concerning the existence of explicit separate libapr, libcrypto and
> libssl dll files in the tcnative binary distribution for Windows: I
> expect one can decide during copilation, which of these libraries will
> be kept separate as dynmic library files and linked in dynamically and
> which of them get linked in statically, so that no separate file needs
> to be shipped.
>
> It seems until 2.0.7 (8?) and 1.3.0 (1?) we link in the apr, crypto and
> ssl libs statically, so no separate dll files are shipped.
>
> Marks suggestion indicates that he suggests to link the two OpenSSL libs
> dynamically and ship the crypto and ssl libs them bundled but keep the
> apr lib linked statically, so no separate dll file for it.
>
> Best regards,
>
> Rainer
>
> -
> 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 Native 1.3.1

[Rémy Maucherat]

On Thu, Jul 18, 2024 at 12:00 PM Mark Thomas  wrote:
>
> The key differences compared to 1.3.0 are:
>
> - Fix a crash on Windows when SSLContext.setCACertificate() is invoked
>with a null value for caCertificateFile and a non-null value for
>caCertificatePath
> - The windows binaries in this release have been built with OpenSSL
>3.0.14 and APR 1.7.4
>
> The proposed release artifacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.3.1 release is
>   [X] Stable, go ahead and release
>   [ ] Broken because of ...

APR and NIO/OpenSSL tests work fine on Tomcat 9.

Rémy

> Thanks,
>
> Mark
>
>
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.3.1
> [2]
> https://github.com/apache/tomcat-native/commit/0d6da8c122e88bba17bf49d0ada443311b2baab6
>
> -
> 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 Native 2.0.8

[Rémy Maucherat]

On Wed, Jul 17, 2024 at 9:52 PM Mark Thomas  wrote:
>
> The key differences of version 2.0.8 compared to 2.0.7 are:
>
> - Fix a crash on Windows when SSLContext.setCACertificate() is invoked
>with a null value for caCertificateFile and a non-null value for
>caCertificatePath
> - The windows binaries in this release have been built with OpenSSL
>3.0.14 and APR 1.7.4
>
> The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
> onwards but can be used with earlier versions as long as the APR/native
> connector is not used.
>
> The proposed release artifacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 2.0.8 release is
>   [X] Stable, go ahead and release
>   [ ] Broken because of ...

Rémy

> Thanks,
>
> Mark
>
>
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.8
> [2]
> https://github.com/apache/tomcat-native/commit/da9d510960b8cef95359b08b30ec1dba995183eb
>
> -
> 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: Short and long term plans for Tomcat Native

[Rémy Maucherat]

On Wed, Jul 17, 2024 at 5:34 PM Mark Thomas  wrote:
>
> All,
>
> I've spent some time today trying to build Tomcat Native with Visual
> Studio 2022 rather then the current, more involved process without success.
>
> Therefore, my short-term plan for Tomcat Native is to get the next 2.0.x
> and 1.3.x releases completed using the existing build process. I'll be
> starting that shortly.

+1

> Longer term, thinking about Tomcat Native and FFM I have the following
> rough plan in mind:
>
> - stop providing x86 binaries for Windows
> - require Windows 10 onwards
> - provide:
>- libssl.dll
>- libcrypto.dll
>- tomcat-native-2.dll
>- openssl.exe
>
> along with appropriate debug symbols.
>
> I'm not sure if we'd need an apr.dll in there as well.
>
> The idea is that users can then use either the AprLifecycleListener or
> OpenSSLLifecycleListener.

I see the current windows binary contains openssl.exe and a statically
linked tcnative-1.dll (or -2). Indeed, providing the various separate
.dll gives more flexibility. Not sure about APR (but since it is used,
it would also need to be a .dll like the rest most likely) ...

> This would probably require moving Tomcat Native to 2.1.x and 1.4.x
>
> This really needs someone more familiar with building C libraries
> generally and these libraries in particular - i.e. Mladen - to say
> whether the above is possible and to provide some pointers on how to do it.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: (tomcat) branch main updated: Fix regression calling add-osgi

[Rémy Maucherat]

On Tue, Jul 16, 2024 at 12:39 PM Mark Thomas  wrote:
>
> On 16/07/2024 10:40, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm 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 a4d3724c25 Fix regression calling add-osgi
> > a4d3724c25 is described below
> >
> > commit a4d3724c25a79ea7f0ebb4ccfb055d576da54789
> > Author: remm 
> > AuthorDate: Tue Jul 16 11:40:19 2024 +0200
> >
> >  Fix regression calling add-osgi
>
> (and setup-bnd - the module-info.class was also missing)
>
> >
> >  Unless means not set at all, evaluating to false is not the same.
>
> We could use:
>
> unless="${skip.build.java.version}"
>
> which does check for skip.build.java.version being set to true.
>
> Changing add-osgi and setup-bnd to use that form should give consistent
> behaviour whether the property is set or not.
>
> If there are no objections, I'll make that change.

Given this unfortunate regression (sorry ...), would it be a good idea
to start the release process for the "August" releases a bit ahead of
schedule ?

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: (tomcat) branch main updated: Fix regression calling add-osgi

[Rémy Maucherat]

On Tue, Jul 16, 2024 at 12:39 PM Mark Thomas  wrote:
>
> On 16/07/2024 10:40, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm 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 a4d3724c25 Fix regression calling add-osgi
> > a4d3724c25 is described below
> >
> > commit a4d3724c25a79ea7f0ebb4ccfb055d576da54789
> > Author: remm 
> > AuthorDate: Tue Jul 16 11:40:19 2024 +0200
> >
> >  Fix regression calling add-osgi
>
> (and setup-bnd - the module-info.class was also missing)
>
> >
> >  Unless means not set at all, evaluating to false is not the same.
>
> We could use:
>
> unless="${skip.build.java.version}"
>
> which does check for skip.build.java.version being set to true.
>
> Changing add-osgi and setup-bnd to use that form should give consistent
> behaviour whether the property is set or not.
>
> If there are no objections, I'll make that change.

It would certainly be less error prone ...

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Security mechanisms to counter spam

[Rémy Maucherat]

On Sat, Jun 8, 2024 at 10:34 AM Rémy Maucherat  wrote:
>
> On Fri, Jun 7, 2024 at 12:23 PM Dimitris Soumis  wrote:
> >
> > Hi All,
> >
> > Due to the surge in spam BZs today, I propose implementing a security
> > mechanism to counter this issue and prevent further disruption to the
> > mailing list.
> >
> > A potential solution could include a honeypot to identify and block bots,
> > as well as a reCaptcha to verify users. Additionally, should monitor for
> > multiple requests from the same IP address and block the IP if necessary.
> >
> > Can also leverage tools like this Mozilla Bugbot Spam Detection Script
> > <https://github.com/mozilla/bugbot/blob/master/bugbot/rules/spambug.py> to
> > identify and filter out spam.
>
> One of the more ambitious proposals (which is in the wiki but has not
> yet made it to the list) is to move to Github Issues. This spamming
> might skew the discussion, but well, bad luck for BZ I guess ...

One month later, there's more and more BZ spam.
Is it time to implement the move to Github ?

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: OpenSSL alternatives using FFM

[Rémy Maucherat]

On Fri, Jul 5, 2024 at 10:55 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> On 7/4/24 09:15, Rémy Maucherat wrote:
> > As an experiment, I tested with LibreSSL and BoringSSL on LInux using
> > the FFM code. Both did not need too many API changes to start working,
> > so I committed the changes to "add support" for them.
>
> \o/
>
> I'm very happy that you have had the inclination to make this work.
> While OpenSSL is everywhere, many OSs are opting to provide "compatible"
> clones such as LibreSSL and BoringSSL and the fact is that they aren't
> 100% compatible.
>
> I'd really like to support them because that means supporting Good
> Crypto in as many places as are possible.
>
> (I'd like to see some updated performance numbers from Jean-Frederic on
> "Pure Java" TLS versus OpenSSL-based TLS. When we talked about it years
> ago it looked like there was a bug in Java preventing it from using
> hardware crypto to Java performed terribly in comparison. And of course
> used much more resources (e.g. power).

I lack the expertise in these libraries to really know what the
expected behavior is ... Insights welcome.

> > LibreSSL:
> > - I cannot get it to renegotiate anything. The client always gets a
> > "no_renegotiation" alert.
> > - Seems relatively complete.
> > - I tested with Linux and 3.9.
> > - Testing is easy on GitHub. Out of the box with macos-latest using
> > LibreSSL 3.3. Verified it does the same as my 3.9.
>
> Maybe LibreSSL refuses to renegotiate?
>
> > BoringSSL:
> > - Only TLS 1.3 "renegotiation" seems to work (TestClientCertTls13).
> > This could be seen as acceptable.
> > - It seems very bare bones, all the stuff for supporting exotic certs
> > seems to be gone. So basically you need a standard certificate doing
> > TLS 1.3 and that's all it does, but it then just works.
> > - When it doesn't like something, the client gets a connection close
> > (no alert, no nothing; I guess sending alerts is less efficient ;) ).
> > - Testing is far more problematic. The project is quite "original" in
> > that it does not do releases.  Funny (not ...).
>
> I think the above (except maybe lack of alerts) is all intentional.
> BoringSSL is intended to support "What people should be using today" and
> so it lacks all those decades of old code to support things nobody
> should be using anymore. I thought it supported TLSv1.2 though...

TLS 1.2 seems to work without renegotiation. For both TestSsl [and
also the browsers] works.

> > I don't have much experience with these so maybe I'm doing something
> > wrong. For both, the basics (TestSsl) and quite a bit more work, but
> > not everything. BoringSSL inspires more confidence in what it does and
> > how it does it than the other one, but not having releases is
> > obviously a deal breaker ...
> >
> > So I'm not very impressed. Given the amount of work it still seems
> > "ok", but that's about it, OpenSSL is by far the best choice for
> > Tomcat without even factoring in possible quic support in the future.
>
> I think michael-o has done some more elaborate testing with LibreSSL. He
> might be willing to enable FFM and put it through its paces a little
> more than you have had time for so far.

Rémy

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

[Rémy Maucherat]

On Mon, Jul 8, 2024 at 12:07 AM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 10.1.26 release is now available for
> voting.
>
> All committers and PMC members are kindly requested to provide a vote if
> possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes are
> binding. We welcome non-committer votes or comments on release builds.
>
> The notable changes compared to 10.1.25 are:
>
> - Move OpenSSL support using FFM to a separate JAR named
>tomcat-coyote-ffm.jar that advertises Java 22 in its manifest.
>
> - When using include directives in a tag file packaged in a JAR file,
>ensure that the include directives are processed correctly.
>
> - Expand the implementation of the filter value of the Authenticator
>attribute allowCorsPreflight, so that it applies to all requests that
>match the configured URL patterns for the CORS filter, rather than
>only applying if the CORS filter is mapped to /*
>
> 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.26/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1502
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.26
> https://github.com/apache/tomcat/commit/43731ff263f74ec9949a3f535fd9254baa932603
>
> Please reply with a +1 for release or +0/-0/-1 with an explanation.

+1

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [ANN] New committer: Dimitris Soumis

[Rémy Maucherat]

On Mon, Jul 8, 2024 at 12:50 PM Dimitris Soumis  wrote:
>
> Thank you very much for the warm welcome. I look forward to collaborating
> with all of you and continuing the great work that has made Tomcat a
> cornerstone project.

+1

Welcome !

Rémy

> Best regards,
>
> Dimitris
>
> On Sat, Jul 6, 2024 at 7:14 AM Igal Sapir  wrote:
>
> > Congrats Dimitris!
> >
> > Welcome to the team!
> >
> > Igal
> >
> > On Fri, Jul 5, 2024, 13:25 Mark Thomas  wrote:
> >
> > > On behalf of the Tomcat committers I am delighted to announce that
> > > Dimitris Soumis (dsoumis) has been voted in as a new Tomcat committer.
> > >
> > > Please join me in congratulating Dimitris.
> > >
> > > Kind regards,
> > >
> > > 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

[ANN] Apache Tomcat 9.0.91 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.91.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.91 is a bugfix and feature release. The notable
changes compared to 9.0.90 include:

- When using include directives in a tag file packaged in a JAR file,
   ensure that the include directives are processed correctly.

-  Expand the implementation of the filter value of the Authenticator
attribute allowCorsPreflight, so that it applies to all requests that
match the configured URL patterns for the CORS filter, rather than
only applying if the CORS filter is mapped to /*

- Add test-only build target to allow running only the testsuite, supporting
   Java versions down to the minimum supported to run Tomcat

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE][RESULT] Release Apache Tomcat 9.0.91

[Rémy Maucherat]

The following votes were cast:

Binding:
+1: remm, markt, jfclere

Non-binding
+1: dsoumis

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

OpenSSL alternatives using FFM

[Rémy Maucherat]

Hi,

As an experiment, I tested with LibreSSL and BoringSSL on LInux using
the FFM code. Both did not need too many API changes to start working,
so I committed the changes to "add support" for them.

LibreSSL:
- I cannot get it to renegotiate anything. The client always gets a
"no_renegotiation" alert.
- Seems relatively complete.
- I tested with Linux and 3.9.
- Testing is easy on GitHub. Out of the box with macos-latest using
LibreSSL 3.3. Verified it does the same as my 3.9.

BoringSSL:
- Only TLS 1.3 "renegotiation" seems to work (TestClientCertTls13).
This could be seen as acceptable.
- It seems very bare bones, all the stuff for supporting exotic certs
seems to be gone. So basically you need a standard certificate doing
TLS 1.3 and that's all it does, but it then just works.
- When it doesn't like something, the client gets a connection close
(no alert, no nothing; I guess sending alerts is less efficient ;) ).
- Testing is far more problematic. The project is quite "original" in
that it does not do releases.  Funny (not ...).

I don't have much experience with these so maybe I'm doing something
wrong. For both, the basics (TestSsl) and quite a bit more work, but
not everything. BoringSSL inspires more confidence in what it does and
how it does it than the other one, but not having releases is
obviously a deal breaker ...

So I'm not very impressed. Given the amount of work it still seems
"ok", but that's about it, OpenSSL is by far the best choice for
Tomcat without even factoring in possible quic support in the future.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.91

[Rémy Maucherat]

On Tue, Jul 2, 2024 at 3:00 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.91 release is now available for voting.
>
> The notable changes compared to 9.0.90 are:
>
> - When using include directives in a tag file packaged in a JAR file,
>ensure that the include directives are processed correctly.
>
> -  Expand the implementation of the filter value of the Authenticator
> attribute allowCorsPreflight, so that it applies to all requests that
> match the configured URL patterns for the CORS filter, rather than
> only applying if the CORS filter is mapped to /*
>
> - Add test-only build target to allow running only the testsuite, supporting
>Java versions down to the minimum supported to run Tomcat
>
> 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.91/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1500
>
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.91
> acef3172d41f18b5272fdf81da88db745669442e
>
> The proposed 9.0.91 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.91

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 11.0.0-M22

[Rémy Maucherat]

On Tue, Jul 2, 2024 at 2:01 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 11.0.0-M22 release is now available for
> voting.
>
> Apache Tomcat 11.0.0-M22 is a 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 the previous milestone include:
>
> - Move OpenSSL support using FFM to a separate JAR named
>tomcat-coyote-ffm.jar that advertises Java 22 in its manifest.
>
> - When using include directives in a tag file packaged in a JAR file,
>ensure that the include directives are processed correctly.
>
> -  Expand the implementation of the filter value of the Authenticator
> attribute allowCorsPreflight, so that it applies to all requests that
> match the configured URL patterns for the CORS filter, rather than
> only applying if the CORS filter is mapped to /*
>
>
> 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-M22/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1499
>
> The tag is:
> https://github.com/apache/tomcat/tree/11.0.0-M22
> 6c03e2dc6390ccb3dbe714889706fcad2f08f4c5
>
> The proposed 11.0.0-M22 release is:
> [ ] -1 Broken - do not release
> [X] +1 Beta   - go ahead and release as 11.0.0-M22

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE] Release Apache Tomcat 9.0.91

[Rémy Maucherat]

The proposed Apache Tomcat 9.0.91 release is now available for voting.

The notable changes compared to 9.0.90 are:

- When using include directives in a tag file packaged in a JAR file,
   ensure that the include directives are processed correctly.

-  Expand the implementation of the filter value of the Authenticator
attribute allowCorsPreflight, so that it applies to all requests that
match the configured URL patterns for the CORS filter, rather than
only applying if the CORS filter is mapped to /*

- Add test-only build target to allow running only the testsuite, supporting
   Java versions down to the minimum supported to run Tomcat

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.91/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1500

The tag is:
https://github.com/apache/tomcat/tree/9.0.91
acef3172d41f18b5272fdf81da88db745669442e

The proposed 9.0.91 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.91

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: (tomcat) branch main updated: Attempt to fix unit tests on MacOS

[Rémy Maucherat]

On Tue, Jul 2, 2024 at 9:52 AM  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 cd5051cc43 Attempt to fix unit tests on MacOS
> cd5051cc43 is described below
>
> commit cd5051cc43e4980e0b5e644cefd56ce090d5c5f1
> Author: Mark Thomas 
> AuthorDate: Tue Jul 2 08:51:44 2024 +0100
>
> Attempt to fix unit tests on MacOS

Adding support for LibreSSL might not be impossible. I'll have a look.
Their philosophy is bad for FFM however since they basically replace
API calls with macros, because they (think they) can.

Rémy

> ---
>  java/org/apache/tomcat/util/openssl/openssl_h.java | 18 +++---
>  webapps/docs/changelog.xml |  4 
>  2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/java/org/apache/tomcat/util/openssl/openssl_h.java 
> b/java/org/apache/tomcat/util/openssl/openssl_h.java
> index a8f5777bdb..d3290392a9 100644
> --- a/java/org/apache/tomcat/util/openssl/openssl_h.java
> +++ b/java/org/apache/tomcat/util/openssl/openssl_h.java
> @@ -23,6 +23,9 @@ import java.lang.invoke.MethodHandle;
>  import java.lang.invoke.MethodHandles;
>  import java.util.Arrays;
>  import java.util.stream.Collectors;
> +
> +import org.apache.tomcat.util.compat.JrePlatform;
> +
>  import java.lang.foreign.*;
>  import static java.lang.foreign.ValueLayout.*;
>
> @@ -49,9 +52,18 @@ public class openssl_h {
>  static final boolean TRACE_DOWNCALLS = 
> Boolean.getBoolean("jextract.trace.downcalls");
>  static final SymbolLookup SYMBOL_LOOKUP;
>  static {
> -SYMBOL_LOOKUP = 
> SymbolLookup.libraryLookup(System.mapLibraryName("ssl"), LIBRARY_ARENA)
> -.or(SymbolLookup.loaderLookup())
> -.or(Linker.nativeLinker().defaultLookup());
> +if (JrePlatform.IS_MAC_OS) {
> +/*
> + * On Mac OS SymbolLookup.libraryLookup() appears to ignore 
> java.library.path which means the LibreSSL
> + * library will be found which will then fail. Therefore, skip 
> that lookup on Mac OS.
> + */
> +System.loadLibrary("ssl");
> +SYMBOL_LOOKUP = 
> SymbolLookup.loaderLookup().or(Linker.nativeLinker().defaultLookup());
> +} else {
> +SYMBOL_LOOKUP = 
> SymbolLookup.libraryLookup(System.mapLibraryName("ssl"), LIBRARY_ARENA)
> +.or(SymbolLookup.loaderLookup())
> +.or(Linker.nativeLinker().defaultLookup());
> +}
>  }
>
>  static void traceDowncall(String name, Object... args) {
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index bc414180ed..be4f9bf183 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -161,6 +161,10 @@
>  tomcat-coyote-ffm.jar that advertises Java 22 in its
>  manifest. (remm)
>
> +  
> +Fix search for OpenSSL library for FFM on Mac OS so that
> +java.library.path is searched. (markt)
> +  
>  
>
>
>
>
> -
> 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: Reduce default for maxParameterCount

[Rémy Maucherat]

On Tue, Jul 2, 2024 at 1:05 PM Mark Thomas  wrote:
>
> On 02/07/2024 12:01, Michael Osipov wrote:
> > On 2024/07/02 10:33:29 Mark Thomas wrote:
> >> On 01/07/2024 07:17, Michael Osipov wrote:
>
> 
>
> >>> I would really really expect that Tomcat fails hard with 4xx if the input 
> >>> is invalid and not issue a simple INFO at the log. The huge problem is 
> >>> that the request is seen as 2xx or 3xx in the access log and if you have 
> >>> a lot of requests or forms it will be needle in the haystack to identify 
> >>> which is really the problem.
> >>> Even worse, if this has not been written by you you can play ping pong 
> >>> with the software vendor.
> >>> Therefore, I'd like all of us (committers) to reconsider this soft 
> >>> non-failing approach. It is not helpful. If the client provides garbage 
> >>> it should fail immediately.
> >>
> >> With Tomcat 11.0.x you will get a hard fail.
> >>
> >> Prior to Tomcat 11 our hands are somewhat tied by the Servlet
> >> specification since getParameter() and friends are documented to not
> >> throw an exception.
> >>
> >> We can't change the default behaviour for Tomcat versions before 11 as
> >> that runs the risk of breaking existing applications that have been
> >> designed for the current behaviour.
> >>
> >> All we can do is make that hard failure optional and it already is. For
> >> a (very) long time we have had the FailedRequestFilter for folks that
> >> wanted a hard failure if there was an issue with parameter parsing.
> >>
> >> Changing the default for maxParameterCount from 10,000 to 1,000 doesn't
> >> change this.
> >>
> >> The documentation for maxParameterCount already documents all of this.
> >>
> >> I don't see a need for any changes here.
> >
> > Thanks, I see. As a comprise would a move to WARN log message be accepted? 
> > This will at least draw people's attention. INFORMATION is just lost with 
> > other output.
>
> That seems reasonable to me.

It seems UserDataHelper needs some changes then, careful about last
minute breakage.

Rémy

> 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: (tomcat) branch main updated: Remove MacOS workaround

[Rémy Maucherat]

On Mon, Jul 1, 2024 at 5:00 PM Mark Thomas  wrote:
>
> On 28/06/2024 13:25, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm 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 61f8c08253 Remove MacOS workaround
> > 61f8c08253 is described below
> >
> > commit 61f8c08253746733f73209522f37182a9d672bd1
> > Author: remm 
> > AuthorDate: Fri Jun 28 14:24:47 2024 +0200
> >
> >  Remove MacOS workaround
>
> I'm afraid I am going to need to make further changes to this.
>
> The issue appears to be that
> SymbolLookup.libraryLookup(System.mapLibraryName("ssl"), LIBRARY_ARENA)
> ignores java.library.path
>
> That in turns causes crashes (at least in the tests) when it tries to
> load the LibreSSL implementation that ships with MacOS.
>
> I think we need to go back to the version that was MacOS specific and
> used System.loadLibrary("ssl");

Ok. After testing it didn't seem to me like it was adding anything
since it's not really a crash.

> I am also seeing an issue where the TLS 1.3 client cert test that
> requires BEFORE_INIT_EVENT to be called on the listener before the test.

Not sure I understand, the one in TestOpenSSLConf needed it, but I
didn't notice anything wrong with TestClientCertTls13. Feel free to
add it if needed.

Rémy

> I have these changes working locally on my M1 mac but they need cleaning
> up. My plan is to do the clean-up, test on my M1, commit and then test
> on MacOS Intel, Linux and 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: (tomcat) branch main updated: Try to adjust for Windows

[Rémy Maucherat]

On Fri, Jun 28, 2024 at 3:52 PM Mark Thomas  wrote:
>
> On 27/06/2024 19:27, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm 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 62567d8321 Try to adjust for Windows
> > 62567d8321 is described below
> >
> > commit 62567d8321ef8fae2f4c07d0b617281b3952ce2b
> > Author: remm 
> > AuthorDate: Thu Jun 27 20:26:59 2024 +0200
> >
> >  Try to adjust for Windows
>
> Thanks for this fix.
>
> I'm going to look and see if I can find a cleaner normalization option
> here as I am a little worried what might happen with one of the less
> common file systems.

Yes, it's a hack and I don't like it either. I caught the problem
because I was still playing with GH workflows and Windows had an
issue.

Rémy

> Mark
>
>
> > ---
> >   java/org/apache/jasper/compiler/ParserController.java | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/java/org/apache/jasper/compiler/ParserController.java 
> > b/java/org/apache/jasper/compiler/ParserController.java
> > index b35f58331d..2d89348a1e 100644
> > --- a/java/org/apache/jasper/compiler/ParserController.java
> > +++ b/java/org/apache/jasper/compiler/ParserController.java
> > @@ -533,7 +533,7 @@ class ParserController implements TagConstants {
> >   String fileName = inFileName.replace('\\', '/');
> >   boolean isAbsolute = fileName.startsWith("/");
> >   if (!isAbsolute) {
> > -fileName = Paths.get(baseDirStack.peekFirst() + 
> > fileName).normalize().toString();
> > +fileName = Paths.get(baseDirStack.peekFirst() + 
> > fileName).normalize().toString().replace('\\', '/');
> >   }
> >   String baseDir = fileName.substring(0, fileName.lastIndexOf('/') 
> > + 1);
> >   baseDirStack.addFirst(baseDir);
> >
> >
> > -
> > 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: [tomcat] 02/03: Experimenting with Semgrep

[Rémy Maucherat]

On Wed, Sep 13, 2023 at 12:53 PM Mark Thomas  wrote:
>
> On 13/09/2023 11:18, ma...@apache.org 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
> >
> > commit a78ed4a68522203def8f0c6b590678b1ff069fc0
> > Author: Mark Thomas 
> > AuthorDate: Wed Sep 13 11:16:49 2023 +0100
> >
> >  Experimenting with Semgrep
> >
> >  Semgrep have offered Tomcat free access to the tool so I am setting it
> >  up to see if it is useful or not.
>
> The initial results are in. Just under 300 findings and they pretty much
> all look to be some degree of false positive. There are a few things
> (such as Javadoc links using http rather than https) that we might want
> to look at but nothing I can see that comes close to something we'd
> consider to be a vulnerability.
>
> I have noticed that the tool isn't good at understanding context. It
> looks like it is just using a form of grep to look for patterns as it
> can't distinguish between SomeOtherObject.setSecure() and Cookie.setSecure()
>
> I am currently wondering whether the low value results are worth the
> time it will take to review and dismiss the false positives. Maybe. But
> I have a long list of things I'd consider more important to do first.
>
> If any other committer wants access to the dashboard just ping me a
> private email and I'll get you added.

I looked at the Semgrep output from the GH runs and it seems like a
waste of resources in the context of Tomcat (does the ASF pay for the
GH workflows ?).

Basically, it doesn't like:
- Path traversal stuff.
- Cookies.
- Class.forName.
- URL rewriting with session ids.

Overall those are very good pieces of advice for apps, but they don't
apply to Tomcat.

Can we drop it ?

I see coverity might be used with GH instead. I like the output of
that one, although in a few cases I would say it is a bit too good.
https://community.synopsys.com/s/article/Coverity-Integrations-GitHub-with-GitHub-Hosted-Runners
Would that work ? I'm really bad at GH stuff ...

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: (tomcat) branch main updated: Fix line endings (should be LF in source control)

[Rémy Maucherat]

On Wed, Jun 26, 2024 at 4:34 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 0228a749f9 Fix line endings (should be LF in source control)
> 0228a749f9 is described below
>
> commit 0228a749f95a83c4572b46a51758253c98215e83
> Author: Mark Thomas 
> AuthorDate: Wed Jun 26 15:34:13 2024 +0100
>
> Fix line endings (should be LF in source control)

Thanks, I never noticed anything.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: TestDataSourceUserDatabase and TestDataSourceRealm need Java 17

[Rémy Maucherat]

On Tue, Jun 18, 2024 at 12:26 PM Rainer Jung  wrote:
>
> Am 18.06.24 um 10:37 schrieb Rémy Maucherat:
> > On Tue, Jun 18, 2024 at 9:45 AM Rainer Jung  wrote:
> >>
> >> Hi there,
> >>
> >> the test classes org.apache.catalina.users.TestDataSourceUserDatabase
> >> and org.apache.catalina.realm.TestDataSourceRealm have a filing test
> >> which needs Java 17 due to the class version of
> >> org/apache/derby/jdbc/EmbeddedDriver. For TC 10.1 this leads to failures
> >> when testing with JDK 11-16.
> >
> > More build dependencies now need Java 17 for the testsuite (bnd in
> > particular, and even the Ant from my Fedora ...). How do you work
> > around that to reach the test ?
>
> Good point, thanks for asking:
>
> - I provide (recent) ant myselve and add it to the PATH
>
> - I first build everything using the release JDK version, so for
> instance Java 22 (just on one platform, currently RHEL 8).
>
> - for each test platform and JVM version I use a copy of the resulting
> build and output tree and I adjust build.xml to be able to only run the
> tests:
>
>- I set an additional custom property skip.build.java.version=true in
> build.properties
>
>- The block "" ist changed from
>
>  
>
>  
>
> to
>
>  
>
>  
>  
>
>  
>
>- the targets setup-bnd and add-osgi get an additional
> unless="skip.build.java.version" to supress them during the pure test run
>
>- the nio and nio2 test targets are duplicated and slightly adjusted
>  (dropping the dependencies test-compile and deploy).
>  Originally:
>
> 
> depends="setup-jacoco,test-compile,deploy,test-openssl-exists"
> if="${execute.test.nio}">
>extension=".NIO" />
> 
>
> 
> depends="setup-jacoco,test-compile,deploy,test-openssl-exists"
> if="${execute.test.nio2}">
>extension=".NIO2" />
> 
>
>The added targets:
>
>depends="setup-jacoco,test-openssl-exists"
> f="${execute.test.nio}">
>  extension=".NIO" />
>
>
>depends="setup-jacoco,test-openssl-exists"
> f="${execute.test.nio2}">
>  extension=".NIO2" />
>
>
>- finally the main test target alslo gets a slighty adjusted twin
>  (drop coverage-report, call the new "only" targets).
>  Originally
>
>depends="test-nio,test-nio2,coverage-report,test-status" />
>
> The added target:
>
>depends="test-only-nio,test-only-nio2,test-status" />
>
>
> - call the new "test-only" target.
>
> There are probably more clever ways to achieve this, but that's at least
> what I use to be able to run the tests on older JVM versions.
>
> Since I do not apply changes to the tests temselves, this means, that
> tests assuming a newer JVM version than the minimal runtime version will
> fail when I run them. Of course I can suppress them with test.exclude
> (probably only the whole class, not just individual failing tests?). I
> will do that, if the derby dependency was intentionally updated.
>
> Thanks and regards,

Thanks a lot ! I tested and committed the changes to all three
branches. I think we're in a much better position now for properly
testing Tomcat 9 and 10.1 with older Java versions.

Rémy

> Rainer
>
> > Rémy
> >
> >> Details:
> >>
> >> Testcase: testBasicUserRoleDatabase took 0.749 sec
> >>   Caused an ERROR
> >> org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
> >> version of the Java Runtime (class file version 61.0), this version of
> >> the Java Runtime only recognizes class file versions up to 55.0
> >> java.lang.UnsupportedClassVersionError:
> >> org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
> >> version of the Java Runtime (class file version 61.0), this version of
> >> the Java Runtime only recognizes class file versions up to 55.0
> >>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> >>   at
> >> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
> >>   at
> >> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
> >>   at
> >> java.base/jdk.internal

Re: (tomcat) branch main updated: Clear error earlier

[Rémy Maucherat]

On Wed, Jun 19, 2024 at 6:49 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> Michael-o has been pointing out that when fetching errors from OpenSSL,
> it's important to get all of them because OpenSSL tends to queue them up.
>
> Instead of getting "last error" should we be getting "all errors" as a
> list/array of error messages?

The important part is done (looping over all the errors to clear the
stack). I wasn't super convinced that returning something more than
the last error was very useful.

Rémy

> -chris
>
> On 6/18/24 10:41, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm 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 6fcf6d333b Clear error earlier
> > 6fcf6d333b is described below
> >
> > commit 6fcf6d333bec4855bd97494679a3d5272cd5786b
> > Author: remm 
> > AuthorDate: Tue Jun 18 16:40:41 2024 +0200
> >
> >  Clear error earlier
> > ---
> >   .../tomcat/util/net/openssl/panama/LocalStrings.properties|  1 +
> >   .../apache/tomcat/util/net/openssl/panama/OpenSSLContext.java | 11 
> > ++-
> >   2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/java/org/apache/tomcat/util/net/openssl/panama/LocalStrings.properties 
> > b/java/org/apache/tomcat/util/net/openssl/panama/LocalStrings.properties
> > index b42309b801..ad0d1d4291 100644
> > --- a/java/org/apache/tomcat/util/net/openssl/panama/LocalStrings.properties
> > +++ b/java/org/apache/tomcat/util/net/openssl/panama/LocalStrings.properties
> > @@ -58,6 +58,7 @@ openssl.errorLoadingPassword=Error loading password file: 
> > [{0}]
> >   openssl.errorLoadingPrivateKey=Error loading private key: [{0}]
> >   openssl.errorLoadingCertificateRevocationListWithError=Error loading 
> > certificate revocation [{0}] with error [{1}]
> >   openssl.errorPrivateKeyCheck=Private key does not match the certificate 
> > public key: [{0}]
> > +openssl.errorReadingPEMParameters=Failed reading PEM parameters [{0}] for 
> > certificate [{1}]
> >   openssl.errorSSLCtxInit=Error initializing SSL context
> >   openssl.invalidSslProtocol=An invalid value [{0}] was provided for the 
> > SSLProtocol attribute
> >   openssl.keyManagerMissing=No key manager found
> > diff --git 
> > a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java 
> > b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
> > index 9a8ba2ea2b..3dedf0fd22 100644
> > --- a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
> > +++ b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
> > @@ -1068,6 +1068,10 @@ public class OpenSSLContext implements 
> > org.apache.tomcat.util.net.SSLContext {
> >   
> > log.debug(sm.getString("openssl.setCustomDHParameters", 
> > Integer.valueOf(numBits), certificate.getCertificateFile()));
> >   }
> >   } else {
> > +String errMessage = 
> > OpenSSLLibrary.getLastError();
> > +if (errMessage != null) {
> > +
> > log.debug(sm.getString("openssl.errorReadingPEMParameters", errMessage, 
> > certificate.getCertificateFile()));
> > +}
> >   SSL_CTX_ctrl(state.sslCtx, 
> > SSL_CTRL_SET_DH_AUTO(), 1, MemorySegment.NULL);
> >   }
> >   }
> > @@ -1220,9 +1224,14 @@ public class OpenSSLContext implements 
> > org.apache.tomcat.util.net.SSLContext {
> >   EVP_PKEY_free(pkey);
> >   } else {
> >   
> > log.debug(sm.getString("openssl.setCustomDHParameters", 
> > Integer.valueOf(numBits),
> > -certificate.getCertificateFile()));
> > +x509KeyManager.toString()));
> >   }
> >   } else {
> > +String errMessage = OpenSSLLibrary.getLastError();
> > +if (errMessage != null) {
> > +
> > log.debug(sm.getString("openssl.errorReadingPEMParameters", errMessage,
> > +x509KeyManager.toString()));
> > +}
> >   SSL_CTX_ctrl(state.sslCtx, 
> > SSL_CTRL_SET_DH_AUTO(), 1, MemorySegment.NULL);
> >   }
> >   }
> >
> >
> > -
> > 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 additi

Re: [VOTE] Release Apache Tomcat 9.0.90

[Rémy Maucherat]

On Wed, Jun 19, 2024 at 3:59 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> On 6/14/24 11:06 AM, Rémy Maucherat wrote:
> > The proposed Apache Tomcat 9.0.90 release is now available for voting.
> >
> > The notable changes compared to 9.0.89 are:
> >
> > - Ensure that static resources deployed via a JAR file remain accessible
> > when the context is configured to use a bloom filter. Based on pull
> > request #730 provided by bergander.
> >
> > - Update to Commons Daemon 1.4.0
> >
> > - The default value of the discardFacades attribute of the Connector is now
> >true for improved safety
> >
> > 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.90/
> >
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1497
> >
> > The tag is:
> > https://github.com/apache/tomcat/tree/9.0.90
> > 65977c7d1da9b6016e2b19de06c3be7373f40859
> >
> > The proposed 9.0.90 release is:
> > [ ] -1, Broken - do not release
> > [ ] +1, Stable - go ahead and release as 9.0.90
>
> +1 for stable (6 hours late!)
>
> Build is reproducible on MacOS x86-64. Unit tests pass except for APR,
> likely an environmental problem. Every APR-related test fails with "APR
> library was not found" so I'll investigate that and hopefully givea
> better vote next time

I have verified the fix for the testsuite works:
https://github.com/apache/tomcat/commit/2a362e8a014e7857dc9491e9fcb22b243e268b9c

It's really only a testsuite thing overall.

Rémy

> Details:
>
> * Environment
> *  Java (build):openjdk version "17.0.11" 2024-04-16 OpenJDK Runtime
> Environment Temurin-17.0.11+9 (build 17.0.11+9) OpenJDK 64-Bit Server VM
> Temurin-17.0.11+9 (build 17.0.11+9, mixed mode)
> *  Java (test): openjdk version "22.0.1" 2024-04-16 OpenJDK Runtime
> Environment Temurin-22.0.1+8 (build 22.0.1+8) OpenJDK 64-Bit Server VM
> Temurin-22.0.1+8 (build 22.0.1+8, mixed mode)
> *  Ant: Apache Ant(TM) version 1.10.14 compiled on August 16
> 2023
> *  OS:  Darwin 21.6.0 x86_64
> *  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
> *  make:GNU Make 3.81
> *  OpenSSL: OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30
> Jan 2024)
> *  APR: 1.7.4
> *
> * Valid SHA-512 signature for apache-tomcat-9.0.90.zip
> * Valid GPG signature for apache-tomcat-9.0.90.zip
> * Valid SHA-512 signature for apache-tomcat-9.0.90.tar.gz
> * Valid GPG signature for apache-tomcat-9.0.90.tar.gz
> * Valid SHA-512 signature for apache-tomcat-9.0.90.exe
> * Valid GPG signature for apache-tomcat-9.0.90.exe
> * Valid SHA512 signature for apache-tomcat-9.0.90-src.zip
> * Valid GPG signature for apache-tomcat-9.0.90-src.zip
> * Valid SHA512 signature for apache-tomcat-9.0.90-src.tar.gz
> * Valid GPG signature for apache-tomcat-9.0.90-src.tar.gz
> *
> * Binary Zip and tarball: Same
> * Source Zip and tarball: Same
> *
> * Building dependencies returned: 0
> * tcnative builds cleanly
> * Tomcat builds cleanly
> * Junit Tests: FAILED
> *
> * Tests that failed:
> * javax.servlet.http.TestHttpServletDoHeadValidWrite1023.NIO2.txt
> * org.apache.catalina.ant.TestDeployTask.APR.txt
> * org.apache.catalina.authenticator.TestDigestAuthenticator.APR.txt
> * org.apache.catalina.connector.TestConnector.APR.txt
> * org.apache.catalina.connector.TestCoyoteAdapter.APR.txt
> * org.apache.catalina.connector.TestRequest.APR.txt
> * org.apache.catalina.connector.TestResponse.APR.txt
> * org.apache.catalina.core.TestApplicationContext.APR.txt
> * org.apache.catalina.core.TestAsyncContextImpl.APR.txt
> * org.apache.catalina.core.TestStandardContext.APR.txt
> * org.apache.catalina.core.TestStandardHostValve.APR.txt
> * org.apache.catalina.filters.TestExpiresFilter.APR.txt
> * org.apache.catalina.filters.TestRemoteIpFilter.APR.txt
> * org.apache.catalina.startup.TestTomcat.APR.txt
> * org.apache.catalina.valves.rewrite.TestRewriteValve.APR.txt
> * org.apache.coyote.http11.TestHttp11InputBuffer.APR.txt
> * org.apache.jasper.compiler.TestGenerator.APR.txt
> * org.apache.jasper.servlet.TestTldScanner.APR.txt
> * org.apache.tomcat.util.net.TestXxxEndpoint.APR.txt
>
> -
> 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

[ANN] Apache Tomcat 9.0.90 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.90.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.90 is a bugfix and feature release. The notable
changes compared to 9.0.89 include:

- Ensure that static resources deployed via a JAR file remain accessible
   when the context is configured to use a bloom filter.

- Update to Commons Daemon 1.4.0.

- The default value of the discardFacades attribute of the Connector is now
  true for improved safety.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE][RESULT] Release Apache Tomcat 9.0.90

[Rémy Maucherat]

The following votes were cast:

Binding:
+1: markt, isapir, remm

Non-binding
+1: Dimitris Soumis

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.90

[Rémy Maucherat]

On Tue, Jun 18, 2024 at 8:26 PM Rémy Maucherat  wrote:
>
> On Tue, Jun 18, 2024 at 5:02 PM Dimitris Soumis  wrote:
> >
> > -1 org.apache.catalina.ant.TestDeployTask is broken although test.apr.loc
>
> Yeah, ok there's still likely a problem with the counting that was
> added. It's still only a testsuite problem.

Verified that it is still the same APR listener instance count
problem, and verified the fix is the right one. Please apply the
little patch before doing the APR testsuite [if you want to test APR].
I will proceed with the release tomorrow.

Rémy

> Rémy
>
> > has been properly defined
> > Testsuite: org.apache.catalina.ant.TestDeployTask
> > Tests run: 5, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.443 sec
> > - Standard Error -
> > 18-Jun-2024 16:34:10.024 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [bug58086a]
> > 18-Jun-2024 16:34:10.097 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-apr-127.0.0.1-auto-1"]
> > 18-Jun-2024 16:34:10.101 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [bug58086b]
> > 18-Jun-2024 16:34:10.102 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-apr-127.0.0.1-auto-2"]
> > 18-Jun-2024 16:34:10.103 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [bug58086c]
> > 18-Jun-2024 16:34:10.103 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-apr-127.0.0.1-auto-3"]
> > 18-Jun-2024 16:34:10.104 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [bug58086d]
> > 18-Jun-2024 16:34:10.105 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-apr-127.0.0.1-auto-4"]
> > 18-Jun-2024 16:34:10.106 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [bug58086e]
> > 18-Jun-2024 16:34:10.346 INFO [main]
> > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> > ["http-apr-127.0.0.1-auto-5"]
> > 18-Jun-2024 16:34:10.346 INFO [main]
> > org.apache.catalina.core.StandardService.stopInternal Stopping service
> > [Tomcat]
> > -  ---
> >
> > Testcase: bug58086a took 0.16 sec
> > Testcase: bug58086b took 0.002 sec
> > Testcase: bug58086c took 0.002 sec
> > Testcase: bug58086d took 0.001 sec
> > Testcase: bug58086e took 0.242 sec
> > Caused an ERROR
> > The configured protocol [org.apache.coyote.http11.Http11AprProtocol]
> > requires the APR/native library which is not available
> > org.apache.catalina.LifecycleException: The configured protocol
> > [org.apache.coyote.http11.Http11AprProtocol] requires the APR/native
> > library which is not available
> > at org.apache.catalina.connector.Connector.initInternal(Connector.java:998)
> > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> > at
> > org.apache.catalina.core.StandardService.initInternal(StandardService.java:525)
> > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> > at
> > org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:990)
> > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
> > at org.apache.catalina.startup.Tomcat.start(Tomcat.java:438)
> > at
> > org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:888)
> > at org.apache.catalina.ant.TestDeployTask.bug58086e(TestDeployTask.java:91)
> > at
> > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> >
> > Caused an ERROR
> > An invalid Lifecycle transition was attempted ([before_stop]) for component
> > [StandardEngine[Tomcat]] in state [INITIALIZED]
> > org.apache.catalina.LifecycleException: An invalid Lifecycle transition was
> > attempted ([before_stop]) for component [StandardEngine[Tomcat]] in state
> > [INITIALIZED]
> > at
> > org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:392)
> > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:218)
> > at
> > org.apache.catalina.core.StandardService.stopInternal(StandardService.java:471)
> > at org.apache.catalina.util.

Re: [VOTE] Release Apache Tomcat 9.0.90

[Rémy Maucherat]

On Tue, Jun 18, 2024 at 5:02 PM Dimitris Soumis  wrote:
>
> -1 org.apache.catalina.ant.TestDeployTask is broken although test.apr.loc

Yeah, ok there's still likely a problem with the counting that was
added. It's still only a testsuite problem.

Rémy

> has been properly defined
> Testsuite: org.apache.catalina.ant.TestDeployTask
> Tests run: 5, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.443 sec
> - Standard Error -
> 18-Jun-2024 16:34:10.024 INFO [main]
> org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> [bug58086a]
> 18-Jun-2024 16:34:10.097 INFO [main]
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> ["http-apr-127.0.0.1-auto-1"]
> 18-Jun-2024 16:34:10.101 INFO [main]
> org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> [bug58086b]
> 18-Jun-2024 16:34:10.102 INFO [main]
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> ["http-apr-127.0.0.1-auto-2"]
> 18-Jun-2024 16:34:10.103 INFO [main]
> org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> [bug58086c]
> 18-Jun-2024 16:34:10.103 INFO [main]
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> ["http-apr-127.0.0.1-auto-3"]
> 18-Jun-2024 16:34:10.104 INFO [main]
> org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> [bug58086d]
> 18-Jun-2024 16:34:10.105 INFO [main]
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> ["http-apr-127.0.0.1-auto-4"]
> 18-Jun-2024 16:34:10.106 INFO [main]
> org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> [bug58086e]
> 18-Jun-2024 16:34:10.346 INFO [main]
> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> ["http-apr-127.0.0.1-auto-5"]
> 18-Jun-2024 16:34:10.346 INFO [main]
> org.apache.catalina.core.StandardService.stopInternal Stopping service
> [Tomcat]
> -  ---
>
> Testcase: bug58086a took 0.16 sec
> Testcase: bug58086b took 0.002 sec
> Testcase: bug58086c took 0.002 sec
> Testcase: bug58086d took 0.001 sec
> Testcase: bug58086e took 0.242 sec
> Caused an ERROR
> The configured protocol [org.apache.coyote.http11.Http11AprProtocol]
> requires the APR/native library which is not available
> org.apache.catalina.LifecycleException: The configured protocol
> [org.apache.coyote.http11.Http11AprProtocol] requires the APR/native
> library which is not available
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:998)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:525)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:990)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:438)
> at
> org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:888)
> at org.apache.catalina.ant.TestDeployTask.bug58086e(TestDeployTask.java:91)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>
> Caused an ERROR
> An invalid Lifecycle transition was attempted ([before_stop]) for component
> [StandardEngine[Tomcat]] in state [INITIALIZED]
> org.apache.catalina.LifecycleException: An invalid Lifecycle transition was
> attempted ([before_stop]) for component [StandardEngine[Tomcat]] in state
> [INITIALIZED]
> at
> org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:392)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:218)
> at
> org.apache.catalina.core.StandardService.stopInternal(StandardService.java:471)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:231)
> at
> org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:923)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:231)
> at org.apache.catalina.startup.Tomcat.stop(Tomcat.java:448)
> at
> org.apache.catalina.startup.TomcatBaseTest.tearDown(TomcatBaseTest.java:247)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>
> The root cause should be this commit
> <https://github.com/apache/tomcat/commit/1b10f5052bd8c9f07986227a050965bffaf47297>
> which introduces the lock on AprLifecycleListener class.
> Have not investigated further on the issue at th

Re: panama test TestOpenSSLConf.testOpenSSLConfCmdCipher() failing

[Rémy Maucherat]

On Tue, Jun 18, 2024 at 12:32 PM Rainer Jung  wrote:
>
> Am 18.06.24 um 12:04 schrieb Rémy Maucherat:
> > On Tue, Jun 18, 2024 at 9:36 AM Rainer Jung  wrote:
> >>
> >> Hi all,
> >>
> >> when testing 11.0.0-M21 and 10.1.25 I observe new failures in panama:
> >>
> >> Testcase:
> >> testOpenSSLConfCmdCipher[org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementation]
> >> took 4.438 sec
> >>   FAILED
> >> Wrong HostConfig ciphers
> >> Expected: is ["AES256-SHA256"]
> >>but: was ["TLS_AES_256_GCM_SHA384",
> >> "TLS_CHACHA20_POLY1305_SHA256", "TLS_AES_128_GCM_SHA256", "AES256-SHA256"]
> >> junit.framework.AssertionFailedError: Wrong HostConfig ciphers
> >> Expected: is ["AES256-SHA256"]
> >>but: was ["TLS_AES_256_GCM_SHA384",
> >> "TLS_CHACHA20_POLY1305_SHA256", "TLS_AES_128_GCM_SHA256", "AES256-SHA256"]
> >>   at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> >>   at
> >> org.apache.tomcat.util.net.openssl.TestOpenSSLConf.testOpenSSLConfCmdCipher(TestOpenSSLConf.java:132)
> >>   at
> >> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> >>
> >> The test was done with the recent releases of OpenSSL 3.0, 3.1, 3.2 and
> >> 3.3. All of them fail in the same way.
> >
> > I'm using OpenSSL 3.2.1 and the test was not failing for me. However,
> > it was also not working.
> >
> > There are two issues that left errors on the stack and making the
> > command check fail:
> > - Setting a bad value for the random seed (fixed)
> > - Then an error supposedly about use of the legacy provider somewhere
> > (no idea where this happens, it's now logged [error:1E08010C:DECODER
> > routines::unsupported])
> > Now the command check passes and I don't see any error processing the 
> > command.
>
> Thanks for checking and improving. I will check the updated version and
> investigate deeper in case it still fails for me. I will also check,
> whether the test is new, or behaves diifferently for OpenSSL 3.2.1 (used
> by you and also by me for the previous release) and 3.2.2 (used by me
> now). But probably not before this evening.
>
> No need to wait with closing the release votes, I guess panama is not
> yet a show-stopper for the vote.

Ok, I found the root cause: the TLS 1.3 check becomes false if
tomcat-native is not available. Since I had it, the FFM test is
working for me. I'll fix it one way or the other.

This test has a lot more configurations than expected ...

Rémy

> > Rémy
> >
> >> Best regards,
> >>
> >> Rainer
>
> -
> 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: panama test TestOpenSSLConf.testOpenSSLConfCmdCipher() failing

[Rémy Maucherat]

On Tue, Jun 18, 2024 at 9:36 AM Rainer Jung  wrote:
>
> Hi all,
>
> when testing 11.0.0-M21 and 10.1.25 I observe new failures in panama:
>
> Testcase:
> testOpenSSLConfCmdCipher[org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementation]
> took 4.438 sec
>  FAILED
> Wrong HostConfig ciphers
> Expected: is ["AES256-SHA256"]
>   but: was ["TLS_AES_256_GCM_SHA384",
> "TLS_CHACHA20_POLY1305_SHA256", "TLS_AES_128_GCM_SHA256", "AES256-SHA256"]
> junit.framework.AssertionFailedError: Wrong HostConfig ciphers
> Expected: is ["AES256-SHA256"]
>   but: was ["TLS_AES_256_GCM_SHA384",
> "TLS_CHACHA20_POLY1305_SHA256", "TLS_AES_128_GCM_SHA256", "AES256-SHA256"]
>  at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
>  at
> org.apache.tomcat.util.net.openssl.TestOpenSSLConf.testOpenSSLConfCmdCipher(TestOpenSSLConf.java:132)
>  at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>
> The test was done with the recent releases of OpenSSL 3.0, 3.1, 3.2 and
> 3.3. All of them fail in the same way.

I'm using OpenSSL 3.2.1 and the test was not failing for me. However,
it was also not working.

There are two issues that left errors on the stack and making the
command check fail:
- Setting a bad value for the random seed (fixed)
- Then an error supposedly about use of the legacy provider somewhere
(no idea where this happens, it's now logged [error:1E08010C:DECODER
routines::unsupported])
Now the command check passes and I don't see any error processing the command.

Rémy

> Best regards,
>
> Rainer
>
> -
> 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: TestDataSourceUserDatabase and TestDataSourceRealm need Java 17

[Rémy Maucherat]

On Tue, Jun 18, 2024 at 9:45 AM Rainer Jung  wrote:
>
> Hi there,
>
> the test classes org.apache.catalina.users.TestDataSourceUserDatabase
> and org.apache.catalina.realm.TestDataSourceRealm have a filing test
> which needs Java 17 due to the class version of
> org/apache/derby/jdbc/EmbeddedDriver. For TC 10.1 this leads to failures
> when testing with JDK 11-16.

More build dependencies now need Java 17 for the testsuite (bnd in
particular, and even the Ant from my Fedora ...). How do you work
around that to reach the test ?

Rémy

> Details:
>
> Testcase: testBasicUserRoleDatabase took 0.749 sec
>  Caused an ERROR
> org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
> version of the Java Runtime (class file version 61.0), this version of
> the Java Runtime only recognizes class file versions up to 55.0
> java.lang.UnsupportedClassVersionError:
> org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
> version of the Java Runtime (class file version 61.0), this version of
> the Java Runtime only recognizes class file versions up to 55.0
>  at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>  at
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
>  at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
>  at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>  at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
>  at java.base/java.lang.Class.forName0(Native Method)
>  at java.base/java.lang.Class.forName(Class.java:315)
>  at
> org.apache.catalina.users.TestDataSourceUserDatabase$DerbyUserDatabase.open(TestDataSourceUserDatabase.java:103)
>  at
> org.apache.catalina.users.TestDataSourceUserDatabase.testBasicUserRoleDatabase(TestDataSourceUserDatabase.java:131)
>  at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>  at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> and
>
> Testcase: testRealm took 1.298 sec
>  Caused an ERROR
> org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
> version of the Java Runtime (class file version 61.0), this version of
> the Java Runtime only recognizes class file versions up to 55.0
> java.lang.UnsupportedClassVersionError:
> org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
> version of the Java Runtime (class file version 61.0), this version of
> the Java Runtime only recognizes class file versions up to 55.0
>  at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>  at
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
>  at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
>  at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
>  at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>  at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
>  at java.base/java.lang.Class.forName0(Native Method)
>  at java.base/java.lang.Class.forName(Class.java:315)
>  at
> org.apache.catalina.realm.TestDataSourceRealm$DerbyDataSourceRealm.open(TestDataSourceRealm.java:61)
>  at
> org.apache.catalina.realm.TestDataSourceRealm.testRealm(TestDataSourceRealm.java:106)
>  at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>  at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>
> Best regards,
>
> Rainer
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, 

Re: [VOTE] Release Apache Tomcat 9.0.90

[Rémy Maucherat]

On Fri, Jun 14, 2024 at 5:06 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.90 release is now available for voting.
>
> The notable changes compared to 9.0.89 are:
>
> - Ensure that static resources deployed via a JAR file remain accessible
>when the context is configured to use a bloom filter. Based on pull
>request #730 provided by bergander.
>
> - Update to Commons Daemon 1.4.0
>
> - The default value of the discardFacades attribute of the Connector is now
>   true for improved safety
>
> 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.90/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1497
>
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.90
> 65977c7d1da9b6016e2b19de06c3be7373f40859
>
> The proposed 9.0.90 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.90

Rémy

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

[Rémy Maucherat]

On Fri, Jun 14, 2024 at 11:19 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 10.1.25 release is now available for
> voting.
>
> All committers and PMC members are kindly requested to provide a vote if
> possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes are
> binding. We welcome non-committer votes or comments on release builds.
>
> The notable changes compared to 10.1.24 are:
>
> - Ensure that static resources deployed via a JAR file remain accessible
>when the context is configured to use a bloom filter. Based on pull
>request #730 provided by bergander.
>
> - Update to Commons Daemon 1.4.0
>
> - Improvements to HTTP/2 streams and timeouts
>
> 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.25/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1498
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.25
> https://github.com/apache/tomcat/commit/a0038178b617423537dc66b2f516c53da7093421
>
> Please reply with a +1 for release or +0/-0/-1 with an explanation.

+1

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 11.0.0-M21

[Rémy Maucherat]

On Fri, Jun 14, 2024 at 4:58 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 11.0.0-M21 release is now available for
> voting.
>
> Apache Tomcat 11.0.0-M21 is a 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 the previous milestone include:
>
> - Ensure that static resources deployed via a JAR file remain accessible
>when the context is configured to use a bloom filter. Based on a pull
>request provided by bergander.
>
> - Ensure that static resources deployed via a JAR file remain accessible
>when the context is configured to use a bloom filter. Based on pull
>request #730 provided by bergander.
>
> - Update to Commons Daemon 1.4.0
>
> 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-M21/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1496
>
> The tag is:
> https://github.com/apache/tomcat/tree/11.0.0-M21
> 2acc5c10a303d6ae7a28c2959432aef98ae29016
>
> The proposed 11.0.0-M21 release is:
> [ ] -1 Broken - do not release
> [X] +1 Beta   - go ahead and release as 11.0.0-M21

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.90

[Rémy Maucherat]

On Fri, Jun 14, 2024 at 7:39 PM Mark Thomas  wrote:
>
> On 14/06/2024 16:06, Rémy Maucherat wrote:
>
> > The proposed 9.0.90 release is:
> > [ ] -1, Broken - do not release
> > [X] +1, Stable - go ahead and release as 9.0.90
>
> Tests pass on Linux, Windows, MacOS Intel and MacOS M1 with one caveat.
>
> APR tests that create an AprLifecycleListener instance and then destroy
> it without initialising it will cause subsequent tests in that class
> that require the AprLifecycleListener to fail. This is extremely
> unlikely to occur in any real use case.

I don't see how that is possible outside of the test case, so I would
say it is ok.

Rémy

> That said, I would understand if you wanted to re-tag.
>
> 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

[VOTE] Release Apache Tomcat 9.0.90

[Rémy Maucherat]

The proposed Apache Tomcat 9.0.90 release is now available for voting.

The notable changes compared to 9.0.89 are:

- Ensure that static resources deployed via a JAR file remain accessible
   when the context is configured to use a bloom filter. Based on pull
   request #730 provided by bergander.

- Update to Commons Daemon 1.4.0

- The default value of the discardFacades attribute of the Connector is now
  true for improved safety

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.90/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1497

The tag is:
https://github.com/apache/tomcat/tree/9.0.90
65977c7d1da9b6016e2b19de06c3be7373f40859

The proposed 9.0.90 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.90

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tagging June releases

[Rémy Maucherat]

On Thu, Jun 13, 2024 at 1:43 PM Mark Thomas  wrote:
>
> Just to confirm, I intend to tag 11.0.x tomorrow and that I intend the
> next 11.0.x release to be a BETA release.
>
> That does beg the question how long until we have a stable release.
> Given the similarity between 11.0.x and 10.1.x I don't think we need to
> wait very long. Thoughts?

I would say not long as well.

About my small FFM packaging update, I plan to do it *after* (= next
week), to avoid risks of messing up the release ...

Rémy

> Mark
>
>
> On 11/06/2024 21:46, Christopher Schultz wrote:
> > Mark,
> >
> > On 6/10/24 04:06, Mark Thomas wrote:
> >> A bunch of minor issues built up in my TODO list while I was at
> >> Community over Code and the Tomcat security day. I'd like to clear
> >> these before I tag the June releases.
> >
> > +1
> >
> >> In related news, the release ballots for Servlet and Pages have
> >> completed successfully. There is some admin that needs to be completed
> >> there as well but the key impact for us is that the next Tomcat 11
> >> vote will be for a BETA release rather than an ALPHA release.
> >
> > :party:
> >
> >> My current guess is that I'll be in a position to tag 11.0.x towards
> >> the end of the week. I'll provide an update if that changes after I
> >> have triaged my inbox.
> >
> > Sounds good to me.
> >
> > -chris
> >
> > -
> > 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

BND 7 and multi release JARs

[Rémy Maucherat]

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

Re: [PROPOSAL] Enable SecureLifecycleListener by default

[Rémy Maucherat]

On Thu, Jun 6, 2024 at 4:46 PM Christopher Schultz
 wrote:
>
> All,
>
> I'd like to remove the  around the SecureLifecycleListener
> in conf/server.xml that we bundle with Tomcat distributions.
>
> Before I do so, are there any objections to making this change?

+1
Having something commented out in the config is obviously the final
step before enabling it by default ;)

Rémy

> Thanks,
> -chris
>
> -
> 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: [PROPOSAL] Remove JSP file from ROOT web application

[Rémy Maucherat]

On Thu, Jun 6, 2024 at 4:44 PM Christopher Schultz
 wrote:
>
> 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.

The reason for this one was simply to have a JSP demo. Of course it is
simpler to have a static page ;)
So this is not needed anymore.

Rémy

> -chris
>
> -
> 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: [PROPOSAL] Tomcat 10: Remove CGI Servlet

[Rémy Maucherat]

On Thu, Jun 6, 2024 at 4:40 PM Christopher Schultz
 wrote:
>
> All,
>
> Resurrecting this thread from 2019.
>
> I will be proceeding with this 4.5-year-old plan to extract the CGI
> servlet to a separate JAR file to make it easy to "remove" from Tomcat
> if operators would prefer to do such things.
>
> I think I'll also move the configuration from conf/web.xml to
> webapps/docs/cgi-howto.html while I'm at it so those vestiges are gone.

I think I am +1 for removing CGI. For extraction, the issue is that
it's in the same package as default and WebDAV, usually it's meh to
split a package like that.

Rémy

>
> Thanks,
> -chris
>
> On 10/28/19 09:55, Christopher Schultz wrote:
> > All,
> >
> > Note: this was not a vote.
> >
> > There was very little feedback, and responses were mixed. We got
> > exactly one response on the users@ list about real-world usage of CGI,
> > so we cannot draw any conclusions about real-world uses.
> >
> > Otherwise, the consensus seems to be that CGIs should stay a part of
> > the main Tomcat distribution, but that perhaps separating it out into
> > a distinct JAR file and/or separate distribution might be advantageous.
> >
> > It appears that the CGIServlet is completely self-contained. It makes
> > use of the following internal(ish) Tomcat APIs:
> >
> > org.apache.catalina.util.IOTools
> > org.apache.juli.logging.Log
> > org.apache.juli.logging.LogFactory
> > org.apache.tomcat.util.compat.JrePlatform
> > org.apache.tomcat.util.res.StringManager
> >
> > All of these could be replaced if necessary to make a standalone,
> > container-agnostic package.
> >
> > It looks like it would be fairly easy to separate-out the CGIServlet
> > into a separate JAR file packaging if there's utility in that. For
> > example, security-conscious environments may want to remove that JAR
> > file entirely from the Tomcat deployment to be absolutely sure that
> > Runtime.exec() isn't available in the deployed Java code (from the
> > container; yet I realize that SSIServlet/SSIFilter has this, too).
> >
> > I'd like to go ahead and move the CGIServlet from the general
> > catalina.jar file into catalina-cgi.jar. That should only require a
> > small change to the build.xml script.
> >
> > Any objections?
> >
> > -chris
> >
> > On 10/7/19 10:59, Christopher Schultz wrote:
> >> All,
> >
> >> I recently gave a presentation on locking-down Apache Tomcat[1] and
> >> I briefly discussed the "sharp edges" present in Tomcat. Some of
> >> them are unnecessarily sharp and may be actually unnecessary. I'm
> >> going to make a few proposals to remove functions from Tomcat.
> >
> >> Proposal: Remove CGI Servlet
> >
> >> Justification:
> >
> >> The CGIServlet is another component, like server-side-includes,
> >> which is a remote-code execution (RCE) vulnerability as a feature.
> >> It is very easy to misconfigure. It is arguably not possible to
> >> secure it on Windows[2]. There are better solutions if you want to
> >> run Perl, Python, PHP, or whatever on your server in the form of
> >> the many fine web-server products out there.
> >
> >> -chris
> >
> >
> >> [1]
> >> http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> >
> >
> > at
> >> [2]
> >> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/
> > 23
> >
> >
> > /everyone-quotes-command-line-arguments-the-wrong-way/
> >
>
> -
> 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: Security mechanisms to counter spam

[Rémy Maucherat]

On Fri, Jun 7, 2024 at 12:23 PM Dimitris Soumis  wrote:
>
> Hi All,
>
> Due to the surge in spam BZs today, I propose implementing a security
> mechanism to counter this issue and prevent further disruption to the
> mailing list.
>
> A potential solution could include a honeypot to identify and block bots,
> as well as a reCaptcha to verify users. Additionally, should monitor for
> multiple requests from the same IP address and block the IP if necessary.
>
> Can also leverage tools like this Mozilla Bugbot Spam Detection Script
>  to
> identify and filter out spam.

One of the more ambitious proposals (which is in the wiki but has not
yet made it to the list) is to move to Github Issues. This spamming
might skew the discussion, but well, bad luck for BZ I guess ...

Rémy

> Best regards,
>
> Dimitris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

[Rémy Maucherat]

On Mon, Oct 7, 2019 at 4:46 PM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I recently gave a presentation on locking-down Apache Tomcat[1] and I
> briefly discussed the "sharp edges" present in Tomcat. Some of them
> are unnecessarily sharp and may be actually unnecessary. I'm going to
> make a few proposals to remove functions from Tomcat.
>
> Proposal: Remove Server-Side Includes
>
> Justification:
>
> The SSI module is a remote-code execution (RCE) vulnerability as a
> feature. My sense is that SSI is a little-used feature. A few years
> ago, markt[2] asked if anyone was using SSI. The only replies were
> from other Tomcat devs commenting on what to do with SSI if it's no
> longer in the main Tomcat distribution; there were no community
> members who responded saying that SSI was important to them.
>
> If the packaging of Tomcat could be tweaked a bit to move the SSI
> components into a separate JAR file (e.g. move
> org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI
> components don't rely on any Tomcat specific capabilities or
> internals, then the cattalina-ssi.jar file could be used between
> Tomcat versions. For example, a user of Tomcat 10 who still needs SSI
> could get the SSI module from a distribution of Tomcat 8.5.x or 9.x.

The discussion and proposal we had was to propose removing and see the
feedback. If there was some use, keep it as it does not actually pose
a security risk unless enabled.

Given the feedback, I would now say we should keep it for Tomcat 12.

Rémy

>
> - -chris
>
>
> [1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> at
> [2]
> https://lists.apache.org/thread.html/969a9d1b6e883a4017907c448292880624c
> c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bT78ACgkQHPApP6U8
> pFj9cQ/+Os1dBaXqqM3taTbqTzzCyLKCMz5q/66QreuH0ZMcqf/QjTGkxhsegelD
> 184cnAni2rWyV015yuqHvM/ZPn5BcH5pV31mEdJyGQiFIjvEfmZs37sGEoSOE584
> jutsktxcla7UEVMPfYU+YiVCapWRjWHNFusP2J/dP+UFYDg/cZJCoYDlMVjpfhmq
> UH6i/Sht3fpMfYYRHdgkP/r2wHLOD+qql/K8RNExhokwDZCiATmKA1uTuUHtQWQu
> rh71myzAqdzsEmLMRSLOnDY17XeG8Pd1W0JmcskdHNkZ/cYECLlMv5iqXLA3FbVM
> sLSd7PLJW1baFi9kqLTP4C44G8+j2tJAgjxkC+9nxFLB7Fy+abyV38Pt77zJ5NXS
> lIceS1jUIn4OBWFrMVnAii3slAl8WI0xknBBtJeObhw1uKtmRMJ2YtcefK89R/FR
> 9ZOAHghcYpkbTE8rO6z7HeyN/M+p972a7Pyr6nOH9XnanYBGuL/eg72/yAZpkofT
> k8AZe9VZ1SOK2TYBmNjHrzQDnodmvgtW3Q0RWY828CrOZ0x9vlQniKc/RWVa0HOR
> nv6l54oGGNoOezNnMKPRgOyUpzCtLCRkxMUVFkJJi2Hetf7QDo43MITgNNIz/VW8
> NEwTPtG/EUE98HQzl4MnV+I7MTBJK8kwwlIKYwtFFTnCy88QmOQ=
> =ap4d
> -END PGP SIGNATURE-
>
> -
> 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: WebDAV and Microsoft clients

[Rémy Maucherat]

On Wed, May 22, 2024 at 7:21 PM Mark Thomas  wrote:
>
> All,
>
> I've been looking at the WebDav Servlet for the last few days and in
> particular how it interacts with Microsoft clients.
>
> Basic operations including:
> - directory listings
> - create new file
> - create new directory
> - rename
> - update contents (ie open a file for editing and then saving it)
>
> all work for port 80 and port 8080 when WebDAV is mounted at "/" or a
> specific context.
>
> Drag/drop and copy/paste do not work. This appears to be related to
> Tomcat not implementing PROPPATCH. There is some guess work involved
> since I don't have access to the Microsoft code but I think the client
> is setting timestamps with PROPPATCH and then checking them. Because the
> PROPPATCH fails the overall operation is failed.
>
> I don't think that the WebdavFixFilter is required any more.
>
> I'd like to propose the following:
> - deprecate WebdavFixFilter in all current versions and then remove it
>in Tomcat 11
> - add the above information on what works and what doesn't to the
>WebdavServlet Javadoc - maybe along with a note to ping the dev list
>if drag/drop and copy/paste are required (or maybe a BZ issue)
> - come back to this if there is user interest in getting drag/drop and
>copy/paste working
>
> Thoughts?

+1, thanks for the research.

Not sure about proppatch obviously ;)

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: ServiceBindingPropertySource

[Rémy Maucherat]

On Wed, May 22, 2024 at 9:06 AM Mark Thomas  wrote:
>
> On 21/05/2024 18:50, Christopher Schultz wrote:
>
> 
>
> > 1. Allow ServiceBindingPropertySource to use the SERVICE_BINDING_ROOT
> > environment variable *or* a system property with an appropriate name
> > such as service.binding.root, with the system property overriding the
> > environment variable.
>
> Seems reasonable to me but keep in mind I've never used this code.

I haven't either, it's been contributed.

I don't really understand why the change overall, Kube uses the
environment and never the system properties.

> > 2. Have ServiceBindingPropertySource fall-back to system property
> > resolution if no matching file is found. Maybe we should do this with
> > all PropertySource classes provided by Tomcat?
>
> My reading of the docs and the code is that SystemPropertySource is
> always added already.

Yes, SystemPropertySource is added. Does it not work properly ?

> > 3. If the SERVICE_BINDING_ROOT environment variable is being used, copy
> > its value into a system property. This will allow application software
> > or Tomcat itself to use the file reference as necessary. For example:
>
> Again seems reasonable to me but same caveat as above.

The resolution should work as it is already given the javadocs from
ServiceBindingPropertySource.
At this point it would seem easier to simply add
-Dservice.binding.root=${SERVICE_BINDING_ROOT} to the Catalina
options.

Rémy

> 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: Buildbot failure in on tomcat-10.1.x

[Rémy Maucherat]

On Thu, May 16, 2024 at 12:20 PM Mark Thomas  wrote:
>
> On 16/05/2024 11:17, Mark Thomas wrote:
> > On 16/05/2024 10:34, Rémy Maucherat wrote:
> >> On Thu, May 16, 2024 at 10:57 AM  wrote:
> >>>
> >>> Build status: BUILD FAILED: failed compile (failure)
> >>> Worker used: bb_worker2_ubuntu
> >>> URL: https://ci2.apache.org/#builders/44/builds/1265
> >>> Blamelist: remm 
> >>> Build Text: failed compile (failure)
> >>> Status Detected: new failure
> >>> Build Source Stamp: [branch 10.1.x]
> >>> bbb4a7b3f7522189678447794b27f1033285df5a
> >>
> >> I cannot really figure out why this one is failing.
> >> https://nightlies.apache.org/tomcat/tomcat-10.1.x/logs/1265/TEST-org.apache.catalina.users.TestDataSourceUserDatabase.NIO.txt
> >>
> >> Derby on CI would be compiled with Java 19 (??) and running on 17 (no
> >> surprise). Testing locally shows the Derby JAR running fine on Java
> >> 17.
> >>
> >> Any ideas ?
> >
> > Hex editor confirms that class files in derby-10.17.1.0.jar target Java
> > 19 (and the MANIFEST says they were compiled with Java 21).
> >
> > The tests fail for me when running on Java 17.
> >
> > Targeting Java 19 is unexpected. I'll look into what the Derby docs say.
>
> Docs say:
> - Derby 10.16.1.1 targets Java 17
> - Derby 10.17.1.0 targets Java 21 (although it only requires Java 21)
>
> Looks like we need to downgrade the version of Derby we use.

Thanks ! I retried and it fails as expected with Java 17. I had an
earlier problem like that and my Fedora acts really weird when I don't
set JAVA_HOME. Setting it makes things more predictable, I need to be
more careful with that it seems.

Rémy

> 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: Buildbot failure in on tomcat-10.1.x

[Rémy Maucherat]

On Thu, May 16, 2024 at 10:57 AM  wrote:
>
> Build status: BUILD FAILED: failed compile (failure)
> Worker used: bb_worker2_ubuntu
> URL: https://ci2.apache.org/#builders/44/builds/1265
> Blamelist: remm 
> Build Text: failed compile (failure)
> Status Detected: new failure
> Build Source Stamp: [branch 10.1.x] bbb4a7b3f7522189678447794b27f1033285df5a

I cannot really figure out why this one is failing.
https://nightlies.apache.org/tomcat/tomcat-10.1.x/logs/1265/TEST-org.apache.catalina.users.TestDataSourceUserDatabase.NIO.txt

Derby on CI would be compiled with Java 19 (??) and running on 17 (no
surprise). Testing locally shows the Derby JAR running fine on Java
17.

Any ideas ?

Rémy

>
> Steps:
>
>   worker_preparation: 0
>
>   git: 0
>
>   shell: 0
>
>   shell_1: 0
>
>   shell_2: 0
>
>   shell_3: 0
>
>   shell_4: 0
>
>   shell_5: 0
>
>   compile: 1
>
>   shell_6: 0
>
>   shell_7: 0
>
>   shell_8: 0
>
>   shell_9: 0
>
>   Rsync docs to nightlies.apache.org: 0
>
>   shell_10: 0
>
>   Rsync RAT to nightlies.apache.org: 0
>
>   compile_1: 2
>
>   shell_11: 0
>
>   Rsync Logs to nightlies.apache.org: 0
>
>
> -- ASF Buildbot
>
>
> -
> 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: [tcnative] switch from using ERR_error_string to ERR_error_string_n

[Rémy Maucherat]

On Tue, May 14, 2024 at 11:15 PM Christopher Schultz
 wrote:
>
> All,
>
> I'd like to basically globally-search-and-replace ERR_error_string for
> ERR_error_string_n and use a #define constant for both the
> initialization of all
>
> char err[256];
>
> and similar strings and use that same constant for all calls to
> ERR_error_string_n..
>
> Any objections?
>
> There should really be no effective change, except:
>
> 1. We can raise that error message length constant and have it affect
> the whole library if we choose.
>
> 2. We will be using a length-aware string-manipulation call which is
> better than using one that assumes that the buffer is at least 256 bytes
> long.

+1

This gives me something to do since I thought this was 128 (this
probably came from the tomcat-native code somewhere initially), so I
have a problem with the FFM code which I will fix at the same time. It
seems 128 is already enough in practice.

Rémy

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

[Rémy Maucherat]

On Thu, May 9, 2024 at 8:12 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 10.1.24 release is now available for
> voting.
>
> The notable changes compared to 10.1.23 are:
>
> - Correct error handling for asynchronous requests
>
> - Refactor HTTP header parsing to use common parsing code and fix
>non-blocking reads of chunked request bodies including trailer fields
>
> - WebDAV locking handling fixes
>
> 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.24/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1494
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.24
> https://github.com/apache/tomcat/commit/f2a274bc00cf73670a614999561c69a391b5e35f
>
> Please reply with a +1 for release or -0/-1 with an explanation.
>
> The proposed 10.1.24 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.1.24

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.89 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.89.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.89 is a bugfix and feature release. The notable
changes compared to 9.0.88 include:

- Refactor HTTP header parsing to use common parsing code and fix
   non-blocking reads of chunked request bodies including trailer fields

- Add more timescale options to AccessLogValve and
   ExtendedAccessLogValve

- WebDAV locking handling fixes

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE][RESULT] Release Apache Tomcat 9.0.89

[Rémy Maucherat]

The following votes were cast:

Binding:
+1: isapir, rjung, remm, jfclere
+0: markt

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.89

[Rémy Maucherat]

On Fri, May 3, 2024 at 10:37 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.89 release is now available for voting.
>
> The notable changes compared to 9.0.88 are:
>
> - Refactor HTTP header parsing to use common parsing code and fix
>non-blocking reads of chunked request bodies including trailer fields
>
> - Add more timescale options to AccessLogValve and
>ExtendedAccessLogValve
>
> - WebDAV locking handling fixes
>
> 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.89/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1494
>
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.89
> 661a5978828212bbe4a324dd7c854894f34a561b
>
> The proposed 9.0.89 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.89

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 11.0.0-M20

[Rémy Maucherat]

On Fri, May 3, 2024 at 6:22 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 11.0.0-M20 release is now available for
> voting.
>
> Apache Tomcat 11.0.0-M20 is a 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 the previous milestone include:
>
> - Add OpenSSL FFM classes to tomcat-embed-core.jar
>
> - Refactor HTTP header parsing to use common parsing code and fix
>non-blocking reads of chunked request bodies including trailer fields
>
> - Add more timescale options to AccessLogValve and
>ExtendedAccessLogValve
>
>
> 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-M20/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1493
>
> The tag is:
> https://github.com/apache/tomcat/tree/11.0.0-M20
> c400bf727cbc10198d3f52c29849d18660050b0c
>
> The proposed 11.0.0-M20 release is:
> [ ] -1 Broken - do not release
> [X] +1 Alpha  - go ahead and release as 11.0.0-M20

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 9.0.89

[Rémy Maucherat]

On Mon, May 6, 2024 at 4:57 AM Rainer Jung  wrote:
>
> Am 03.05.24 um 22:37 schrieb Rémy Maucherat:
> > The proposed Apache Tomcat 9.0.89 release is now available for voting.
> >
> > The notable changes compared to 9.0.88 are:
> >
> > - Refactor HTTP header parsing to use common parsing code and fix
> > non-blocking reads of chunked request bodies including trailer fields
> >
> > - Add more timescale options to AccessLogValve and
> > ExtendedAccessLogValve
> >
> > - WebDAV locking handling fixes
> >
> > 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.89/
> >
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1494
> >
> > The tag is:
> > https://github.com/apache/tomcat/tree/9.0.89
> > 661a5978828212bbe4a324dd7c854894f34a561b
> >
> > The proposed 9.0.89 release is:
> > [ ] -1, Broken - do not release
> > [X] +1, Stable - go ahead and release as 9.0.89
> >
> > Rémy
>
> +1, builds fine (on RHEL8 using JDK22).
>
> Tested via unit test suite on RHEL 6, 7, 8 and 9, SLES 11, 12 and 15 and
> Solaris 10 and 11 using latest patch levels of JDK 8, 11, 17, 21, 22
> from Adoptium Temurin, Zulu Azul, Amazon Coretto, Oracle and RedHat (the
> latter only on RHEL) plus JDK 23 EA 18. Solaris tests limited to JDK
> 1.8.0 and 11. A total of 161 test runs for NIO+NIO2.
>
> Also ran the few relevant tests for all of these platforms and JVMs in
> combination with tcnative 1.3.0 and 2.0.7 built with OpenSSL 3.0.13,
> 3.1.5, 3.2.1 and 3.3.0. A total of 1288 test runs for NIO+NIO2. Tests
> assumed to be relevant were
> org/apache/coyote/http2/TestLargeUpload.java,org/apache/**/Test*SSL*.java,org/apache/**/Test*Ssl*.java,org/apache/**/Test*openssl*.java,org/apache/tomcat/util/net/**/Test*.java,org/apache/tomcat/jni/**/Test*.java
>
> No testing done for APR connectors.
>
> Test adjustments:
>
> - TestMapperPerformance increased maxTime from 5000 to 25000
> - TesterTagHandlerPoolPerformance lowered loop count from 500, to 50
> - SimpleHttpClient increased soTimeout from 1 to 2
>
> No unusual test failures:
>
> 1) sporadic tcnative crashes (probably during shutdown, running with 2
> test threads):
>
> - org.apache.tomcat.util.net.TestClientCert FAILED (crashed)
>1 rh_jdk1.8.0-rhel9.x86_64-tcnative-1.3.0-320-1
>
> - org.apache.tomcat.util.net.TestClientCertTls13 FAILED (crashed)
>1 amazon_jdk1.8.0-rhel9.x86_64-tcnative-2.0.7-300-1
>
> - org.apache.tomcat.util.net.TestSsl FAILED (crashed)
>1 amazon_jdk1.8.0-rhel9.x86_64-tcnative-2.0.7-300-1
>1 oracle_jdk1.8.0-sles12.x86_64-tcnative-2.0.7-310-2
>1 amazon_jdk21-sles12.x86_64-tcnative-2.0.7-320-1
>1 amazon_jdk21-sles15.x86_64-tcnative-1.3.0-310-2
>1 rh_jdk21-rhel8.x86_64-tcnative-2.0.7-320-1
>
> - org.apache.catalina.valves.rewrite.TestResolverSSL FAILED (crashed)
>1 zulu_jdk21-sles12.x86_64-tcnative-2.0.7-300-1
>
>
> 2) very sporadic JSSE failures for Linux:
>
> - org.apache.tomcat.websocket.server.TestSlowClient FAILED
>1 amazon_jdk1.8.0-rhel6.x86_64-jsse
>1 oracle_jdk17-rhel6.x86_64-jsse
>
> -
> org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator
> FAILED
>1 adopt_jdk22-rhel8.x86_64-jsse
>
> 3) sporadic JSSE failures for Solaris:
>
> - org.apache.catalina.connector.TestConnector FAILED
>1 oracle_jdk1.8.0-solaris10.sparc-jsse
>
> - org.apache.catalina.core.TestSwallowAbortedUploads FAILED
>1 adopt_jdk1.8.0-solaris11.sparc-jsse
>2 oracle_jdk1.8.0-solaris11.sparc-jsse
>2 zulu_jdk1.8.0-solaris11.sparc-jsse
>
> - org.apache.tomcat.websocket.TestWebSocketFrameClientSSL FAILED
>1 zulu_jdk11-solaris11.sparc-tcnative-1.3.0-300-1
>
> - org.apache.tomcat.websocket.server.TestClose FAILED
>1 zulu_jdk1.8.0-solaris11.sparc-jsse

Thanks :) Your testing is getting more extensive every time !

Rémy

> Best regards,
>
> Rainer
>
> -
> 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

[VOTE] Release Apache Tomcat 9.0.89

[Rémy Maucherat]

The proposed Apache Tomcat 9.0.89 release is now available for voting.

The notable changes compared to 9.0.88 are:

- Refactor HTTP header parsing to use common parsing code and fix
   non-blocking reads of chunked request bodies including trailer fields

- Add more timescale options to AccessLogValve and
   ExtendedAccessLogValve

- WebDAV locking handling fixes

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.89/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1494

The tag is:
https://github.com/apache/tomcat/tree/9.0.89
661a5978828212bbe4a324dd7c854894f34a561b

The proposed 9.0.89 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.89

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tagging May releases

[Rémy Maucherat]

On Thu, May 2, 2024 at 7:26 PM Mark Thomas  wrote:
>
> Hi all,
>
> Things are looking good for the May releases. I have a few things to
> back-port to 10.1.x and 9.0.x and then I'll start running my pre-release
> tests. Providing everything passes (and CI runs suggest they will) I'll
> tag 11.0.x - probably some time tomorrow.

+1

Rémy

> 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: Refactoring heads up

[Rémy Maucherat]

On Fri, Apr 26, 2024 at 7:20 PM Mark Thomas  wrote:
>
> On 24/04/2024 17:52, Mark Thomas wrote:
>
> 
>
> > My plan is to commit these changes to 11.0.x with the low risk parts
> > (e.g. new methods) back-ported. Then, once we can see what is left, we
> > can decide how quickly/slowly we want to back-port the complete fix to
> > 10.1.x and 9.0.x (the issue was reported against 10.1.x).
>
> All is looking good so far.
>
> The complete refactoring has been applied to 11.0.x
>
> 10.1.x and 9.0.x have the new header parser and are using it for the
> ChunkedInputFilter.
>
> The question is how long do we want to wait before back-porting the
> standard HTTP header parsing? Essentially this means back-porting this
> commit:
>
> https://github.com/apache/tomcat/commit/e5acf2cf0f745350c85d81532826d92b1882469a
>
> Thoughts?

Nice overall. You can wait a bit just in case ...
I was not aware that non blocking was not working there.

Rémy

> I'm thinking wait at least one release cycle before back-porting just in
> case of regressions given that this affects every request.
>
> 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.23

[Rémy Maucherat]

On Sun, Apr 21, 2024 at 11:52 AM Rainer Jung  wrote:
>
> Am 16.04.24 um 15:11 schrieb Christopher Schultz:
> > The proposed Apache Tomcat 10.1.23 release is now available for
> > voting. Apache Tomcat 10.1.21 was canceled due to a release-build
> > mistake and Apache Tomcat 10.1.22 was cancelled due to an option in
> > startup scripts which would have caused Java 11 environments to fail to
> > start.
> >
> > The notable changes compared to 10.1.20 are:
> >
> > - Improve locking strategies in Catalina core
> >
> > - Update Basic authentication to implement the requirements of RFC 7617
> >
> > - Updates to Apache Commons dependencies
> >
> > - Add OpenSSL support when FFM is available
> >
> > 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.23/
> >
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1492
> >
> > The tag is:
> > https://github.com/apache/tomcat/tree/10.1.23
> > https://github.com/apache/tomcat/commit/9062d27dc5122e8241ea62a4c4312af0dc71da49
> >
> > Please reply with a +1 for release or -0/-1 with an explanation.
> >
> > The proposed 10.1.23 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 10.1.23
>
> +1, builds fine (on RHEL8 using JDK22).
>
> Tested via unit test suite on RHEL 6, 7, 8 and 9, SLES 11, 12 and 15 and
> Solaris 11 Sparc using latest patch levels of JDK 11, 17, 21, 22 from
> Adoptium Temurin, Zulu Azul, Amazon Coretto, Oracle and RedHat (where
> applicable) plus JDK 23 EA 18. That was a total of 124 JSSE based test
> suite runs.
>
> Also ran the few relevant tests for all of these platforms and JMVs in
> combination with tcnative 1.3.0 and 2.0.7 built with OpenSSL 3.0.13,
> 3.1.5, 3.2.1 and 3.3.0. That was a total of 992 tcnative based shortened
> test suite runs.
>
> Finally ran the relevant tests with JVMs 22 and 23 plus panama for the
> same four OpenSSL versions. That was a total of 124 tcnative based
> shortened test suite runs.
>
> Apart from the usual sporadic tcnative crashes during shutdown (running
> with 2 test threads) all was fine.

That's a lot of tests ! Are the crashes affecting the FFM code too ?

Rémy

> Best regards,
>
> Rainer
>
> -
> 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: Panama modules: inconsistency between 9.0.x, 10.1.x and main?

[Rémy Maucherat]

On Thu, Apr 18, 2024 at 1:52 PM Rainer Jung  wrote:
>
> Hi all,
>
> I noticed, that in main and 9.0.x we have a panama module, but not in
> 10.1.x.
>
> More precisely I see:
>
> main and 10.1.x do have java/org/apache/tomcat/util/net/openssl/panama.
> That is probably due to the existence of Java 22 for a release build. Fine.
>
> main and 9.0.x do have a main/modules/openssl-foreign.
>
> Only main does have main/modules/openssl-java17 and
> main/modules/openssl-java21

These modules in main are for history purposes, maybe they can be
moved to an archive somewhere.

Only the 9.0 module is useful since FFM can never be backported to
that branch (the next Java LTS will most likely not allow a release
target to Java 1.8).

Rémy

> 10.1.x does not have any of these modules.
>
> Is this already how it should look like?
>
> Thanks and regards,
>
> Rainer
>
> -
> 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.23

[Rémy Maucherat]

On Tue, Apr 16, 2024 at 3:11 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 10.1.23 release is now available for
> voting. Apache Tomcat 10.1.21 was canceled due to a release-build
> mistake and Apache Tomcat 10.1.22 was cancelled due to an option in
> startup scripts which would have caused Java 11 environments to fail to
> start.
>
> The notable changes compared to 10.1.20 are:
>
> - Improve locking strategies in Catalina core
>
> - Update Basic authentication to implement the requirements of RFC 7617
>
> - Updates to Apache Commons dependencies
>
> - Add OpenSSL support when FFM is available
>
> 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.23/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1492
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.23
> https://github.com/apache/tomcat/commit/9062d27dc5122e8241ea62a4c4312af0dc71da49
>
> Please reply with a +1 for release or -0/-1 with an explanation.
>
> The proposed 10.1.23 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.1.23

+1
Sorry again for the trouble ...

Rémy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.88 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.88.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.88 is a bugfix and feature release. The notable
changes compared to 9.0.87 include:

- Cookies header generation enhancements.

- Fix regression when reloading TLS configuration and files.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[ANN] Apache Tomcat 11.0.0-M19 (alpha) available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M19 (alpha).

Apache Tomcat 11 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M19 is a 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 11.0.0-M18 include:

- Finalize update to the Jakarta EE 11 specifications.

- Cookies header generation enhancements.

- Fix regression when reloading TLS configuration and files.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-11.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-11.cgi

Migration guides from Apache Tomcat 8.5.x, 9.0.x and 10.1.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org