Refactoring heads up

[Mark Thomas]

Hi all,

The Spring folks have pinged me on an issue reported to them. The short 
version is that Tomcat doesn't support non-blocking reads of chunked 
request bodies.


While we have nearly all of the pieces we need to fix this, the commit 
is still going to be quite large involving quite a lot of changes to the 
ChunkedInputFilter. This will require some changes to Tomcat's internal 
API for ChunkedInputFilter - a number of protected fields and methods 
will be removed or made private.


I have this working locally except for trailer fields.

Closely related is the parsing of trailer fields. We already have a code 
comment saying this is very similar to HTTP fields (headers) but a 
common implementation isn't provided because fields use blocking or 
non-blocking IO but trailer fields only use blocking IO. Given we need 
to support non-blocking IO there is now a much stronger case for pulling 
the field (header) parsing code out to a separate class and reusing it 
for trailer fields.


I'm starting to work on this now and hope to complete the work this week.

Given these changes are going to impact pretty much every request I 
wanted to provide a heads up that these changes were on the way.


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


Mark

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

Re: [VOTE] Release Apache Tomcat 10.1.23

[Mark Thomas]

On 23/04/2024 06:35, jean-frederic clere wrote:

On 4/17/24 12:00, Mark Thomas wrote:

Build is reproducible.


My tests here complain about examples, did I miss something.


No idea. You'd need to do a diff to see what didn't match and that will 
(hopefully) point you towards the root cause.


Mark



TCK tests are still running...




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

Re: (tomcat) branch main updated: Don't create a StringBuilder object until we know we have at least one Cookie value to log.

[Mark Thomas]

Ping. Just making sure this veto hasn't been lost in the recent flurry 
of commits.


Mark


On 18/04/2024 16:12, Mark Thomas wrote:

On 18/04/2024 14:31, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz 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 23facd507d Don't create a StringBuilder object until we know 
we have at least one Cookie value to log.

23facd507d is described below

commit 23facd507db72d583ed89a13f20ab1cb766f0221
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 09:30:50 2024 -0400

 Don't create a StringBuilder object until we know we have at 
least one Cookie value to log.


-1. veto. Please fix/revert ASAP.

Note: This veto applies to this commit and the back-ports.

This creates multiple paths where a NPE is possible.

This does not work if there are multiple cookies with the same name that 
need to be logged.


Mark



---
  java/org/apache/catalina/valves/AbstractAccessLogValve.java | 3 ++-
  webapps/docs/changelog.xml  | 4 
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git 
a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java

index 5502d1c183..e13bb9e5ac 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1479,7 +1479,7 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

  @Override
  public void addElement(CharArrayWriter buf, Date date, 
Request request, Response response, long time) {

-    StringBuilder value = new StringBuilder();
+    StringBuilder value = null;
  boolean first = true;
  Cookie[] cookies = request.getCookies();
  if (cookies != null) {
@@ -1490,6 +1490,7 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

  } else {
  value.append(',');
  }
+    value = new StringBuilder();
  value.append(cookie.getValue());
  }
  }
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 8ef77e52aa..f6c6c62962 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -123,6 +123,10 @@
  including the removal of the trimCredentials 
setting which

  is now hard-coded to false. (markt)
    
+  
+    Small performance optimization when logging cookies with no 
values.

+    (schultz)
+  
  
    
    


-
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/02: Re-factor ElapsedTimeElement to use a customizable Style

[Mark Thomas]

On 19/04/2024 13:31, Mark Thomas wrote:

On 19/04/2024 13:12, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit d3482c35bf144cc891dfa325b2f2f50460708c23
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 10:22:16 2024 -0400

 Re-factor ElapsedTimeElement to use a customizable Style


How is this customizable?

This seems to add complexity to somewhere we probably want to keep 
things simple.


Never mind. I think you meant extensible. I can see what you are trying 
to do in the PR that adds ns etc.


Mark




Mark



---
  .../catalina/valves/AbstractAccessLogValve.java    | 52 
+-

  webapps/docs/changelog.xml |  4 ++
  2 files changed, 44 insertions(+), 12 deletions(-)

diff --git 
a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java

index e13bb9e5ac..0576b83442 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1307,8 +1307,44 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

   * write time taken to process the request - %D, %T
   */
  protected static class ElapsedTimeElement implements 
AccessLogElement {

-    private final boolean micros;
-    private final boolean millis;
+    enum Style {
+    SECONDS {
+    @Override
+    public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));

+    }
+    },
+    MILLISECONDS {
+    @Override
+    public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));

+    }
+    },
+    MICROSECONDS {
+    @Override
+    public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));

+    }
+    };
+
+    /**
+ * Append the time to the buffer in the appropriate format.
+ *
+ * @param buf The buffer to append to.
+ * @param time The time to log in nanoseconds.
+ */
+    public abstract void append(CharArrayWriter buf, long time);
+    }
+    private final Style style;
+
+    /**
+ * Create a new ElapsedTimeElement that will log the time in 
the specified style.

+ *
+ * @param style The elapsed-time style to use.
+ */
+    public ElapsedTimeElement(Style style) {
+    this.style = style;
+    }
  /**
   * @param micros true, write time in 
microseconds - %D
@@ -1316,20 +1352,12 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

   *   time in seconds - %T
   */
  public ElapsedTimeElement(boolean micros, boolean millis) {
-    this.micros = micros;
-    this.millis = millis;
+    this(micros ? Style.MICROSECONDS : millis ? 
Style.MILLISECONDS : Style.SECONDS);

  }
  @Override
  public void addElement(CharArrayWriter buf, Date date, 
Request request, Response response, long time) {

-    if (micros) {
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));

-    } else if (millis) {
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));

-    } else {
-    // second
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));

-    }
+    style.append(buf, time);
  }
  }
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index bda2e5d98c..f6eacba634 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -133,6 +133,10 @@
  dispatch is now performed rather than completing the request 
using the

  error page mechanism. (markt)
    
+  
+    Re-factor ElapsedTimeElement in AbstractAccessLogValve to use 
a customizable

+    style. (schultz)
+  
  
    
    


-
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

Re: (tomcat) 02/02: Re-factor ElapsedTimeElement to use a customizable Style

[Mark Thomas]

On 19/04/2024 13:12, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit d3482c35bf144cc891dfa325b2f2f50460708c23
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 10:22:16 2024 -0400

 Re-factor ElapsedTimeElement to use a customizable Style


How is this customizable?

This seems to add complexity to somewhere we probably want to keep 
things simple.


Mark



---
  .../catalina/valves/AbstractAccessLogValve.java| 52 +-
  webapps/docs/changelog.xml |  4 ++
  2 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
index e13bb9e5ac..0576b83442 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1307,8 +1307,44 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
   * write time taken to process the request - %D, %T
   */
  protected static class ElapsedTimeElement implements AccessLogElement {
-private final boolean micros;
-private final boolean millis;
+enum Style {
+SECONDS {
+@Override
+public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));
+}
+},
+MILLISECONDS {
+@Override
+public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));
+}
+},
+MICROSECONDS {
+@Override
+public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));
+}
+};
+
+/**
+ * Append the time to the buffer in the appropriate format.
+ *
+ * @param buf The buffer to append to.
+ * @param time The time to log in nanoseconds.
+ */
+public abstract void append(CharArrayWriter buf, long time);
+}
+private final Style style;
+
+/**
+ * Create a new ElapsedTimeElement that will log the time in the 
specified style.
+ *
+ * @param style The elapsed-time style to use.
+ */
+public ElapsedTimeElement(Style style) {
+this.style = style;
+}
  
  /**

   * @param micros true, write time in microseconds - %D
@@ -1316,20 +1352,12 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
   *   time in seconds - %T
   */
  public ElapsedTimeElement(boolean micros, boolean millis) {
-this.micros = micros;
-this.millis = millis;
+this(micros ? Style.MICROSECONDS : millis ? Style.MILLISECONDS : 
Style.SECONDS);
  }
  
  @Override

  public void addElement(CharArrayWriter buf, Date date, Request 
request, Response response, long time) {
-if (micros) {
-buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));
-} else if (millis) {
-buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));
-} else {
-// second
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));
-}
+style.append(buf, time);
  }
  }
  
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml

index bda2e5d98c..f6eacba634 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -133,6 +133,10 @@
  dispatch is now performed rather than completing the request using the
  error page mechanism. (markt)

+  
+Re-factor ElapsedTimeElement in AbstractAccessLogValve to use a 
customizable
+style. (schultz)
+  
  




-
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: Don't create a StringBuilder object until we know we have at least one Cookie value to log.

[Mark Thomas]

On 18/04/2024 14:31, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz 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 23facd507d Don't create a StringBuilder object until we know we have 
at least one Cookie value to log.
23facd507d is described below

commit 23facd507db72d583ed89a13f20ab1cb766f0221
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 09:30:50 2024 -0400

 Don't create a StringBuilder object until we know we have at least one 
Cookie value to log.


-1. veto. Please fix/revert ASAP.

Note: This veto applies to this commit and the back-ports.

This creates multiple paths where a NPE is possible.

This does not work if there are multiple cookies with the same name that 
need to be logged.


Mark



---
  java/org/apache/catalina/valves/AbstractAccessLogValve.java | 3 ++-
  webapps/docs/changelog.xml  | 4 
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
index 5502d1c183..e13bb9e5ac 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1479,7 +1479,7 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
  
  @Override

  public void addElement(CharArrayWriter buf, Date date, Request 
request, Response response, long time) {
-StringBuilder value = new StringBuilder();
+StringBuilder value = null;
  boolean first = true;
  Cookie[] cookies = request.getCookies();
  if (cookies != null) {
@@ -1490,6 +1490,7 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
  } else {
  value.append(',');
  }
+value = new StringBuilder();
  value.append(cookie.getValue());
  }
  }
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 8ef77e52aa..f6c6c62962 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -123,6 +123,10 @@
  including the removal of the trimCredentials setting 
which
  is now hard-coded to false. (markt)

+  
+Small performance optimization when logging cookies with no values.
+(schultz)
+  
  




-
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

[Mark Thomas]

On 16/04/2024 14:11, Christopher Schultz wrote:

The proposed 10.1.23 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.1.23


Unit tests pass on Linux, Windows and MacOS (M1).

Build is reproducible.

Mark

PS I am still unable to test on MacOS (Intel) as it is a $dayjob 
provided laptop and the mandatory AV software is slowing the tests down 
to the point that lots of them fail.


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

Re: jakartaee/servlet pom.xml

[Mark Thomas]

On 16/04/2024 08:23, xulin y wrote:

Hi,

I refer to this commit:
https://github.com/jakartaee/servlet/commit/1455686360e118a68a545fb2e1b74f1c79abcfb5


And I ask again. How is that a Tomcat issue?

Mark




By Xulin Yang
Kind Regards

Mark Thomas  于2024年4月16日周二 15:20写道：


The list drops images. What changed?

Mark


On 16/04/2024 07:52, xulin y wrote:

Hi,

image.png
You can see this version was changed from 6.1.0-M2 to 6.1.0 on 2024 Mar
27 while 6.1.0 is not present in


https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/


image.png

By Xulin Yang
Kind Regards

Mark Thomas mailto:ma...@apache.org>> 于2024年4月16日
周二 14:48写道：

 How is this an Apache Tomcat issue?

 Mark


 On 16/04/2024 07:41, xulin y wrote:
  > Hi,
  >
  > System OS: Windows 10
  > Maven: 3.9.6
  > Java: 17.0.1
  >
  > When I was "mvn install" jakartaee/servlet on my desktop. I found
  >


https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37
<
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37>
<
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37
<
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37>>
can give me exception. This is because
https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>>
does not have jakarta.servlet-api 6.1.0

  > image.png
  > I use 6.1.0-SNAPSHOT on my desktop instead. Could you take a look
 at this?
  >
  > Appendix:
  > [ERROR] Failed to execute goal on project tck-runtime: Could not
 resolve
  > dependencies for project
 jakarta.servlet:tck-runtime:jar:6.1.0-SNAPSHOT:
  > The following artifacts could not be resolved:
  > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 (absent):
  > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 was not found
  >
  > By Xulin Yang
  > Kind Regards

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

[Mark Thomas]

On 16/04/2024 08:18, Mark Thomas wrote:



Tomcat's current implementation is based on RFC 2617 and allows the 
following:

- white space around the base64
- allows embedded line breaks in the base64
- missing padding
- illegal characters in the base64 (ignored)
- illegal characters in the base64 padding (ignored)
- excessive padding
- whitespace around the decoded password

I don't see any of the above causing issues apart from the last one 
which prevents the use of passwords with leading or trailing whitespace.


Just following up on this.

Prior to Tomcat 9.0.15, Tomcat always did this.

From 9.0.15 Tomcat did this by default but it could be disabled.

Intend to remove this feature from Tomcat 11 and disable it by default 
in earlier versions.


Mark

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

Re: jakartaee/servlet pom.xml

[Mark Thomas]

The list drops images. What changed?

Mark


On 16/04/2024 07:52, xulin y wrote:

Hi,

image.png
You can see this version was changed from 6.1.0-M2 to 6.1.0 on 2024 Mar 
27 while 6.1.0 is not present in 
https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/ <https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>

image.png

By Xulin Yang
Kind Regards

Mark Thomas mailto:ma...@apache.org>> 于2024年4月16日 
周二 14:48写道：


How is this an Apache Tomcat issue?

Mark


On 16/04/2024 07:41, xulin y wrote:
 > Hi,
 >
 > System OS: Windows 10
 > Maven: 3.9.6
 > Java: 17.0.1
 >
 > When I was "mvn install" jakartaee/servlet on my desktop. I found
 >
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37 
<https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37> 
<https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37 
<https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37>> can give me exception. 
This is because https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/ 
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/> 
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/ 
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>> does not have 
jakarta.servlet-api 6.1.0
 > image.png
 > I use 6.1.0-SNAPSHOT on my desktop instead. Could you take a look
at this?
 >
 > Appendix:
 > [ERROR] Failed to execute goal on project tck-runtime: Could not
resolve
 > dependencies for project
jakarta.servlet:tck-runtime:jar:6.1.0-SNAPSHOT:
 > The following artifacts could not be resolved:
 > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 (absent):
 > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 was not found
 >
 > By Xulin Yang
 > Kind Regards

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



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

Base64 and BASIC authentication

[Mark Thomas]

Hi all,

TL;DR - we need to tighten up parsing of BASIC authentication headers.

When I switched out Tomcat's Base64 handling for the built-in JRE 
handling, I noticed that BASIC authentication was using a very relaxed 
version of the Base64 decoder. That seemed odd, so I replaced it with 
the standard Base64 decoder. That broke a bunch of tests so I switched 
to the MIME decoder (the most relaxed) which fixed most - but not all - 
of the issues. Then I started look at what the tests were testing and 
the relevant RFCs.


The current RFC for HTTP BASIC authentication is RFC 7617. This in turn 
references numerous other RFCs, most notably RFC 7235 (HTTP 
Authentication) and RFC 4648 (Base64). Taken together these require that 
the format of the Authorization header is:

- The token "Basic"
- Exactly 1 space
- The base64 encoding of username:password

Tomcat's current implementation is based on RFC 2617 and allows the 
following:

- white space around the base64
- allows embedded line breaks in the base64
- missing padding
- illegal characters in the base64 (ignored)
- illegal characters in the base64 padding (ignored)
- excessive padding
- whitespace around the decoded password

I don't see any of the above causing issues apart from the last one 
which prevents the use of passwords with leading or trailing whitespace. 
This is mostly of a cleaning up exercise so the switch to Java's base64 
decoder is simpler.


Before I merge the change to use the JRE's Base64 encoder, I intend to 
tighten up the parsing of Basic authentication headers. I intend to do 
this for all currently supported versions.


Any objections?

Mark

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

Re: jakartaee/servlet pom.xml

[Mark Thomas]

How is this an Apache Tomcat issue?

Mark


On 16/04/2024 07:41, xulin y wrote:

Hi,

System OS: Windows 10
Maven: 3.9.6
Java: 17.0.1

When I was "mvn install" jakartaee/servlet on my desktop. I found 
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37  can give me exception. This is because https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/  does not have jakarta.servlet-api 6.1.0

image.png
I use 6.1.0-SNAPSHOT on my desktop instead. Could you take a look at this?

Appendix:
[ERROR] Failed to execute goal on project tck-runtime: Could not resolve 
dependencies for project jakarta.servlet:tck-runtime:jar:6.1.0-SNAPSHOT: 
The following artifacts could not be resolved: 
jakarta.servlet:jakarta.servlet-api:jar:6.1.0 (absent): 
jakarta.servlet:jakarta.servlet-api:jar:6.1.0 was not found


By Xulin Yang
Kind Regards


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

Re: (tomcat) 01/06: Remove unused code - thanks to UCDetector

[Mark Thomas]

On 05/04/2024 12:55, Mark Thomas wrote:

5 Apr 2024 04:33:42 Christopher Schultz :


Mark,

Can't this entire class be replaced with calls to 
java.util.Base64.get*Encoder and java.util.Base64.get*Decoder wherever 
necessary?


Now that 9.0.x is oldest, we should be able to use java.util.Base64 
from Java 1.8+


Possibly. There is a commit from 2.0.x that does that that we could back 
port.


The one thing I wanted to check was that the Tomcat one was stricter for 
URL safe Vs non URL safe. I wasn't sure how that applied here.


My main concern was aligning 9.0.x through 11.0.x which is now done. 
Improvements like this were next on the TODO list for File upload.


I've done more checks and it was the commons implementation that used 
the same decoder for standard and URL-safe. The Java implementation has 
specific decoders for each.


It looks like we can remove the o.a.tomcat.util.codec.binary package 
completely. I'll take a look. If it is possible then the plan would be 
remove in 11.0.x and deprecate in 10.1.x and earlier just in case 
someone is using the Tomcat internals directly.


Mark

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

Re: April releases

[Mark Thomas]

On 07/04/2024 17:44, Rémy Maucherat wrote:

On Sat, Apr 6, 2024 at 2:21 PM Mark Thomas  wrote:


5 Apr 2024 14:18:49 Rémy Maucherat :


On Fri, Apr 5, 2024 at 2:02 PM Mark Thomas  wrote:


Hi all,

Just a heads up that I have a lot on my plate at the moment and the
April
tag for 11.0.x is unlikely to happen for a couple of weeks.

There are changes I'd like to see in a release but I don't think there
is
anything urgent.


I can help by doing the 11 M release. I would probably skip the
localization update for this round though.


That would be great if you could.

I'm hoping to get some Commons FileUpload changes finished over the
weekend if you can wait until Monday.


I cannot do anything on weekends these days.


Ack.


I figured out how the import/export from poeditor worked, but I'm a
bit worried about clicking import on the website. I would import the
properties with the full US strings, but without "Overwrite existing
translations" ?


You want to overwrite the translations to pick up any updates to the 
English versions.



So most likely I'll only import the languages with some updates and that's it.


That would be great.

Mark

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

Re: April releases

[Mark Thomas]

5 Apr 2024 14:18:49 Rémy Maucherat :


On Fri, Apr 5, 2024 at 2:02 PM Mark Thomas  wrote:


Hi all,

Just a heads up that I have a lot on my plate at the moment and the 
April

tag for 11.0.x is unlikely to happen for a couple of weeks.

There are changes I'd like to see in a release but I don't think there 
is

anything urgent.


I can help by doing the 11 M release. I would probably skip the
localization update for this round though.


That would be great if you could.

I'm hoping to get some Commons FileUpload changes finished over the 
weekend if you can wait until Monday.


Mark




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

April releases

[Mark Thomas]

Hi all,

Just a heads up that I have a lot on my plate at the moment and the April 
tag for 11.0.x is unlikely to happen for a couple of weeks.


There are changes I'd like to see in a release but I don't think there is 
anything urgent.


Mark

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

Re: (tomcat) 01/06: Remove unused code - thanks to UCDetector

[Mark Thomas]

5 Apr 2024 04:33:42 Christopher Schultz :


Mark,

Can't this entire class be replaced with calls to 
java.util.Base64.get*Encoder and java.util.Base64.get*Decoder wherever 
necessary?


Now that 9.0.x is oldest, we should be able to use java.util.Base64 
from Java 1.8+


Possibly. There is a commit from 2.0.x that does that that we could back 
port.


The one thing I wanted to check was that the Tomcat one was stricter for 
URL safe Vs non URL safe. I wasn't sure how that applied here.


My main concern was aligning 9.0.x through 11.0.x which is now done. 
Improvements like this were next on the TODO list for File upload.


Mark




?

-chris

On 4/4/24 15:52, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 1a2f722e405ec17c5dab5fac43ae2fe63eb8fbce
Author: Mark Thomas 
AuthorDate: Fri Jun 17 12:29:10 2022 +0100
 Remove unused code - thanks to UCDetector
---
  .../apache/tomcat/util/codec/binary/Base64.java    | 155 
-
  .../tomcat/util/codec/binary/BaseNCodec.java   |  88 


  2 files changed, 243 deletions(-)
diff --git a/java/org/apache/tomcat/util/codec/binary/Base64.java 
b/java/org/apache/tomcat/util/codec/binary/Base64.java

index a733df9937..e38bf3df17 100644
--- a/java/org/apache/tomcat/util/codec/binary/Base64.java
+++ b/java/org/apache/tomcat/util/codec/binary/Base64.java
@@ -16,9 +16,6 @@
   */
  package org.apache.tomcat.util.codec.binary;
  -import java.math.BigInteger;
-import java.util.Objects;
-
  /**
   * Provides Base64 encoding and decoding as defined by href="http://www.ietf.org/rfc/rfc2045.txt;>RFC 2045.

   *
@@ -141,20 +138,6 @@ public class Base64 extends BaseNCodec {
  // The private member fields below are used with the new 
streaming approach, which requires
  // some state be preserved between calls of encode() and 
decode().

  -    /**
- * Decodes Base64 data into octets.
- * 
- * Note: this method seamlessly handles data encoded in 
URL-safe or normal mode.

- * 
- *
- * @param base64Data
- *    Byte array containing Base64 data
- * @return Array containing decoded data.
- */
-    public static byte[] decodeBase64(final byte[] base64Data) {
-    return decodeBase64(base64Data, 0, base64Data.length);
-    }
-
  public  static byte[] decodeBase64(
  final byte[] base64Data, final int off, final int len) {
  return new Base64().decode(base64Data, off, len);
@@ -180,29 +163,6 @@ public class Base64 extends BaseNCodec {
  }
    // Implementation of integer encoding used for crypto
-    /**
- * Decodes a byte64-encoded integer according to crypto standards 
such as W3C's XML-Signature.

- *
- * @param pArray
- *    a byte array containing base64 character data
- * @return A BigInteger
- * @since 1.4
- */
-    public static BigInteger decodeInteger(final byte[] pArray) {
-    return new BigInteger(1, decodeBase64(pArray));
-    }
-
-    /**
- * Encodes binary data using the base64 algorithm but does not 
chunk the output.

- *
- * @param binaryData
- *    binary data to encode
- * @return byte[] containing Base64 characters in their UTF-8 
representation.

- */
-    public static byte[] encodeBase64(final byte[] binaryData) {
-    return encodeBase64(binaryData, false);
-    }
-
  /**
   * Encodes binary data using the base64 algorithm, optionally 
chunking the output into 76 character blocks.

   *
@@ -272,17 +232,6 @@ public class Base64 extends BaseNCodec {
  return b64.encode(binaryData);
  }
  -    /**
- * Encodes binary data using the base64 algorithm and chunks the 
encoded output into 76 character blocks

- *
- * @param binaryData
- *    binary data to encode
- * @return Base64 characters chunked in 76 character blocks
- */
-    public static byte[] encodeBase64Chunked(final byte[] binaryData) 
{

-    return encodeBase64(binaryData, true);
-    }
-
  /**
   * Encodes binary data using the base64 algorithm but does not 
chunk the output.

   *
@@ -298,19 +247,6 @@ public class Base64 extends BaseNCodec {
  return StringUtils.newStringUsAscii(encodeBase64(binaryData, 
false));

  }
  -    /**
- * Encodes binary data using a URL-safe variation of the base64 
algorithm but does not chunk the output. The
- * url-safe variation emits - and _ instead of + and / 
characters.

- * Note: no padding is added.
- * @param binaryData
- *    binary data to encode
- * @return byte[] containing Base64 characters in their UTF-8 
representation.

- * @since 1.4
- */
-    public static byte[] encodeBase64URLSafe(final byte[] binaryData) 
{

-    return encodeBase64(binaryData, fal

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Mark Thomas]

On 27/03/2024 08:48, Romain Manni-Bucau wrote:

Hi all,

Checkout out TomEE's notifications I realized Tomcat is in a weirdish
situation where Tomcat 9 is Servlet 4 and "+1" version is Tomcat 10.1 which
is Servlet 6.
It means Tomcat is no more a Servlet 5 friendly option.

I wonder if it means Tomcat < 10.1 should be stopped too or if Tomcat 10.0
should be maintained and released again - pretty sure we can find help if
desired for that not that far.
Another option is to restore the deleted methods between servlet 5-6 in the
code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?


-1 to stopping Tomcat 9.0.x support.

No interest in supporting 10.0.x

This has been discussed at length previously. Those discussions can be 
found in the archives.


The short version is:
- Tomcat 9.x (Java EE8) will be maintained for the foreseeable future at
  it is the last branch to support Java EE.
- Jakarta EE 9 (Tomcat 10.0) was a transition release that we only ever
  intended to maintain for as long as it took for Jakarta EE 10 (Tomcat
  10.1) to reach stability

Mark

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

Re: Instruct the tomcat source builders before the build process for tomcat source 8.5.100

[Mark Thomas]

On 22/03/2024 10:54, Koteswararao Gundapaneni wrote:

Hi,

While building the tomcat source 8.5.100 its giving an error with java 7

below is the error

ANT_OPTS is set to  -Djava.security.manager=allow
Error occurred during initialization of VM
java.lang.UnsupportedClassVersionError: allow : Unsupported major.minor
version 52.0

in Building.txt file it has the following instruction

  3. Install the JDK according to the instructions included with the release.

so if am not wrong, we could suggest java11 is required for the build
process in the instructions given


Yes, you are wrong.

PLEASE read the documentation first. Specifically this sentence from 
BUILDING.txt



Download a version 11 or later of Java Development Kit...


Mark

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

Re: [VOTE] Release Apache Tomcat 10.1.20

[Mark Thomas]

On 19/03/2024 13:52, Christopher Schultz wrote:


The proposed 10.1.20 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.1.20


Tests pass on Linux, Windows and MacOS (M1).

The build is reproducible.

Mark

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

Re: [VOTE] Release Apache Tomcat 8.5.100

[Mark Thomas]

On 19/03/2024 14:23, Christopher Schultz wrote:


The proposed 8.5.100 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 8.5.100 (stable)


Tests pass on Linux, Windows and MacOS (M1).

The build is reproducible.

Mark

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

Re: (tomcat) branch main updated: IDE says this is no longer required

[Mark Thomas]

On 18/03/2024 22:18, Rémy Maucherat wrote:

On Mon, Mar 18, 2024 at 9:30 PM Mark Thomas  wrote:


On 18/03/2024 20:24, 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


The following commit(s) were added to refs/heads/main by this push:
   new 1972d821a0 IDE says this is no longer required
1972d821a0 is described below

commit 1972d821a093002328e7a43c4a7e2ef1fb017af2
Author: Mark Thomas 
AuthorDate: Mon Mar 18 20:24:07 2024 +

  IDE says this is no longer required


Just realised this was new rather than old. I'm guessing you are
compiling with Java 22 in the IDE which is why you need this?


Yes, it's an IDE warning.


No problem. I'll revert my change.

Mark

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

Re: (tomcat) branch main updated: IDE says this is no longer required

[Mark Thomas]

On 18/03/2024 20:24, 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


The following commit(s) were added to refs/heads/main by this push:
  new 1972d821a0 IDE says this is no longer required
1972d821a0 is described below

commit 1972d821a093002328e7a43c4a7e2ef1fb017af2
Author: Mark Thomas 
AuthorDate: Mon Mar 18 20:24:07 2024 +

 IDE says this is no longer required


Just realised this was new rather than old. I'm guessing you are 
compiling with Java 22 in the IDE which is why you need this?


Mark


---
  java/org/apache/tomcat/util/net/AbstractEndpoint.java | 1 -
  1 file changed, 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java 
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index 2c8a77ddd2..b63a493c27 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -1240,7 +1240,6 @@ public abstract class AbstractEndpoint {
  this.executor = null;
  if (executor instanceof ThreadPoolExecutor) {
  //this is our internal one, so we need to shut it down
-@SuppressWarnings("resource")
  ThreadPoolExecutor tpe = (ThreadPoolExecutor) executor;
  tpe.shutdownNow();
  long timeout = getExecutorTerminationTimeoutMillis();


-
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: Very sporadic test failures in org.apache.catalina.core.TestAsyncContextImpl for TC 8.5 and 9

[Mark Thomas]

On 08/03/2024 20:28, Rainer Jung wrote:
Again, this is not a new failure and it happens extremely infrequent. 
Observed with JSSE on various Linux distributions and with various JVM 
versions and vendors. Only observed for TC 8.5 and 9, but for 10.1 and 
11 the unit tests are run with much fewer JVM combinations so I can not 
exclude the problem might happen there as well.


Looks like a timing issue when we have a non-container thread still 
accessing the AsyncContext (it shouldn't do that).


The test acknowledged the problem but you found another fisalure mode 
that wasn't handled. It now is. Hopefully, these tests should be more 
reliable going forwards.


Mark




This info is not intended to prevent a release.

The typical situation is:

Testcase: testBug49567 took 21.162 sec
     FAILED
expected:<...alse2true3true4true5[false]> but 
was:<...alse2true3true4true5[]>
junit.framework.AssertionFailedError: 
expected:<...alse2true3true4true5[false]> but 
was:<...alse2true3true4true5[]>
     at 
org.apache.catalina.core.TestAsyncContextImpl.testBug49567(TestAsyncContextImpl.java:163)
     at 
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)


The execution log contains:

22-Feb-2024 11:19:03.617 INFO [main] 
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case 
[testBug49567]
22-Feb-2024 11:19:03.626 INFO [main] 
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["http-nio-127.0.0.1-auto-11"]
22-Feb-2024 11:19:03.627 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Tomcat]
22-Feb-2024 11:19:03.627 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet 
engine: [Apache Tomcat/9.0.86]
22-Feb-2024 11:19:03.640 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]
Exception in thread "Thread-9" java.lang.NullPointerException: Cannot 
invoke "org.apache.catalina.connector.Request.getCoyoteRequest()" 
because "this.request" is null
     at 
org.apache.catalina.core.AsyncContextImpl.isStarted(AsyncContextImpl.java:295)
     at 
org.apache.catalina.connector.Request.isAsyncStarted(Request.java:1715)
     at 
org.apache.catalina.connector.RequestFacade.isAsyncStarted(RequestFacade.java:749)
     at 
org.apache.catalina.core.TestAsyncContextImpl$Bug49567Servlet$1$1.run(TestAsyncContextImpl.java:383)

     at java.base/java.lang.Thread.run(Thread.java:1583)
22-Feb-2024 11:19:24.685 INFO [main] 
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]
22-Feb-2024 11:19:24.693 INFO [main] 
org.apache.catalina.core.StandardService.stopInternal Stopping service 
[Tomcat]
22-Feb-2024 11:19:24.729 INFO [main] 
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]
22-Feb-2024 11:19:24.739 INFO [main] 
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]



or as a variation:

08-Mar-2024 14:44:59.132 INFO [main] 
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case 
[testBug49528]
08-Mar-2024 14:44:59.141 INFO [main] 
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["http-nio2-127.0.0.1-auto-10"]
08-Mar-2024 14:44:59.151 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Tomcat]
08-Mar-2024 14:44:59.151 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet 
engine: [Apache Tomcat/9.0.86sp1]
08-Mar-2024 14:44:59.170 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
["http-nio2-127.0.0.1-auto-10-37101"]
java.lang.NullPointerException: Cannot invoke 
"org.apache.catalina.connector.Request.getCoyoteRequest()" because 
"this.request" is null
     at 
org.apache.catalina.core.AsyncContextImpl.isStarted(AsyncContextImpl.java:295)
     at 
org.apache.catalina.connector.Request.isAsyncStarted(Request.java:1715)
     at 
org.apache.catalina.connector.RequestFacade.isAsyncStarted(RequestFacade.java:749)
     at 
org.apache.catalina.core.TestAsyncContextImpl$Bug49528Servlet$1.run(TestAsyncContextImpl.java:303)
     at 
org.apache.catalina.core.AsyncContextImpl$RunnableWrapper.run(AsyncContextImpl.java:543)
     at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
     at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
     at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)

     at java.base/java.lang.Thread.run(Thread.java:1583)
08-Mar-2024 14:45:00.196 INFO [main] 
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler 
["http-nio2-127.0.0.1-auto-10-37101"]
08-Mar-2024 14:45:00.198 INFO [main] 

Re: Plans for 10.1.x and 8.5.x release?

[Mark Thomas]

On 15/03/2024 12:08, Koteswararao Gundapaneni wrote:

Hi

Innovations are on the way for both 10.1.x and 8.5.x


OK. I'll bite. What innovations?

Mark




regards,
Koti

On Fri, Mar 15, 2024 at 4:53 AM Mark Thomas  wrote:


Chris,

Just wondering what your thinking was for the March releases of 10.1.x
and 8.5.x

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

Plans for 10.1.x and 8.5.x release?

[Mark Thomas]

Chris,

Just wondering what your thinking was for the March releases of 10.1.x 
and 8.5.x


Mark

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

Re: Requesting as I had been agreed to commit from a contributor role

[Mark Thomas]

On 15/03/2024 01:41, koteswara Rao Gundapaneni wrote:

Ok let me know I can use the below email as the future mailing address


apache.tomcat.k...@gmail.com


Something like that


Unsubscribe your old address.

Subscribe your new address.

Full instructions can be found at https://tomcat.apache.org/lists.html

Mark





Regards
Koti



On Fri, 15 Mar 2024, 00:35 Christopher Schultz, <
ch...@christopherschultz.net> wrote:


Koteswararao,

On 3/14/24 14:21, Mark Thomas wrote:

On 14/03/2024 13:43, koteswara Rao Gundapaneni wrote:



On Thu, 14 Mar 2024, 00:28 koteswara Rao Gundapaneni,
mailto:koti.gundapan...@gmail.com>> wrote:


 HI Tomcat PMC,

 Please ensure I had showing my interest as a committer as I have
 been passed my contribution status from a range of having said
 that few contributions


Simply saying I have been showing my interest to work as committer


Please approve my icla


There is nothing to approve. You submitted your ICLA. It has been filed
by the ASF secretary.

I'll note that:
- no-one asked you to file an ICLA
- there was no need for you to file an ICLA
- the only thing filing an ICLA achieved was wasting the precious
resource of volunteer time

I *strongly* urge you to read the advice (including the references to
how the ASF works) you have been given on and off list, stop wasting
precious volunteer time and think very carefully before you post
anything else to a Tomcat mailing list.


Definitely read ASF How It Works, specifically the section on
Meritocracy[1]. You cannot simply ask to become a committer on a
project. Instead, you have to demonstrate to the existing project
participants that you *deserve* to be /invited/ as a committer.

So far, the weird series of PRs and emails you have sent are not making
you look good.

I'm not trying to be mean. I'm trying to be honest and use simple language.

-chris

[1] https://www.apache.org/foundation/how-it-works/#meritocracy

-
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 11.0.0-M18 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M18 (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-M18 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-M17 include:


- Reduce minimum Java version to Java 17

- When restoring a saved POST request after a successful FORM
  authentication, ensure that neither the URI, the query string no
  the protocol are corrupted when restoring the request body.

- Align error handling for Writer and OutputStream. Ensure use of either
  once the response has been recycled triggers a NullPointerException
  provided that discardFacades is configured with the default value of
  true.

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

Re: Requesting as I had been agreed to commit from a contributor role

[Mark Thomas]

On 14/03/2024 13:43, koteswara Rao Gundapaneni wrote:



On Thu, 14 Mar 2024, 00:28 koteswara Rao Gundapaneni, 
mailto:koti.gundapan...@gmail.com>> wrote:



HI Tomcat PMC,

Please ensure I had showing my interest as a committer as I have
been passed my contribution status from a range of having said
that few contributions 




Simply saying I have been showing my interest to work as committer


Please approve my icla


There is nothing to approve. You submitted your ICLA. It has been filed 
by the ASF secretary.


I'll note that:
- no-one asked you to file an ICLA
- there was no need for you to file an ICLA
- the only thing filing an ICLA achieved was wasting the precious
  resource of volunteer time

I *strongly* urge you to read the advice (including the references to 
how the ASF works) you have been given on and off list, stop wasting 
precious volunteer time and think very carefully before you post 
anything else to a Tomcat mailing list.


Mark

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

Re: Requesting as I had been agreed to commit from a contributor role

[Mark Thomas]

Koteswararao,

This message makes no sense.

Please follow the advice you have been given multiple times off-list to 
either post in your native language and let recipients use Google 
translate if required or use Google translate yourself.


If you continue to ignore the advice you have been given, you will be 
blocked from posting to all Tomcat mailing lists.


Mark


On 14/03/2024 11:16, koteswara Rao Gundapaneni wrote:

On Thu, 14 Mar 2024, 00:28 koteswara Rao Gundapaneni, <
koti.gundapan...@gmail.com> wrote:



HI Tomcat PMC,


Please ensure I had showing my interest as a committer as I have been
passed my contribution status from a range of having said that few
contributions

regards,
Koteswararao







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

Re: (tomcat-tck) 02/04: Update to 11.0.0-M18 release and EL API 6.0.0

[Mark Thomas]

FYI, 11.0.0-M18 passes the EL 6.0 TCK and I'll be using that (rather 
than the previous 11.0.0-M18-SNAPSHOT) to provide the certified 
implementation I need to complete the EL 6.0 release over at Eclipse.


Mark


On 14/03/2024 10:12, 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-tck.git

commit f8f0e68378d5677594453ca912d4fbb9da0865f0
Author: Mark Thomas 
AuthorDate: Thu Mar 14 10:09:17 2024 +

 Update to 11.0.0-M18 release and EL API 6.0.0
---
  pom.xml | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pom.xml b/pom.xml
index b4498ba..72e0b0f 100644
--- a/pom.xml
+++ b/pom.xml
@@ -31,13 +31,13 @@
  17
  
  

-11.0.0-M18-SNAPSHOT
+11.0.0-M18
  
  

  6.0.0
-6.0.0-SNAPSHOT
+6.0.0
  6.1.0-SNAPSHOT
-4.0.0-SNAPSHOT
+4.0.0
  10.0.0-SNAPSHOT
  
  



-
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][RESULT} Release Apache Tomcat 11.0.0-M18

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, remm, schultz, lihan

Non-Binding:
+1: Dimitris Soumis

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 09/03/2024 18:52, Mark Thomas wrote:

The proposed Apache Tomcat 11.0.0-M18 release is now available for
voting.

Apache Tomcat 11.0.0-M18 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:


- Reduce minimum Java version to Java 17

- When restoring a saved POST request after a successful FORM
   authentication, ensure that neither the URI, the query string no
   the protocol are corrupted when restoring the request body.

- Align error handling for Writer and OutputStream. Ensure use of either
   once the response has been recycled triggers a NullPointerException
   provided that discardFacades is configured with the default value of
   true.

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-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-M18/

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

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M18
eee0dbb29048a60ee2c85ebcb9abb1750046c0bf

The proposed 11.0.0-M18 release is:
[ ] -1 Broken - do not release
[ ] +1 Alpha  - go ahead and release as 11.0.0-M18

-
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

[SECURITY] CVE-2024-23672 Apache Tomcat - Denial of Service

[Mark Thomas]

CVE-2024-23672 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
It was possible for a WebSocket client to keep a WebSocket connection 
open leading to increased resource consumption.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

History:
2024-03-13 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html

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

[SECURITY] CVE-2024-24549 Apache Tomcat - Denial of Service

[Mark Thomas]

CVE-2024-24549 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
When processing an HTTP/2 request, if the request exceeded any of the 
configured limits for headers, the associated HTTP/2 stream was not 
reset until after all of the headers had been processed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Bartek Nowotarski (https://nowotarski.info/).


History:
2024-03-13 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html

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

Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.

[Mark Thomas]

On 13/03/2024 14:38, Rémy Maucherat wrote:

 wrote:





1. A longer default nag-duration


That's a good start. If it is meant to be enabled by default, I would
like a value that is long enough so that it is almost certain there's
an issue. 2 years ?

Rémy


2. Add an explicit "disable" (e.g. -1)


I was thinking yes to this and setting it to -1 by default.


3. Disable the feature by default

4. Remove this feature entirely

The target for this was really 8.5 which will immediately go
out-of-support once 8.5.100 is released. So really the default for
8.5.100 should be "nag immediately", but we can't expect that anybody
really uses the out-of-the-box server.xml without any customizations, so
specifically setting the duration to some small number of days in
server.xml isn't going to have any effect.


The more I think about this the more I wonder if some further tweaks are 
required.


This check only runs at startup. There are some (very) long running 
Tomcat instances out there. Is on startup enough? Should this check be 
periodic? If yes, how periodic? Once a day? Probably whatever frequency 
we went for with the TLS reload warnings would be about right.


Mark

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

Re: [VOTE] Release Apache Tomcat 9.0.87

[Mark Thomas]

On 11/03/2024 11:09, Rémy Maucherat wrote:


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


Tests pass on Linux, Windows and MacOS (M1).

I'm currently unable to test on Intel MacOS due to security software 
recently installed by $dayjob.


The build is repeatable.

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

Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.

[Mark Thomas]

On 11/03/2024 21:38, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 3ab883aa746a5c577efa39d9080858e53ca77da6
Author: Christopher Schultz 
AuthorDate: Mon Mar 11 17:38:01 2024 -0400

 Add checking for the age of the Tomcat version running and warn if it's 
getting old.


How do I disable this check if I don't want to use it? I'd expect 
something like set it to "-1".


Mark

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

Drop jspxml.dtd and jspxml.xsd

[Mark Thomas]

The jspxml files are located in the jakarta.servlet.jsp.resources packages.

They do not appear to have been updated since Tomcat 5.

They are not part of the JSP JAR provided by Jakarta EE. I can't find 
them anywhere in the Jakarta EE repositories.


I'd like to drop them in Tomcat 11. I will do so for the next release 
unless I hear any objections.


Mark


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

Re: [VOTE] Release Apache Tomcat 11.0.0-M18

[Mark Thomas]

On 09/03/2024 18:52, Mark Thomas wrote:


The proposed 11.0.0-M18 release is:
[ ] -1 Broken - do not release
[X] +1 Alpha  - go ahead and release as 11.0.0-M18


Test pass on Linux, Windows and M1 MacOS.

The build is reproducible across Windows/Linux.

I'm unable to test on Intel MacOS due to security software recently 
installed by $dayjob.


Mark

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

[VOTE] Release Apache Tomcat 11.0.0-M18

[Mark Thomas]

The proposed Apache Tomcat 11.0.0-M18 release is now available for
voting.

Apache Tomcat 11.0.0-M18 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:


- Reduce minimum Java version to Java 17

- When restoring a saved POST request after a successful FORM
  authentication, ensure that neither the URI, the query string no
  the protocol are corrupted when restoring the request body.

- Align error handling for Writer and OutputStream. Ensure use of either
  once the response has been recycled triggers a NullPointerException
  provided that discardFacades is configured with the default value of
  true.

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-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-M18/

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

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M18
eee0dbb29048a60ee2c85ebcb9abb1750046c0bf

The proposed 11.0.0-M18 release is:
[ ] -1 Broken - do not release
[ ] +1 Alpha  - go ahead and release as 11.0.0-M18

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

Re: Add support for HTTP connectors to accept REMOTE_USER information from a proxy?

[Mark Thomas]

On 06/03/2024 08:51, Christopher Schultz wrote:

All,

*bump*

Any thoughts?


I'd go with the RemoteIPValve.

Mark



-chris

On 2/28/24 14:53, Christopher Schultz wrote:

All,

When using AJP, setting tomcatAuthentication="false" allows mod_jk or 
mod_proxy_ajp to transmit authenticated user information across the 
connection to Tomcat so that request.getRemoteUser() will return 
whatever httpd has for REMOTE_USER.


The same is not true for the HTTP connectors.

   RemoteIPValve takes care of X-Forwarded-* headers

   SSLValve takes care of SSL_* variables for cipher, client cert, etc.

This appears to be one of the only commonly-used pieces of information 
that is difficult to transmit across HTTP while it's easy with AJP.


https://lists.apache.org/thread/bmps52nv8h63mkfqhzmh7p5bhhglgbpl

As a part of my crusade to get people to move from AJP to HTTP, I'd 
like to propose that we make arrangements for this information to be 
transmitted in some reasonable way.


One way to do it would be to add something to RemoteIPValve that would 
be willing to accept e.g. X-Remote-User header and assign that to the 
request. (This would be disabled by default!) Straightforward, 
relatively easy to understand and configure, and uses existing 
components. But perhaps X-Remote-User is "out of scope" for 
RemoteIPValve?


Another way would be to add tomcatAuthentication="false" as an option 
for the HTTP connector. It would behave like its AJP twin, except it 
would look in HTTP headers for ... X-Remote-User? REMOTE_USER? 
Somethign user-configurable? While this option mirrors the way it's 
done for AJP, I don't like it as much as using RemoteIPValve, if for 
no other reason than it has nothing to do with the connector itself 
and the RemoteIPValve already has similar configuration options for 
setting the names of special HTTP headers.


We could introduce a new Valve that just does this, and maybe adds 
other things later that we find are also missing. This introduces a 
completely new component, makes the valve chain even longer, etc. and 
so I still favor adding this to RemoteIPValve.


Thoughts?

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: Sporadic Failures in org.apache.coyote.http2.TestRfc9218

[Mark Thomas]

On 07/03/2024 11:20, Rainer Jung wrote:
As always thanks a lot for the investigation and forthcoming fix. Let me 
know when I can help!


I've committed a fix that worked for me locally but I was focring the 
test failure via the debugger. I'm fairly sure this is the issue you 
were seeing but iof you are able to re-run your tests that would be very 
helpful.


Thanks,

Mark



Am 07.03.24 um 16:55 schrieb Mark Thomas:

On 02/03/2024 05:58, Rainer Jung wrote:

Hi there,

for a long time I get sporadic failures in 
org.apache.coyote.http2.TestRfc9218. It happens for all branches of 
TC, for NIO and NIO2 and with JSSE and tcnative. Tested platforms 
Linux and Solaris see this. And JVM versions 1.8.0, 11, 17 and 21 
show it. It is also not restricted to a specific JDK vendor.


Rainer,

Thanks for raising this. I have worked out what the root cause is. 
Esentially, it is a timing issue.


When stream 17 does its write, it writes 1k of the 8k response. Before 
it tries to write the remaining 7k, streams 19 and/or 21 attempt to 
write 8k, the connection window is extended by a further 1k and that 
1k is allocated to stream 19 or 21 depending on which streams have 
attempted to write the 8k body by then.


I have a fix in mind which involves adding stream 17 to the backlog as 
soon as it attempts to write more than the connection window will 
allow. I need to do some more work on this as I am seeing some test 
failures with my first attempt at a pacth.


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: Sporadic Failures in org.apache.coyote.http2.TestRfc9218

[Mark Thomas]

On 02/03/2024 05:58, Rainer Jung wrote:

Hi there,

for a long time I get sporadic failures in 
org.apache.coyote.http2.TestRfc9218. It happens for all branches of TC, 
for NIO and NIO2 and with JSSE and tcnative. Tested platforms Linux and 
Solaris see this. And JVM versions 1.8.0, 11, 17 and 21 show it. It is 
also not restricted to a specific JDK vendor.


Rainer,

Thanks for raising this. I have worked out what the root cause is. 
Esentially, it is a timing issue.


When stream 17 does its write, it writes 1k of the 8k response. Before 
it tries to write the remaining 7k, streams 19 and/or 21 attempt to 
write 8k, the connection window is extended by a further 1k and that 1k 
is allocated to stream 19 or 21 depending on which streams have 
attempted to write the 8k body by then.


I have a fix in mind which involves adding stream 17 to the backlog as 
soon as it attempts to write more than the connection window will allow. 
I need to do some more work on this as I am seeing some test failures 
with my first attempt at a pacth.


Mark

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

Re: March releases

[Mark Thomas]

On 27/02/2024 09:29, Christopher Schultz wrote:

Mark,

On 2/27/24 06:20, Mark Thomas wrote:

On 27/02/2024 10:57, Rémy Maucherat wrote:

On Tue, Feb 27, 2024 at 10:12 AM Mark Thomas  wrote:


All,

When I look at the current change logs there isn't much there to 
justify

a March release. There are a couple of open bugs of which one looks
likely that there is an actual issue to be fixed.

That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11
March. The change log may look different at that point.

It is probably too early to make a decision but I wanted to float the
possibility of skipping the March release. That would mean we'd 
probably

need to make the final 8.5.x release in April.


We don't need to always release all branches every time.


Good point.


For example, 11 already has two useful fixes right now: support for
Java 17 (one could want to verify it), then the FFM fix I made (using
the wrong loader in one location means it simply breaks depending on
how OpenSSL is loaded, so that's bad). But these two are not in the
other branches.


Ack. Those are good reasons for an 11.0.x release.

I just checked the dependencies - there are no updates at the moment.


As for a final 8.5, I would say it is not mandatory if there's nothing
useful in the changelog by the end of March. There's always going to
be a final final fix needed anyway. I started skipping some backports
to 8.5 since "regressions, who knows".


I was just thinking .100 was a nice point release to end on ;)


Yeah, me too ;)

I think we should release 8.5.100 in March, if only to meet our own goal 
of "ending support at the end of March". There isn't likely to be 
anything so important that it needs to be added after that.


We made a few exceptions for Tomcats 6, 7, and 8.0 for security issues, 
but I think there's no reason not to release 8.5.100 during March. I 
don't mind waiting until later in the month just in case anything comes 
up. Plus we can always change our minds and release again if there is 
something vital.


Following up on this, I think the bug fix for BZ 68495 does make it 
worth doing a set of releases this month.


The dependencies are up to date, I've just updated the translations and 
we don't have any open bugs at the moment.


There is the sproadic test failure issue that Rainer highlighted.

My plan, as I am not in a huge rush since the Feb releases were so late 
and I am travelling this week, is to look at that issue, check the unit 
tests all pass on the usual set of platforms and then tag 11.0.x.


I've just realised I don't have access to MacOS on Intel until the end 
of the week so I'm thinking tag 11.0.x on Friday if everything else goes 
to plan.


Mark

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

Re: svn commit: r1916061 - in /tomcat/site/trunk/docs/tck: ./ el-6.0.0-tomcat-11.0.0-M18-SNAPSHOT.txt

[Mark Thomas]

On 29/02/2024 20:57, ma...@apache.org wrote:

Author: markt
Date: Thu Feb 29 20:57:11 2024
New Revision: 1916061

URL: http://svn.apache.org/viewvc?rev=1916061=rev
Log:
Add certification summary for EL 6.0.0 TCK with Tomcat 11.0.0-M18-SNAPSHOT


This is a bit of an experiment. This particular certification is likely 
to be replaced once we have a proper 11.0.0-M18 release but I need a 
certified implementation to complete the release process for EL 6.0.0.


As my first attempt at a certification it is likely that that it will 
need some tweaks.


I'm expecting to need to certify Servlet, JSP and WebSocket towards the 
end of next month.


Medium to long term, my plan is to add certification to the nightly 
build process.


Mark

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

Re: March releases

[Mark Thomas]

On 27/02/2024 10:57, Rémy Maucherat wrote:

On Tue, Feb 27, 2024 at 10:12 AM Mark Thomas  wrote:


All,

When I look at the current change logs there isn't much there to justify
a March release. There are a couple of open bugs of which one looks
likely that there is an actual issue to be fixed.

That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11
March. The change log may look different at that point.

It is probably too early to make a decision but I wanted to float the
possibility of skipping the March release. That would mean we'd probably
need to make the final 8.5.x release in April.


We don't need to always release all branches every time.


Good point.


For example, 11 already has two useful fixes right now: support for
Java 17 (one could want to verify it), then the FFM fix I made (using
the wrong loader in one location means it simply breaks depending on
how OpenSSL is loaded, so that's bad). But these two are not in the
other branches.


Ack. Those are good reasons for an 11.0.x release.

I just checked the dependencies - there are no updates at the moment.


As for a final 8.5, I would say it is not mandatory if there's nothing
useful in the changelog by the end of March. There's always going to
be a final final fix needed anyway. I started skipping some backports
to 8.5 since "regressions, who knows".


I was just thinking .100 was a nice point release to end on ;)

Mark

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

March releases

[Mark Thomas]

All,

When I look at the current change logs there isn't much there to justify 
a March release. There are a couple of open bugs of which one looks 
likely that there is an actual issue to be fixed.


That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11 
March. The change log may look different at that point.


It is probably too early to make a decision but I wanted to float the 
possibility of skipping the March release. That would mean we'd probably 
need to make the final 8.5.x release in April.


Mark

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

Re: FFM in Tomcat 10.1

[Mark Thomas]

On 23/02/2024 13:35, Rémy Maucherat wrote:

Hi,

I would like to propose backporting the OpenSSL FFM support to Tomcat 10.1.

Java 22.0.0 should be released on March 19, and the next Java LTS
should still have no problem targeting Java 11. As a result, there
should be no negative impact to the platform support, and users
running on Java 22+ could benefit from easier OpenSSL support.

Obviously I anticipate most users will use FFM support once the next
Java LTS is out in a few years, but getting the feature out now would
still be good.

After the change:
- Compiling, running the testsuite, etc is still doable with Java 17.
- Running Tomcat 10.1 still works with Java 11.
- Building a Tomcat 10.1 release would now require Java 22+.

Backporting further to Tomcat 9.0 could be riskier however. Following
the removal of the Java 7 release target, Java 8 might be next. The
main question is if the next Java LTS will still support the Java 8
release target.

Comments ?


LGTM.

Mark

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

Re: Tomcat 8.5.99 artifacts not in Maven central

[Mark Thomas]

On 22/02/2024 20:03, S. Ali Tokmen wrote:

Dear Tomcat development team

The Tomcat 8.5.99 artifacts not in Maven central.

Is this normal?


No.

I've just checked and they weren't promoted from the staging repository. 
I've just done that. They should be in Maven Central shortly.


Mark

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

Re: Jakarta EE 11 may be changing minimum Java version to 17

[Mark Thomas]

On 21/02/2024 09:02, Rémy Maucherat wrote:

On Wed, Feb 21, 2024 at 1:28 AM Paul Nicolucci  wrote:


Hi,

At a minimum could the Expression Language be built to Java 17 bytecode?
There is nothing in the Expression Language that requires Java 21.

I have a branch with some initial changes to get that working here:
https://github.com/pnicolucci/tomcat/commit/cae7f1e02eaeaf16a75395d9bcdddc9a02e65580

Some additional manifest updates will be required that I can work on if the
community is open to this option.


Yes, this will be changed back to 17, along with almost everything else.

Overall I believe staying on 21 is not worth it as we would get tons
of requests for 17 support, just like yours.


+1. As much as I don't like it.


Rémy


Thanks,

Paul Nicolucci

On Tue, Feb 20, 2024 at 4:48 PM David Blevins 
wrote:


On Feb 20, 2024, at 8:08 AM, Mark Thomas  wrote:

Looking at the latest version of the Jakarta EE 11 release plan, the

minimum Java version has been dropped to Java 17.


https://jakartaee.github.io/platform/jakartaee11/JakartaEE11ReleasePlan

On that basis I think we have no choice but to reduce the minimum Java

version for Tomcat 11 to Java 17.

Implementations are not required to support Java 17,


That is certainly an interesting interpretation of the statement


Java SE 17 will become the minimum runtime supported by compatible 
implementations of Jakarta EE.




it is simply now one
of the allowed options.  We can absolutely continue with java 21 (or any
JDK 17 or up) if we like.


It appears the fudge being employed to meet the "must target Java 21 
direction" from the Jakarta EE steering committee is that a compatible 
implementation has to pass on at least one of Java 17 or Java 21 and 
each spec must have at least one compatible implementation (not 
necessarily the same one) that passes on each of Java 17 and Java 21.


As stated elsewhere, this is a recipe for user confusion. The least 
worst option for Tomcat users is to use Java 17 as the baseline.



The decision was made to allow implementations to certify with 17 support
if they wanted as none of the specs took advantage of Java 21 features,


Some specifications had started to use Java > 17 features. Granted only 
in a minor way that was relatively easy to work-around but they were 
being used.



so
there is no real basis to reject their certification requests.


That is not the justification that was used when the issue was raised. 
The justification was (lack of) market adoption.



 It is still
hoped there will be implementations that take advantage of Java 21 features
and brag publicly about them.


We aren't dropping any functionality by lowering the minimum version. 
Support for virtual threads, for example, will remain. All my patch does 
(which I'll commit shortly) is re-introduce the necessary JreCompat 
classes to enable Tomcat 11 to run on Java 17 onwards and take advantage 
of the features we want to take advantage of when running on later versions.


Mark

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

Re: Jakarta EE 11 may be changing minimum Java version to 17

[Mark Thomas]

Looking at the latest version of the Jakarta EE 11 release plan, the 
minimum Java version has been dropped to Java 17.


https://jakartaee.github.io/platform/jakartaee11/JakartaEE11ReleasePlan

On that basis I think we have no choice but to reduce the minimum Java 
version for Tomcat 11 to Java 17.


I have a branch with this change already in place. If there are no 
objections I'll merge those changes later this week.


Mark


On 19/01/2024 16:45, Volodymyr Siedlecki wrote:

Hi,

This is more compliance than function, unfortunately. Open Liberty
plans to pass the TCK under both 17 and 21 (although only one is
required).

If the EL jar we use is Java 21 byte code, then we wouldn't be able to
run the Jakarta EE 11 features on 17.

If Tomcat could compile EL against 17, that would be a huge help. If
not, we have workarounds.

Volodymyr


On Fri, Jan 19, 2024 at 9:41 AM Mark Thomas  wrote:


On 19/01/2024 14:20, Volodymyr Siedlecki wrote:

Hi Mark,

I understand your perspective about changing 21 to 17 so late.

Open Liberty uses Tomcat's Expression Language and we would prefer to
use a Java 17 binary. However, there are workarounds for us.


Ack.

I'll note that the EL code will compile quite happily with Java 17 or
Java 21.

Can you expand on why you'd prefer Java 17? Ignoring how late in the
process this change is being made, I've yet to hear a logically
consistent argument for selecting Java 17 over Java 21.


As for the EL TCK issue, I'd be happy to take a look if you push up a

branch.

Thanks for the offer but I have already fixed the issue.

Mark




Thank you,

Volodymyr


On Fri, Jan 19, 2024 at 6:38 AM Mark Thomas  wrote:


On 16/01/2024 11:44, Rémy Maucherat wrote:

On Tue, Jan 16, 2024 at 11:59 AM Mark Thomas  wrote:


Hi all,

I'm not sure what is going on as there has been one significant change
in the announcement already but it looks to me as if the minimum Java
version for Jakarta EE 11 is changing to Java 17 rather than Java 21.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg04371.html

It seems far too late in the day for this change to me but I'm not

sure

that view is going to carry much weight.

I've taken a quick look at the Tomcat 11 code base and a JreCompat for
Java 21 shouldn't be too much work. I'm not planning on doing anything
on this until the intentions of the Jakarta EE platform team are

clearer.


That's annoying ... The virtual threads are in the 21 compat. The
Panama for Java 22 and building releases with 22+ should not require
any additional changes.


I'm going to be looking at switching Java 17 locally as I have an EL TCK
issue I need to investigate that only happens on Java 17. I can push
that branch to GitHub if there is interest. However, I am a long way
from being ready to support that change for 11.0.x.

I ma trying to think about this in terms of what would be best for our
user community.

Working to a minimum of Java 17 would make Tomcat 11 an option for those
using willing to move to Java 17 but unwilling to move to Java 21. What
I am not sure about is how big a proportion of our community that is. If
I had to guess, I'd say very small.

Working to a minimum of Java 21 would mean users could be sure that
anything claiming Jakarta 11 compliance would work with Tomcat - whether
it required Java 17 or Java 21 as a minimum.

Given the above, I'm leaning towards sticking with Java 21 as the
minimum unless there is user demand for Java 17. I'll note that we can
always reduce the minimum version at any point in the future - even
between stable point releases.

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






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

Re: 10.1.19: sporadic NullPointerException in org.apache.tomcat.websocket.TestWsSessionSuspendResume.testSuspendThenClose()

[Mark Thomas]

On 19/02/2024 14:41, Christopher Schultz wrote:



On 2/17/24 12:21, Rainer Jung wrote:

OK, great and sorry I didn't notice the fix!

Am 17.02.24 um 17:18 schrieb Mark Thomas:

On 16/02/2024 23:50, Rainer Jung wrote:

Hi there,

I see sporadic NullPointerExceptions when running the new unit test 
in org.apache.tomcat.websocket.TestWsSessionSuspendResume:


Yep. My bad. The fix is already committed:

https://github.com/apache/tomcat/commit/d7daf694cbd773e362567a29a3b518cc1edaa9c1


Shall I cancel the release and re-tag, etc. or proceed with the release 
of 10.1.19?


It is only a bug in the test. I think it is fine to continue with the 
10.1.19 release.


Mark

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

[VOTE][RESULT] Release Apache Tomcat 11.0.0-M17

[Mark Thomas]

The following votes were cast:

Binding:
+1: remm, markt, fschumacher

Non-binding
+1: Dimitris Soumis

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark



On 13/02/2024 22:50, Mark Thomas wrote:

The proposed Apache Tomcat 11.0.0-M17 release is now available for
voting.

Apache Tomcat 11.0.0-M17 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 improvements to the CSRF prevention filter including the ability
   to skip adding nonces for resource name and subtree URL patterns.

- Add support for user provided SSLContext instances configured on
   SSLHostConfigCertificate instances. Based on pull request #673
   provided by Hakan Altındağ.

- Review usage of debug logging and downgrade trace or data dumping
   operations from debug level to trace.

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

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

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M17
110bc36637569f7e9d191d21ac8600a8667cfc94


The proposed 11.0.0-M17 release is:
[ ] -1 Broken - do not release
[ ] +1 Alpha  - go ahead and release as 11.0.0-M17

-
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: 10.1.19: sporadic NullPointerException in org.apache.tomcat.websocket.TestWsSessionSuspendResume.testSuspendThenClose()

[Mark Thomas]

On 16/02/2024 23:50, Rainer Jung wrote:

Hi there,

I see sporadic NullPointerExceptions when running the new unit test in 
org.apache.tomcat.websocket.TestWsSessionSuspendResume:


Yep. My bad. The fix is already committed:

https://github.com/apache/tomcat/commit/d7daf694cbd773e362567a29a3b518cc1edaa9c1

Mark

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

QUIC over TCP

[Mark Thomas]

Hi all,

The IETF HTTP working group has received a draft for running QUIC over 
TCP+TLS rather than UDP called QUIC on streams. There is also a draft 
for running HTTP/3 on QUIC on streams.


https://lists.w3.org/Archives/Public/ietf-http-wg/2024JanMar/0078.html

I have only skimmed these but this looks like a much more viable 
implementation route for HTTP/3 for Tomcat.


It is early days. I was imagining I would look at this over the summer 
once the work for Jakarta EE 11 was complete.


Mark

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

Multiple PRs for 'super tomcat'

[Mark Thomas]

All,

The spate of PRs (nearly) all at the same time, all with (nearly) the 
same title and all with (nearly) the same apology appear to be linked.


I don't know what is going on but I have a very hard time believing that 
they were all accidental. It looks very much like deliberate, 
coordinated activity to me.


The question is what do we do about it. Do we
- ignore it
- add a comment to the PR that we view it as abusive and that
  - any further on the PR will be reported to GitHub as abuse
  - any further behaviour of this nature from this user will reported to
GitHub as abuse
  - anyone reported to GitHub for abuse *will* be permanently banned
from contributing to all ASF repositories
- report them (and ban them) for abuse now

I suspect some training course is using Tomcat to send dummy PRs. As 
such I'm leaning to the second option as it should send a clear message 
that such use is not acceptable.


Thoughts?

Mark

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

Re: [VOTE] Release Apache Tomcat 9.0.86

[Mark Thomas]

On 14/02/2024 08:53, Rémy Maucherat wrote:


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


Tests pass on:
- MacOS Intel with Native 1.3.0 with OpenSSL 3.2.1 (homebrew)
- MacOS M1 with Native 1.3.0 with OpenSSL 3.2.1 (homebrew)
- Windows with Native 1.3.0 binaries
- Linux with Native 1.3.0 with OpenSSL 3.0.2 (Ubuntu)

The release is reproducible.

Mark

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

Re: [VOTE] Release Apache Tomcat 11.0.0-M17

[Mark Thomas]

On 13/02/2024 22:50, Mark Thomas wrote:


The proposed 11.0.0-M17 release is:
[ ] -1 Broken - do not release
[X] +1 Alpha  - go ahead and release as 11.0.0-M17


Tests pass with:
- Windows with Tomcat Native 2.0.7 binaries
- Linux with Tomcat Native 2.0.7 with OpenSSL 3.0.2 (Ubuntu)
- MacOS Intel with Tomcat Native 2.0.7 with OpenSSL 3.2.1 (homebrew)
- MacOS M1 with Tomcat Native 2.0.7 with OpenSSL 3.2.1 (homebrew)

Mark

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

[VOTE] Release Apache Tomcat 11.0.0-M17

[Mark Thomas]

The proposed Apache Tomcat 11.0.0-M17 release is now available for
voting.

Apache Tomcat 11.0.0-M17 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 improvements to the CSRF prevention filter including the ability
  to skip adding nonces for resource name and subtree URL patterns.

- Add support for user provided SSLContext instances configured on
  SSLHostConfigCertificate instances. Based on pull request #673
  provided by Hakan Altındağ.

- Review usage of debug logging and downgrade trace or data dumping
  operations from debug level to trace.

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

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

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M17
110bc36637569f7e9d191d21ac8600a8667cfc94


The proposed 11.0.0-M17 release is:
[ ] -1 Broken - do not release
[ ] +1 Alpha  - go ahead and release as 11.0.0-M17

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

Re: February release tagging

[Mark Thomas]

On 13/02/2024 19:00, Rémy Maucherat wrote:

On Tue, Feb 13, 2024 at 6:49 PM Mark Thomas  wrote:


On 13/02/2024 16:57, Mark Thomas wrote:

On 13/02/2024 14:14, Rémy Maucherat wrote:





I tested a fresh build of trunk (3.3 dev) and it seems to work fine
for me on Linux. What is the error ?


This isn't OpenSSL or Java EA version related.

There error is:

"WARNING:  is loading libcrypto in an unsafe way"

and then the JVM exits.

It is caused by this commit:
https://github.com/apache/tomcat/commit/830771823edbb79d2884eb1c6f5122e81df4df78


Need to decide what to do about this:
- fix it later
- try and fix it now
- revert the change and fix it later


I need to report it to the FFM team, because from your finding it is
now trying to load the wrong thing. OTOH, it did fix the library
loading for the CI runs (previously libssl was not found), so it's not
all on the regression side.

Given that I would prefer ignoring it in this build.


ACK.

Mark

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

Re: February release tagging

[Mark Thomas]

On 13/02/2024 16:57, Mark Thomas wrote:

On 13/02/2024 14:14, Rémy Maucherat wrote:





I tested a fresh build of trunk (3.3 dev) and it seems to work fine
for me on Linux. What is the error ?


This isn't OpenSSL or Java EA version related.

There error is:

"WARNING:  is loading libcrypto in an unsafe way"

and then the JVM exits.

It is caused by this commit:
https://github.com/apache/tomcat/commit/830771823edbb79d2884eb1c6f5122e81df4df78


Need to decide what to do about this:
- fix it later
- try and fix it now
- revert the change and fix it later


I found this GitHub issue comment

https://github.com/cl-plus-ssl/cl-plus-ssl/issues/114#issuecomment-770370592

that suggests that what is happening is Tomcat is trying to load 
"/usr/lib/libcrypto.dylib" which is a stub which is intended to trigger 
the crash.



2. I'm seeing a couple of HTTP/2 test failures on Windows.


I'm looking at these now.


These are fixed.

Mark

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

Re: February release tagging

[Mark Thomas]

On 13/02/2024 14:14, Rémy Maucherat wrote:

On Tue, Feb 13, 2024 at 2:12 PM Mark Thomas  wrote:


Hi all,

Just a quick status update.

I was hopping to have tagged 11.0.x by now but I have found a couple of
issues.

1. FFM on MacOS is broken. This might be related to me updating OpenSSL
(via homebrew) from 3.2.0 to 3.2.1


I tested a fresh build of trunk (3.3 dev) and it seems to work fine
for me on Linux. What is the error ?


This isn't OpenSSL or Java EA version related.

There error is:

"WARNING:  is loading libcrypto in an unsafe way"

and then the JVM exits.

It is caused by this commit:
https://github.com/apache/tomcat/commit/830771823edbb79d2884eb1c6f5122e81df4df78

I found this GitHub issue comment

https://github.com/cl-plus-ssl/cl-plus-ssl/issues/114#issuecomment-770370592

that suggests that what is happening is Tomcat is trying to load 
"/usr/lib/libcrypto.dylib" which is a stub which is intended to trigger 
the crash.



2. I'm seeing a couple of HTTP/2 test failures on Windows.


I'm looking at these now.

Mark

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

February release tagging

[Mark Thomas]

Hi all,

Just a quick status update.

I was hopping to have tagged 11.0.x by now but I have found a couple of 
issues.


1. FFM on MacOS is broken. This might be related to me updating OpenSSL 
(via homebrew) from 3.2.0 to 3.2.1


2. I'm seeing a couple of HTTP/2 test failures on Windows.

I'm currently investigating.

Mark

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

[ANN] Apache Tomcat Native 1.3.0 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.3.0 stable.

The key features of this release are:

- The minimum supported OpenSSL version is 1.1.1
- The minimum supported APR version in 1.6.3
- The windows binaries in this release have been built with OpenSSL
  3.0.13

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

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


The Apache Tomcat Native Library 1.3.x provides portable API for 
features not found in contemporary JDK's. It uses Apache Portable 
Runtime as operating system abstraction layer and OpenSSL for SSL 
networking and allows optimal performance in production environments.


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

[ANN] Apache Tomcat Native 2.0.7 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 2.0.7 stable.

The key features of this release are:

- Align default pass phrase prompt with httpd on Windows
- The windows binaries in this release have been built with OpenSSL
  3.0.13

The 2.0.x branch is primarily intended for use with Tomcat 10.1.x or 
later but can be used with earlier versions as long as the APR/native 
connector is not used.


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

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

The Apache Tomcat Native Library 2.0.x provides an API for using OpenSSL 
for SSL networking with Apache Tomcat.


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

[VOTE][RESULT] Release Apache Tomcat Native 1.3.0

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, schultz, remm

No other votes were cast. The vote therefore passes.

Thanks to everyone who helped with this release.

Mark

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

Re: Test stability and tagging delayed

[Mark Thomas]

On 12/02/2024 15:14, Christopher Schultz wrote:

Mark,

On 2/9/24 08:30, Mark Thomas wrote:

On 09/02/2024 12:14, Rémy Maucherat wrote:

On Fri, Feb 9, 2024 at 12:46 PM Mark Thomas  wrote:

On 08/02/2024 17:07, Mark Thomas wrote:





Back to working out a more robust fix...


While the fix worked well locally, it hasn't fixed the problem on the
Buildbot CI worker.

I'm going to take another look.


I had a look at the test output, and the issue is exclusively with the
APR connector (the tests are a bit weird so that the APR connector is
also run, basically the test is the same for all connectors), that's
why it would only affect 8.5 and 9.0. Overall it's not even certain
OpenSSL + NIO really needed a fix and the OpenSSLContext cleanup is
most likely good enough (at least in that case). Build 845 for 9.0.x
was crashing when using the APR connector, not NIO.


I am making progress. I have a slightly amended theory as to what is 
going on (and now confirmed via logging).


The clean-up of OpenSSLContext is performed by the finalizer.
In the problematic tests, the Native library is repeatedly loaded and 
unloaded within a single JVM.
The crashes happen when the finalizer attempts to clean an 
OpenSSLContext instance from a previous load of the native library 
after the native library has been reloaded.


I have a fix for this.

I intend to:
- revert (most of) the changes made to 8.5.x through 11.0.x
- apply the new fix to 9.0.x and 8.5.x only

Apologies for the noise while I tracked the root cause of this down. 
The good news is that this should address one of the causes of unit 
test instability.


Apologies for the noise while I caught up to today's messages on this 
topic. You can obviously ignore all my critiques thus far.


Since this appears mostly to be due to the unit-testing environment, 
should we simply create a system property that suppresses the shutdown 
of the native library during unit-tests and let it stay configured the 
whole time? Or do we actually need to de-configure and re-configure it 
during the unit-test run?


I think it is useful in that it has been highlighting an issue with 
APR/native that we have needed to address for a while. In production, it 
typically happens on shutdown so isn't too big an issue - hence why it 
wasn't addressed.


Mark

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

Re: Assist in build for successful build

[Mark Thomas]

On 10/02/2024 11:49, koteswara Rao Gundapaneni wrote:

Tomcat 8.5.97 build is failing with java runtime jdk 21 windows 10


That is expected. You need to use a JDK that can target Java 7.

Mark

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

Re: Test stability and tagging delayed

[Mark Thomas]

On 09/02/2024 12:14, Rémy Maucherat wrote:

On Fri, Feb 9, 2024 at 12:46 PM Mark Thomas  wrote:

On 08/02/2024 17:07, Mark Thomas wrote:





Back to working out a more robust fix...


While the fix worked well locally, it hasn't fixed the problem on the
Buildbot CI worker.

I'm going to take another look.


I had a look at the test output, and the issue is exclusively with the
APR connector (the tests are a bit weird so that the APR connector is
also run, basically the test is the same for all connectors), that's
why it would only affect 8.5 and 9.0. Overall it's not even certain
OpenSSL + NIO really needed a fix and the OpenSSLContext cleanup is
most likely good enough (at least in that case). Build 845 for 9.0.x
was crashing when using the APR connector, not NIO.


I am making progress. I have a slightly amended theory as to what is 
going on (and now confirmed via logging).


The clean-up of OpenSSLContext is performed by the finalizer.
In the problematic tests, the Native library is repeatedly loaded and 
unloaded within a single JVM.
The crashes happen when the finalizer attempts to clean an 
OpenSSLContext instance from a previous load of the native library after 
the native library has been reloaded.


I have a fix for this.

I intend to:
- revert (most of) the changes made to 8.5.x through 11.0.x
- apply the new fix to 9.0.x and 8.5.x only

Apologies for the noise while I tracked the root cause of this down. The 
good news is that this should address one of the causes of unit test 
instability.


Mark

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

Re: Test stability and tagging delayed

[Mark Thomas]

On 08/02/2024 17:07, Mark Thomas wrote:

Hi all,

TL;DR tagging likely delayed while APR/native stability issue is addressed

We have had a couple of issues with test stability in the last few days.

The issues with 11.0.x and 10.1.x were caused by the incomplete 
convenience binary for Tomcat Native 2.0.7. That should be resolved now. 
The 11.0.x tests are already green and I am expecting 10.1.x to be green 
for the next run.


9.0.x and 8.5.x are a little more interesting. The instability was 
triggered by the change to allow users to provide an SSLContext directly 
to SSLHostConfigCertificate. This changed the timing of endpoint 
destruction enough to make the intermittent APR crashes much more 
frequent - almost on every run.


The good news is that the more frequent crashes made it easier to 
investigate. My current theory is related to the cleanup of 
OpenSSLContext. In 9.0.x and 8.5.x clean-up of this object is performed 
by a finalizer. This is to support runtime replacement of the 
SSLHostContext.


What I think happens is:
- Tomcat starts shutdown
- Endpoint is destroyed
- AprLifecycleListener shuts down Native library
- finalizer runs and tries to reference native code leading to a crash

I have some initial ideas on how we might handle this better. The quick 
and dirty fix was to force GC and add a delay in 
AprLifecycleListener.terminateAPR() but that was just a hack to test the 
theory.


Back to working out a more robust fix...


While the fix worked well locally, it hasn't fixed the problem on the 
Buildbot CI worker.


I'm going to take another look.

Mark

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

Re: (tomcat) 04/04: Reduce changes of crash on Library shutdown with OpenSSL connections

[Mark Thomas]

On 09/02/2024 09:35, Rémy Maucherat wrote:

On Thu, Feb 8, 2024 at 10:11 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit e19fa66b8397194f421134debb1f71b590a1f0c0
Author: Mark Thomas 
AuthorDate: Thu Feb 8 18:54:45 2024 +

 Reduce changes of crash on Library shutdown with OpenSSL connections


Do you have a test to reproduce that sort of crash ?

I believe the FFM version is "ok" but if you have some easy procedure
to verify that it would be nice.


I could only recreate it on 9.0.x and earlier with the 
TestSSLHostConfigCompat tests.


I did wonder whether the change was necessary for 10.1.x and 11.0.x. In 
the end I opted for consistency but I'm happy to revert the 
Library.isInitialized() changes in 10.1.x onwards if that is the consensus.


Mark



Rémy


---
  .../tomcat/util/net/openssl/OpenSSLContext.java   | 19 +++
  1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java 
b/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java
index f1d7b092ec..12dc41455b 100644
--- a/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java
+++ b/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java
@@ -46,6 +46,7 @@ import javax.net.ssl.X509TrustManager;
  import org.apache.juli.logging.Log;
  import org.apache.juli.logging.LogFactory;
  import org.apache.tomcat.jni.CertificateVerifier;
+import org.apache.tomcat.jni.Library;
  import org.apache.tomcat.jni.Pool;
  import org.apache.tomcat.jni.SSL;
  import org.apache.tomcat.jni.SSLConf;
@@ -648,14 +649,16 @@ public class OpenSSLContext implements 
org.apache.tomcat.util.net.SSLContext {

  @Override
  public void run() {
-if (ctx != 0) {
-SSLContext.free(ctx);
-}
-if (cctx != 0) {
-SSLConf.free(cctx);
-}
-if (aprPool != 0) {
-Pool.destroy(aprPool);
+if (Library.isInitialized()) {
+if (ctx != 0) {
+SSLContext.free(ctx);
+}
+if (cctx != 0) {
+SSLConf.free(cctx);
+}
+if (aprPool != 0) {
+Pool.destroy(aprPool);
+}
  }
  }
  }


-
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: [VOTE] Release Apache Tomcat Native 1.3.0

[Mark Thomas]

Just a reminder that at least one more PMC vote is required for this 
VOTE to pass.


Mark


On 05/02/2024 20:43, Mark Thomas wrote:
This is the first release of the 1.3.x branch. The main differences 
compared to the 1.2.x branch are


- Minimum OpenSSL version of 1.1.1
- Minimum APR version of 1.6.3
- Minimum LibreSSL version of 3.5.2
- The windows binaries in this release have been built with OpenSSL
   3.0.13 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.0 release is
  [ ] Stable, go ahead and release
  [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.3.0
[2] 
https://github.com/apache/tomcat-native/commit/998746966815e1ae105cba9f2681d37cc30249bc


-
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

Test stability and tagging delayed

[Mark Thomas]

Hi all,

TL;DR tagging likely delayed while APR/native stability issue is addressed

We have had a couple of issues with test stability in the last few days.

The issues with 11.0.x and 10.1.x were caused by the incomplete 
convenience binary for Tomcat Native 2.0.7. That should be resolved now. 
The 11.0.x tests are already green and I am expecting 10.1.x to be green 
for the next run.


9.0.x and 8.5.x are a little more interesting. The instability was 
triggered by the change to allow users to provide an SSLContext directly 
to SSLHostConfigCertificate. This changed the timing of endpoint 
destruction enough to make the intermittent APR crashes much more 
frequent - almost on every run.


The good news is that the more frequent crashes made it easier to 
investigate. My current theory is related to the cleanup of 
OpenSSLContext. In 9.0.x and 8.5.x clean-up of this object is performed 
by a finalizer. This is to support runtime replacement of the 
SSLHostContext.


What I think happens is:
- Tomcat starts shutdown
- Endpoint is destroyed
- AprLifecycleListener shuts down Native library
- finalizer runs and tries to reference native code leading to a crash

I have some initial ideas on how we might handle this better. The quick 
and dirty fix was to force GC and add a delay in 
AprLifecycleListener.terminateAPR() but that was just a hack to test the 
theory.


Back to working out a more robust fix...

Mark


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

Re: [VOTE][RESULT] Release Apache Tomcat Native 2.0.7

[Mark Thomas]

On 08/02/2024 11:43, Mark Thomas wrote:
The source is OK but the convenience binary needs to be re-packaged. I 
think the DLL name changed which meant the correct files weren't picked up.


Since we aren't changing the source or the tag, I don't think we need a 
new release but I'll confirm that once I figure out exactly where things 
went wrong.


Confirmed. Just the binaries and it was caused by the file name change 
so the copy and pasted commands didn't pick up the dll or symbol files.


I still have the build directory I used for the release so I have 
uploaded new convenience binaries that include the dll and symbol files 
from the original release build.


Mark

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

Re: [VOTE][RESULT] Release Apache Tomcat Native 2.0.7

[Mark Thomas]

The source is OK but the convenience binary needs to be re-packaged. I 
think the DLL name changed which meant the correct files weren't picked up.


Since we aren't changing the source or the tag, I don't think we need a 
new release but I'll confirm that once I figure out exactly where things 
went wrong.


Mark


On 08/02/2024 09:23, Mark Thomas wrote:

The following votes were cast:

Binding:
+1: markt, schultz, remm

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 04/02/2024 20:42, Mark Thomas wrote:

The key differences of version 2.0.7 compared to 2.0.6 are:

- Align default pass phrase prompt with httpd on Windows
- The windows binaries in this release have been built with OpenSSL
   3.0.13 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.7 release is
  [ ] Stable, go ahead and release
  [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.7
[2] 
https://github.com/apache/tomcat-native/commit/feefd3b9cf9dc60063860c173c6d027125bac843


-
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

[VOTE][RESULT] Release Apache Tomcat Native 2.0.7

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, schultz, remm

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 04/02/2024 20:42, Mark Thomas wrote:

The key differences of version 2.0.7 compared to 2.0.6 are:

- Align default pass phrase prompt with httpd on Windows
- The windows binaries in this release have been built with OpenSSL
   3.0.13 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.7 release is
  [ ] Stable, go ahead and release
  [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.7
[2] 
https://github.com/apache/tomcat-native/commit/feefd3b9cf9dc60063860c173c6d027125bac843


-
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][RESULT] Apache Tomcat migration tool for Jakarta EE 1.0.8

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, schultz, remm

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


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

Re: Moving to Tomcat Native 1.3.x

[Mark Thomas]

On 06/02/2024 11:22, Michael Osipov wrote:

On 2024/02/04 19:54:25 Mark Thomas wrote:

Hi all,

AS you have probably noticed I am working on another round of Tomcat
Native releases.

We are overdue on switching to 1.3.x so I would like to propose the
following with this release round:

- create a new 1.3.x branch from the current 1.2.x HEAD
- update minimum OpenSSL to 1.1.1
- update minimum APR to 1.6.3
- remove code supporting OpenSSL < 1.1.1


Good, you have basically picked up 
https://bz.apache.org/bugzilla/show_bug.cgi?id=67683.

You have missed at least two spots:
* 
https://github.com/apache/tomcat-native/blob/f6e1474c6b05e9cab0ad308647a3bde533c1cbce/native/build/tcnative.m4#L41-L45
* 
https://github.com/apache/tomcat-native/blob/f6e1474c6b05e9cab0ad308647a3bde533c1cbce/native/src/jnilib.c#L77-L81


Thanks for pointing those out. There may be more. I'll fix them as we 
spot them.


I don't see either of these as reasons to halt the 1.3.0 release. If 
anyone has a different view, please comment on the vote thread.



The next 8.5.x and 9.0.x releases would then ship with Tomcat Native
1.3.0 but minimum required/recommended Tomcat Native versions would not
change.


I wouldn't bother with 8.5 and 1.3, I'd use 1.2.x until end of 8.5 and the put 
1.2.x EOL.


I'm still leaning towards switching 8.5.x to 1.3.0 but if the consensus 
is to stcik with the current 1.2.x release I'm fine with that. I'm 
mainly trying to avoid another 1.2.x release on top of all the other 
releases I am juggling at the moment.



Overall sounds like a good plan. I will do also testing here on my side.


Tx.

Mark

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

Re: [VOTE] Release Apache Tomcat Native 1.3.0

[Mark Thomas]

On 05/02/2024 20:43, Mark Thomas wrote:


The Apache Tomcat Native 1.3.0 release is
  [X] Stable, go ahead and release
  [ ] Broken because of ...


Tomcat 9.0.x tests (NIO, NIO2 and APR/native) all pass with Java 22 EA 
on Linux (OpenSSL 1.1.1w and 3.0.13) and Windows (OpenSSL 3.0.13).


Mark

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

[VOTE] Release Apache Tomcat Native 1.3.0

[Mark Thomas]

This is the first release of the 1.3.x branch. The main differences 
compared to the 1.2.x branch are


- Minimum OpenSSL version of 1.1.1
- Minimum APR version of 1.6.3
- Minimum LibreSSL version of 3.5.2
- The windows binaries in this release have been built with OpenSSL
  3.0.13 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.0 release is
 [ ] Stable, go ahead and release
 [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.3.0
[2] 
https://github.com/apache/tomcat-native/commit/998746966815e1ae105cba9f2681d37cc30249bc


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

Re: (tomcat-native) branch 1.3.x created (now de94af367)

[Mark Thomas]

On 05/02/2024 14:17, Mark Thomas wrote:

On 05/02/2024 14:12, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 1.3.x


The 1.3.x might not be perfect but it builds with OpenSSL 1.1.1w and 
3.0.13 on Linux and all 9.0.x tests then all pass with Java 22 EA.


I've obviously messed something up as the jnirelease.sh script isn't 
working yet. I want to get that working and test the Windows build 
before I tag 1.3.0.


No issue with the script. Just needed to wait for gitbox to fully sync 
with GitHub.


I've run the 9.0.x tests on Windows as well for 1.3.x with OpenSSL 
3.0.13 and all is good. I'm going to tag 1.3.0 shortly.


Mark

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

Re: (tomcat-native) 03/03: Consistent formatting. Add missing entries. Add version to title.

[Mark Thomas]

On 05/02/2024 11:52, Konstantin Kolinko wrote:

пн, 5 февр. 2024 г. в 11:45, :


This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 1.2.x
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git

commit 34a274f39b836c9d9766e1707018b3b8b61c5506
Author: Mark Thomas 
AuthorDate: Mon Feb 5 08:27:04 2024 +

 Consistent formatting. Add missing entries. Add version to title.
---
  xdocs/miscellaneous/project.xml | 51 +
  xdocs/news/project.xml  | 10 
  xdocs/project.xml   |  8 ---
  3 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/xdocs/miscellaneous/project.xml b/xdocs/miscellaneous/project.xml
index 1153ee1ea..31248d42e 100644
--- a/xdocs/miscellaneous/project.xml
+++ b/xdocs/miscellaneous/project.xml
@@ -16,41 +16,42 @@
limitations under the License.
  -->
  http://tomcat.apache.org/;>
+href="http://tomcat.apache.org/;>



Just spotting:
The three 'project.xml" files changed by this commit still use "http:"
instead of "https:" in the  tag above...

I tested, http://tomcat.apache.org/  responds with a 301 redirect to
https://tomcat.apache.org/


Fixed to use https.

Thanks for spotting this.

Mark

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

Re: Moving to Tomcat Native 1.3.x

[Mark Thomas]

On 05/02/2024 14:11, Christopher Schultz wrote:

I'm +1 to markt's suggestions for these releases, except maybe we should 
leave 8.5.x with tcnative 1.2.x. I wouldn't want to break the last few 
releases of 8.5.x for anybody.


I think the chances of breakage are low as:
- this is a fork from 1.2.x with the OpenSSL < 1.1.1 support removed
- I'm testing the result with the 9.0.x unit tests (including the
  APR/Native connector) on multiple operating systems

It is always possible that I broke something in an edge case but:
- there is plenty of time to release a fix for 1.3.x before 8.5.x
  reaches EOL
- updating to a new Tomcat Native is very simple even if an issue
  emerges after the last 8.5.x release
- 1.3.x releases are likely to continue for the lifetime of 9.0.x which
  is probably another 3 years

My current thinking is that I will switch 8.5.x to Tomcat Native 1.3.x 
as it means one less Tomcat Native release.


Mark

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

Re: (tomcat-native) branch 1.3.x created (now de94af367)

[Mark Thomas]

On 05/02/2024 14:12, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 1.3.x


The 1.3.x might not be perfect but it builds with OpenSSL 1.1.1w and 
3.0.13 on Linux and all 9.0.x tests then all pass with Java 22 EA.


I've obviously messed something up as the jnirelease.sh script isn't 
working yet. I want to get that working and test the Windows build 
before I tag 1.3.0.


Mark

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

Re: [VOTE] Release Apache Tomcat Native 2.0.7

[Mark Thomas]

On 04/02/2024 20:42, Mark Thomas wrote:


The Apache Tomcat Native 2.0.7 release is
  [X] Stable, go ahead and release
  [ ] Broken because of ...


Tests pass with 11.0.x on Linux and Windows.

Mark

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

[VOTE] Release Apache Tomcat Native 2.0.7

[Mark Thomas]

The key differences of version 2.0.7 compared to 2.0.6 are:

- Align default pass phrase prompt with httpd on Windows
- The windows binaries in this release have been built with OpenSSL
  3.0.13 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.7 release is
 [ ] Stable, go ahead and release
 [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.7
[2] 
https://github.com/apache/tomcat-native/commit/feefd3b9cf9dc60063860c173c6d027125bac843


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

Moving to Tomcat Native 1.3.x

[Mark Thomas]

Hi all,

AS you have probably noticed I am working on another round of Tomcat 
Native releases.


We are overdue on switching to 1.3.x so I would like to propose the 
following with this release round:


- create a new 1.3.x branch from the current 1.2.x HEAD
- update minimum OpenSSL to 1.1.1
- update minimum APR to 1.6.3
- remove code supporting OpenSSL < 1.1.1

The next 8.5.x and 9.0.x releases would then ship with Tomcat Native 
1.3.0 but minimum required/recommended Tomcat Native versions would not 
change.


Any objections?

Mark

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

Re: (tomcat-native) tag 2.0.7 created (now ca59e88dc)

[Mark Thomas]

On 03/02/2024 11:21, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to tag 2.0.7
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git


   at ca59e88dc (commit)
This tag includes the following new commits:

  new ca59e88dc Tag 2.0.7


TL;DR - expect a replacement for this tag soon.

The tag looks good on Linux (builds with OpenSSl 3.0.13 and all tests 
pass in 11.0.x) but the build fails on Windows. Initial indications are 
we need to add an additional include in the openssl patch. I'm testing 
that now.


Mark

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

Re: [VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.8

[Mark Thomas]

On 02/02/2024 18:42, Mark Thomas wrote:

On 02/02/2024 18:19, Christopher Schultz wrote:

Mark,

On 2/2/24 10:53, Mark Thomas wrote:

The proposed Apache Tomcat migration tool for Jakarta EE 1.0.8 is now
available for voting.

The significant changes since 1.0.7 are:

- Recognize .ear files as archives

- Include .jspf and .tagf files in the conversion process

- Update dependencies

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v1.0.8/

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

The tag is:
https://github.com/apache/tomcat-jakartaee-migration/tree/1.0.8
7c1559661980d93e84b947682c67959165abbc4a

The proposed 1.0.8 release is:

[ ] -1: Broken. Do not release because...
[ ] +1: Acceptable. Go ahead and release.


+1 for stable release

Builds from source and passes the "verify" target (aka unit tests).

Running the "shaded" version of the JAR file worked on the first try 
with an application written using Java EE APIs and associated (legacy) 
libraries. A quick smoke-test in Tomcat 10.1.18 using the migrated WAR 
file indicates that everything is working as expected.


Details:

MacOS X Ventura x86-64
Java 21
Maven 3.8.1

Running "mvn package" results in lots of stack traces being dumped to 
the console, mostly java.lang.instrument.IllegalClassFormatException 
coming from JaCoCo and some failed unit tests.


I get warnings about weak DSA signatures for the JAR signatures. The 
"signed" JAR files also say they are not signed when I check with 
"jarsigned -verify [jar]". Is that expected if I perform the build 
locally?


I don't think I've tried the build with Java 21. I'm using Java 17 for 
that at the moment. I'll try 21 and see what happens.


I see warnings about self-signed certificates for JAR signing.

I also see the JAR is reported as unsigned. That is expected. The 
migration process removes the signatures.


The Jacoco plugin needed an update. I missed that in my last round of 
updates. I'll do that now.


Mark

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

Re: [VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.8

[Mark Thomas]

On 02/02/2024 18:19, Christopher Schultz wrote:

Mark,

On 2/2/24 10:53, Mark Thomas wrote:

The proposed Apache Tomcat migration tool for Jakarta EE 1.0.8 is now
available for voting.

The significant changes since 1.0.7 are:

- Recognize .ear files as archives

- Include .jspf and .tagf files in the conversion process

- Update dependencies

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v1.0.8/

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

The tag is:
https://github.com/apache/tomcat-jakartaee-migration/tree/1.0.8
7c1559661980d93e84b947682c67959165abbc4a

The proposed 1.0.8 release is:

[ ] -1: Broken. Do not release because...
[ ] +1: Acceptable. Go ahead and release.


+1 for stable release

Builds from source and passes the "verify" target (aka unit tests).

Running the "shaded" version of the JAR file worked on the first try 
with an application written using Java EE APIs and associated (legacy) 
libraries. A quick smoke-test in Tomcat 10.1.18 using the migrated WAR 
file indicates that everything is working as expected.


Details:

MacOS X Ventura x86-64
Java 21
Maven 3.8.1

Running "mvn package" results in lots of stack traces being dumped to 
the console, mostly java.lang.instrument.IllegalClassFormatException 
coming from JaCoCo and some failed unit tests.


I get warnings about weak DSA signatures for the JAR signatures. The 
"signed" JAR files also say they are not signed when I check with 
"jarsigned -verify [jar]". Is that expected if I perform the build locally?


I don't think I've tried the build with Java 21. I'm using Java 17 for 
that at the moment. I'll try 21 and see what happens.


Mark

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

Re: [VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.8

[Mark Thomas]

On 02/02/2024 15:53, Mark Thomas wrote:


The proposed 1.0.8 release is:

[ ] -1: Broken. Do not release because...
[X] +1: Acceptable. Go ahead and release.


The tests pass during the build.

When used with Tomcat 11.0.x, the 1.0.8 shaded JAR successfully converts 
the 9.0.x examples web application. The WebSocket snake and drawing 
examples work in the migrated web application.


Mark

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

[VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.8

[Mark Thomas]

The proposed Apache Tomcat migration tool for Jakarta EE 1.0.8 is now
available for voting.

The significant changes since 1.0.7 are:

- Recognize .ear files as archives

- Include .jspf and .tagf files in the conversion process

- Update dependencies

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v1.0.8/

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

The tag is:
https://github.com/apache/tomcat-jakartaee-migration/tree/1.0.8
7c1559661980d93e84b947682c67959165abbc4a

The proposed 1.0.8 release is:

[ ] -1: Broken. Do not release because...
[ ] +1: Acceptable. Go ahead and release.

Thanks,

Mark

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

Re: February 2024 releases

[Mark Thomas]

On 01/02/2024 23:45, Christopher Schultz wrote:

All,

Friday seems like a good time to roll a release and call for a vote.

Does anyone want to fit anything in before this round of releases?


Yes. The update to the migration tool.

We might want to think about a Tomcat Native release to pick up the 
latest OpenSSL releases. We don't need to, but it will probably save 
some false positives from security scanners.


I also have some other changes locally that I want to merge.

Mark

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

Time for a migration tool release

[Mark Thomas]

Hi all,

There have been some fixes are there are currently no open issues so, 
unless there are objections, I intend to tag and start the release tomorrow.


Mark

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

Re: [bug] websocket generics?

[Mark Thomas]

On 22/01/2024 15:04, Romain Manni-Bucau wrote:

Hi Mark,

Checked deeper the sample and seems it is the old lambda issue, so indeed
we can avoid the NPE and fallback on Object but since it was not done I'm
not sure it would be helpful compared to current code.
Here is the test:

@Test
public void testLambda() {
 final MessageHandler.Whole handler = message -> {
 };
 Assert.assertEquals(Object.class, Util.getMessageType(handler));
}

So guess we can play the status-quo.


To save others doing the search:

https://bz.apache.org/bugzilla/show_bug.cgi?id=65458

+1 to leaving things as they are.


Side note: seems ide-intellij ant task got broken with java 22 API usage of
the source.


Possibly. I'm an Eclipse user so we'll need an IntelliJ user to take a 
look at that.


Mark




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 22 janv. 2024 à 12:53, Mark Thomas  a écrit :


On 21/01/2024 18:33, Romain Manni-Bucau wrote:

Hi,

I know websocket 1.0 methods without providing the handler type are kind

of

deprecated (not recommended would be more correct) so not sure this bug
would get a fix or not.
Long story
short,

org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler)

will call Util.getMessageType which goes into the reflection code and the
interesting part is org.apache.tomcat.websocket.Util#getGenericType and
more precisely TypeResult superClassTypeResult = getGenericType(type,
superClazz); which can return null (end of recursion) but next line

being int

dimension = superClassTypeResult.getDimension(); we can get a NPE.

The fix is trivial but I'mnot sure it is worth it or just redirecting to
the right API would be better.


It depends whether this is one of the cases we can actually handle
correctly or if it is one where you have to use the new API.

If we can handle it correctly, we should. If not, I'm fine with throwing
an although it looks like the error handling might need a small tweak in
that case.

Can you provide a concrete example that currently fails?

Mark

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






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

Re: [bug] websocket generics?

[Mark Thomas]

On 21/01/2024 18:33, Romain Manni-Bucau wrote:

Hi,

I know websocket 1.0 methods without providing the handler type are kind of
deprecated (not recommended would be more correct) so not sure this bug
would get a fix or not.
Long story
short, 
org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler)
will call Util.getMessageType which goes into the reflection code and the
interesting part is org.apache.tomcat.websocket.Util#getGenericType and
more precisely TypeResult superClassTypeResult = getGenericType(type,
superClazz); which can return null (end of recursion) but next line being int
dimension = superClassTypeResult.getDimension(); we can get a NPE.

The fix is trivial but I'mnot sure it is worth it or just redirecting to
the right API would be better.


It depends whether this is one of the cases we can actually handle 
correctly or if it is one where you have to use the new API.


If we can handle it correctly, we should. If not, I'm fine with throwing 
an although it looks like the error handling might need a small tweak in 
that case.


Can you provide a concrete example that currently fails?

Mark

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

Re: [SECURITY] CVE-2024-21733 Apache Tomcat - Information Disclosure

[Mark Thomas]

Correcting the CVE reference in the text (the subject line is correct)

Mark


On 19/01/2024 10:17, Mark Thomas wrote:

CVE-2023-21733 Apache Tomcat - Information Disclosure

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0-M11 to 9.0.43
Apache Tomcat 8.5.7 to 8.5.63

Description:
Incomplete POST requests triggered an error response that could contain 
data from a previous request from another user.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.44 or later
- Upgrade to Apache Tomcat 8.5.64 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by xer0dayz from Sn1perSecurity LLC.


History:
2024-01-19 Original advisory

References:
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html


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

Re: Jakarta EE 11 may be changing minimum Java version to 17

[Mark Thomas]

On 19/01/2024 14:20, Volodymyr Siedlecki wrote:

Hi Mark,

I understand your perspective about changing 21 to 17 so late.

Open Liberty uses Tomcat's Expression Language and we would prefer to
use a Java 17 binary. However, there are workarounds for us.


Ack.

I'll note that the EL code will compile quite happily with Java 17 or 
Java 21.


Can you expand on why you'd prefer Java 17? Ignoring how late in the 
process this change is being made, I've yet to hear a logically 
consistent argument for selecting Java 17 over Java 21.



As for the EL TCK issue, I'd be happy to take a look if you push up a branch.


Thanks for the offer but I have already fixed the issue.

Mark




Thank you,

Volodymyr


On Fri, Jan 19, 2024 at 6:38 AM Mark Thomas  wrote:


On 16/01/2024 11:44, Rémy Maucherat wrote:

On Tue, Jan 16, 2024 at 11:59 AM Mark Thomas  wrote:


Hi all,

I'm not sure what is going on as there has been one significant change
in the announcement already but it looks to me as if the minimum Java
version for Jakarta EE 11 is changing to Java 17 rather than Java 21.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg04371.html

It seems far too late in the day for this change to me but I'm not sure
that view is going to carry much weight.

I've taken a quick look at the Tomcat 11 code base and a JreCompat for
Java 21 shouldn't be too much work. I'm not planning on doing anything
on this until the intentions of the Jakarta EE platform team are

clearer.


That's annoying ... The virtual threads are in the 21 compat. The
Panama for Java 22 and building releases with 22+ should not require
any additional changes.


I'm going to be looking at switching Java 17 locally as I have an EL TCK
issue I need to investigate that only happens on Java 17. I can push
that branch to GitHub if there is interest. However, I am a long way
from being ready to support that change for 11.0.x.

I ma trying to think about this in terms of what would be best for our
user community.

Working to a minimum of Java 17 would make Tomcat 11 an option for those
using willing to move to Java 17 but unwilling to move to Java 21. What
I am not sure about is how big a proportion of our community that is. If
I had to guess, I'd say very small.

Working to a minimum of Java 21 would mean users could be sure that
anything claiming Jakarta 11 compliance would work with Tomcat - whether
it required Java 17 or Java 21 as a minimum.

Given the above, I'm leaning towards sticking with Java 21 as the
minimum unless there is user demand for Java 17. I'll note that we can
always reduce the minimum version at any point in the future - even
between stable point releases.

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: Jakarta EE 11 may be changing minimum Java version to 17

[Mark Thomas]

On 16/01/2024 11:44, Rémy Maucherat wrote:

On Tue, Jan 16, 2024 at 11:59 AM Mark Thomas  wrote:


Hi all,

I'm not sure what is going on as there has been one significant change
in the announcement already but it looks to me as if the minimum Java
version for Jakarta EE 11 is changing to Java 17 rather than Java 21.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg04371.html

It seems far too late in the day for this change to me but I'm not sure
that view is going to carry much weight.

I've taken a quick look at the Tomcat 11 code base and a JreCompat for
Java 21 shouldn't be too much work. I'm not planning on doing anything
on this until the intentions of the Jakarta EE platform team are clearer.


That's annoying ... The virtual threads are in the 21 compat. The
Panama for Java 22 and building releases with 22+ should not require
any additional changes.


I'm going to be looking at switching Java 17 locally as I have an EL TCK 
issue I need to investigate that only happens on Java 17. I can push 
that branch to GitHub if there is interest. However, I am a long way 
from being ready to support that change for 11.0.x.


I ma trying to think about this in terms of what would be best for our 
user community.


Working to a minimum of Java 17 would make Tomcat 11 an option for those 
using willing to move to Java 17 but unwilling to move to Java 21. What 
I am not sure about is how big a proportion of our community that is. If 
I had to guess, I'd say very small.


Working to a minimum of Java 21 would mean users could be sure that 
anything claiming Jakarta 11 compliance would work with Tomcat - whether 
it required Java 17 or Java 21 as a minimum.


Given the above, I'm leaning towards sticking with Java 21 as the 
minimum unless there is user demand for Java 17. I'll note that we can 
always reduce the minimum version at any point in the future - even 
between stable point releases.


Mark

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

Re: (tomcat) branch 10.1.x updated: Fix backport of BZ 66508 regression fix

[Mark Thomas]

On 19/01/2024 10:24, Rémy Maucherat wrote:

On Fri, Jan 19, 2024 at 11:08 AM Mark Thomas  wrote:




On 19/01/2024 09:22, Rémy Maucherat wrote:

On Thu, Jan 18, 2024 at 8:18 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/10.1.x by this push:
   new 67638c17e7 Fix backport of BZ 66508 regression fix
67638c17e7 is described below

commit 67638c17e7c19a0280ccafa340183fb179af92f5
Author: Mark Thomas 
AuthorDate: Thu Jan 18 18:52:30 2024 +

  Fix backport of BZ 66508 regression fix


I don't understand the differences introduced.
In SocketWrapperBase, the lock is not a ReentrantLock, but it still
cannot be anything else:
private final Lock lock = new ReentrantLock();

So couldn't the code be the same as in Tomcat 11 ? (with an extra
cast, but no need to check anything)


SocketWrapperBase.getLock() isn't final so it is possible for the
SocketWrapper implementation in a sub-class to override it and use a
different lock type.

I think ReentrantLock is the only realistic option here but I was aiming
to be extra careful to avoid breakage. We do have some users that
implement custom connectors so I couldn't be sure that a cast wouldn't
break in rare cases.


Oops. silly me, getLock can indeed return whatever. It would be really
odd, but it's possible.
Sorry for the noise ...


No problem. I almost went with the cast approach on the basis that 
ReentrantLock was the only realistic option. It is good to have a check 
on these sorts of things.


Thanks,

Mark

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