from:"Christopher Schultz"


Mark,

On 4/26/24 13:17, Mark Thomas wrote:

On 24/04/2024 17:52, Mark Thomas wrote:



My plan is to commit these changes to 11.0.x with the low risk parts 
(e.g. new methods) back-ported. Then, once we can see what is left, we 
can decide how quickly/slowly we want to back-port the complete fix to 
10.1.x and 9.0.x (the issue was reported against 10.1.x).


All is looking good so far.

The complete refactoring has been applied to 11.0.x

10.1.x and 9.0.x have the new header parser and are using it for the 
ChunkedInputFilter.


The question is how long do we want to wait before back-porting the 
standard HTTP header parsing? Essentially this means back-porting this 
commit:


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

Thoughts?

I'm thinking wait at least one release cycle before back-porting just in 
case of regressions given that this affects every request.


+1 for waiting until next cycle to back-port.

I don't think we have to wait any longer than that.

-chris

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

Re: Unit tests using tcnative/panama [Was: [Bug 68910] Improve LibreSSL version check in tcnative.m4]





On 4/18/24 06:05, Rainer Jung wrote:

Am 18.04.24 um 09:08 schrieb bugzi...@apache.org:

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

--- Comment #3 from Michael Osipov  ---
(In reply to Christopher Schultz from comment #1)

(In reply to Michael Osipov from comment #0)

since we also do support LibreSSL [...]


Note: Support for LibreSSL is more of an aspiration and less of a
requirement. We don't technically advertise support for LibreSSL, but I
would like to be able to support it.


FYI. Just ran 10.1.x with LibreSSL 3.5.2:
    [concat] 
TEST-org.apache.catalina.valves.rewrite.TestResolverSSL.NIO.txt
    [concat] 
TEST-org.apache.catalina.valves.rewrite.TestResolverSSL.NIO2.txt

    [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO.txt
    [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO2.txt
    [concat] 
TEST-org.apache.tomcat.util.net.TestCustomSslTrustManager.NIO.txt
    [concat] 
TEST-org.apache.tomcat.util.net.TestCustomSslTrustManager.NIO2.txt
    [concat] 
TEST-org.apache.tomcat.util.net.openssl.TestOpenSSLConf.NIO.txt
    [concat] 
TEST-org.apache.tomcat.util.net.openssl.TestOpenSSLConf.NIO2.txt


The rest is passing. These are failing for renegotiation or protocol 
mismatch.

That looks very promising.


Probably not relevant for this specific topic but maybe of general 
interest:


For other reasons I tried to identify, which unit tests actually load 
and execute with tcnative and/or panama, and those are very few. Most 
tests do not use these. Apart from the ones you mentioned as failing:


org.apache.catalina.valves.rewrite.TestResolverSSL
org.apache.tomcat.util.net.TestClientCert
org.apache.tomcat.util.net.TestCustomSslTrustManager
org.apache.tomcat.util.net.openssl.TestOpenSSLConf

the only other tests I found using tcnative and/or openssl connectors are:

org.apache.coyote.http2.TestLargeUpload
org.apache.tomcat.util.net.TestClientCertTls13
org.apache.tomcat.util.net.TestSSLHostConfigCompat
org.apache.tomcat.util.net.TestSSLHostConfigIntegration
org.apache.tomcat.util.net.TestSsl
org.apache.tomcat.websocket.TestWebSocketFrameClientSSL
org.apache.tomcat.websocket.TestWsWebSocketContainerSSL

So almost all of the tests actually using a connector to run servlets 
etc. only use plain http connectors (or fixed JSSE, but I think such do 
not exist).


A few more might only use the commandline openssl binary. Those are not 
included in the above lists.


I was thinking about this the other day as well, since there are 
tcnative+APR-based tests in Tomcat 9 which are executed separately from 
NIO and NIO2. I wasn't ever sure if/how the native library was being 
loaded. I wonder if on test-start (for those tests which actually use 
the connector), we could advertise which strategy is actually being used 
at runtime? I'm aware that FFM isn't supported pre-10.1.23 and that the 
APR connector has been removed in 10.1 but when running 10.1/11 tests it 
would be nice to know that the tests are failing because some specific 
test isn't working via e.g. FFM rather than the native library just 
didn't load properly and therefore ALL tests are failing.


-chris

-
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 disastrous cookie-logging patch.


Mark,

Thanks for back-porting this. I thought I had already done so.

-chris

On 4/26/24 12:58, ma...@apache.org 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 783815fd94 Fix disastrous cookie-logging patch.
783815fd94 is described below

commit 783815fd940a4ac2f6d7df7bd056e071f54d7de6
Author: Christopher Schultz 
AuthorDate: Fri Apr 19 10:16:36 2024 -0400

 Fix disastrous cookie-logging patch.
---
  java/org/apache/catalina/valves/AbstractAccessLogValve.java | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
index 03acb492fa..5c4e67dde6 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1515,17 +1515,19 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
  if (cookies != null) {
  for (Cookie cookie : cookies) {
  if (cookieNameToLog.equals(cookie.getName())) {
+if (value == null) {
+value = new StringBuilder();
+}
  if (first) {
  first = false;
  } else {
  value.append(',');
  }
-value = new StringBuilder();
  value.append(cookie.getValue());
  }
  }
  }
-if (value.length() == 0) {
+if (value == null) {
  buf.append('-');
  } else {
  escapeAndAppend(value.toString(), buf);


-
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: Fix disastrous cookie-logging patch.


Chuck,

On 4/19/24 10:48, Chuck Caldarale wrote:

On Apr 19, 2024, at 09:18, Christopher Schultz  
wrote:

Hopefully this patch has the intended effect. ;)



I’m not convinced this change will have any measurable performance
improvement. The JVM C2 compiler is pretty good with escape analysis,
so an unused StringBuilder object may not even get allocated.
It should get allocated, since the constructor needs to be called. But 
it may be allocated in a cheap memory region and immediately become 
speedily-collected garbage.



Also, there’s now an added comparison for each iteration of the
cookies loop, plus the additional code for an object allocation. This
enlarges the body of the loop, putting more pressure on the microcode
cache in the CPU, possibly making each iteration take longer.

That's a fair criticism.


Are there any practical examples that show a performance benefit or GC 
reduction?


None.

I made this change merely based upon code inspection. Since this code 
executes for every single request, I guessed without evidence that 
reduction of memory-churn would be beneficial.


-chris


On 4/19/24 10:17, 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 cbefe8624e Fix disastrous cookie-logging patch.
cbefe8624e is described below
commit cbefe8624ee5d6255955134d08498f9926295126
Author: Christopher Schultz 
AuthorDate: Fri Apr 19 10:16:36 2024 -0400
 Fix disastrous cookie-logging patch.
---
  java/org/apache/catalina/valves/AbstractAccessLogValve.java | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
index 0576b83442..dd29a5ec37 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1513,17 +1513,19 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
  if (cookies != null) {
  for (Cookie cookie : cookies) {
  if (cookieNameToLog.equals(cookie.getName())) {
+if (value == null) {
+value = new StringBuilder();
+}
  if (first) {
  first = false;
  } else {
  value.append(',');
  }
-value = new StringBuilder();
  value.append(cookie.getValue());
  }
  }
  }
-if (value.length() == 0) {
+if (value == null) {
  buf.append('-');
  } else {
  escapeAndAppend(value.toString(), buf);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org


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




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



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

[VOTE][RESULT] Release Apache Tomcat 10.1.23

2024-04-23 Thread Christopher Schultz


All,

The following votes were cast:

Binding:
+1: schultz, remm, markt, rjung, jfclere

Non-binding:
+1: Dimitris Soumis

There were no other votes, therefore the vote passed.

I will begin the release process shortly. Thanks to everyone who 
contributed toward this release.


-chris


The proposed Apache Tomcat 10.1.23 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build mistake and 
Apache Tomcat 10.1.22 was cancelled due to an option in startup scripts which 
would have caused Java 11 environments to fail to start.

The notable changes compared to 10.1.20 are:

- Improve locking strategies in Catalina core

- Update Basic authentication to implement the requirements of RFC 7617

- Updates to Apache Commons dependencies

- Add OpenSSL support when FFM is available

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be placed 
in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically 
convert them to Jakarta EE and copy them to the webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.23/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.23
https://github.com/apache/tomcat/commit/9062d27dc5122e8241ea62a4c4312af0dc71da49

Please reply with a +1 for release or -0/-1 with an explanation.

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



-
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

2024-04-23 Thread Christopher Schultz


Jean-Frederic,

On 4/23/24 08:27, jean-frederic clere wrote:

On 4/23/24 09:47, Mark Thomas wrote:

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.


The class files are different... Investigating.


I'm holding the VOTE-RESULT email just in case you find something truly 
weird.


-chris

-
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

2024-04-23 Thread Christopher Schultz


Jean-Frederic,

On 4/23/24 08:27, jean-frederic clere wrote:

On 4/23/24 09:47, Mark Thomas wrote:

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.


The class files are different... Investigating.


Try using "ant verify-release". It will give you suggestions for 
investigating anything that doesn't match.


-chris

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

Re: (tomcat) branch main updated: Fix disastrous cookie-logging patch.


All,

Hopefully this patch has the intended effect. ;)

-chris

On 4/19/24 10:17, 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 cbefe8624e Fix disastrous cookie-logging patch.
cbefe8624e is described below

commit cbefe8624ee5d6255955134d08498f9926295126
Author: Christopher Schultz 
AuthorDate: Fri Apr 19 10:16:36 2024 -0400

 Fix disastrous cookie-logging patch.
---
  java/org/apache/catalina/valves/AbstractAccessLogValve.java | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
index 0576b83442..dd29a5ec37 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1513,17 +1513,19 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
  if (cookies != null) {
  for (Cookie cookie : cookies) {
  if (cookieNameToLog.equals(cookie.getName())) {
+if (value == null) {
+value = new StringBuilder();
+}
  if (first) {
  first = false;
  } else {
  value.append(',');
  }
-value = new StringBuilder();
  value.append(cookie.getValue());
  }
  }
  }
-if (value.length() == 0) {
+if (value == null) {
  buf.append('-');
  } else {
  escapeAndAppend(value.toString(), buf);


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

On 4/18/24 11: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.


OMG what the heck happened to this patch? Grr. I saw this while working 
on the timestamp-style stuff and decided to separate it out into a 
separate commit and but did I get it wrong. It NPEs on /every/ path :(


Sorry for such a low-quality commit.

I'm going to try a "correct" commit on top of it and would appreciate a 
review. If it still looks like a no-go, I'll revert the whole thing.


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

ACK

Thanks,
-chris


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


Mark,

On 4/19/24 08:38, Mark Thomas wrote:
Ping. Just making sure this veto hasn't been lost in the recent flurry 
of commits.


ACK

I'll revert and re-evaluate.

Thanks,
-chris


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



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

On 4/19/24 08: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.


It was preparation for this PR:

https://github.com/apache/tomcat/pull/721

The use of two-booleans means that we could support only 4 possible 
formats where one of them didn't make any sense (i.e. microseconds=true 
&& milliseconds == true).


-chris


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

Re: Some remarks on panama libssl loading

2024-04-18 Thread Christopher Schultz


Michael,

On 4/17/24 16:46, Michael Osipov wrote:

On 2024/04/17 14:21:06 Rainer Jung wrote:

Am 17.04.24 um 15:34 schrieb Michael Osipov:

Rainer, I do not fully understand the problem here. We use libtool to solve 
exactly this problem with versioned SONAMEs. It will create symlinks to the 
SONAME.
Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless it 
is strictly needed?

E.g.:
lrwxr-xr-x  1 root  wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@ -> 
../../lib/libcrypto.so.111
lrwxr-xr-x  1 root  wheel   13 2024-03-22 10:20 /usr/lib/libssl.so@ -> 
libssl.so.111
-r--r--r--  1 root  wheel   608008 2024-03-22 10:20 /usr/lib/libssl.so.111
and so on...


Yes, I expect that! anyone is the JVM :(

The problem is, that the Java API does not care about these well thought
native traditions. You can not open libssl.so.3 using
System.loadlibrary(String name), because whatever you give it as "name"
parameter it will always try to open libname.so. It always prepends
"lib" to name and always suffixes it with plain ".so".

Yes, it might exist as the first in your list of symlinks, but on most
linux distributions this link is not installed by default, because it is
only needed when doing compilations. So it is only installed when you
install development packages for libs.


Ah, now I see your problem, but it looks like a downstream problem of your 
distro of choice, no? I wonder how you compile then custom software if .so 
isn't present and the linker cannot find it with -L? What if you install the 
devel package to have .so link?


That works, but doesn't seem to be a reasonable requirement if you just 
want to install Ubuntu and Tomcat and run a server.


-chris

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

Re: [VOTE] Release Apache Tomcat 10.1.23


Rémy,

On 4/16/24 14:34, Rémy Maucherat wrote:

On Tue, Apr 16, 2024 at 3:11 PM Christopher Schultz
 wrote:


The proposed Apache Tomcat 10.1.23 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build
mistake and Apache Tomcat 10.1.22 was cancelled due to an option in
startup scripts which would have caused Java 11 environments to fail to
start.

The notable changes compared to 10.1.20 are:

- Improve locking strategies in Catalina core

- Update Basic authentication to implement the requirements of RFC 7617

- Updates to Apache Commons dependencies

- Add OpenSSL support when FFM is available

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
without changes. Java EE applications designed for Tomcat 9 and earlier
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
will automatically convert them to Jakarta EE and copy them to the
webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.23/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.23
https://github.com/apache/tomcat/commit/9062d27dc5122e8241ea62a4c4312af0dc71da49

Please reply with a +1 for release or -0/-1 with an explanation.

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


+1
Sorry again for the trouble ...


It's no trouble.

When I was still doing Tomcat 8.5 it would have been worse. I managed to 
get things such that the final digit of both releases was the same and 
it was hard to mess them up. Burning .21 and .22 would have thrown that 
out of wack and I probably would have been doing wrong-tags or 
wrong-emails or whatever.


So don't worry about it :)

-chris

-
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


All,

On 4/16/24 09:11, Christopher Schultz wrote:

The proposed Apache Tomcat 10.1.23 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build 
mistake and Apache Tomcat 10.1.22 was cancelled due to an option in 
startup scripts which would have caused Java 11 environments to fail to 
start.


The notable changes compared to 10.1.20 are:

- Improve locking strategies in Catalina core

- Update Basic authentication to implement the requirements of RFC 7617

- Updates to Apache Commons dependencies

- Add OpenSSL support when FFM is available

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.23/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.23
https://github.com/apache/tomcat/commit/9062d27dc5122e8241ea62a4c4312af0dc71da49

Please reply with a +1 for release or -0/-1 with an explanation.

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


+1 for stable release

Unit tests pass on MacOS aarch64.

Details:

* Environment
*  Java (build):openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment Temurin-22+36 (build 22+36) OpenJDK 64-Bit Server VM 
Temurin-22+36 (build 22+36, mixed mode)
*  Java (test): openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment Temurin-22+36 (build 22+36) OpenJDK 64-Bit Server VM 
Temurin-22+36 (build 22+36, mixed mode)
*  Ant: Apache Ant(TM) version 1.10.14 compiled on August 16 
2023

*  OS:  Darwin 23.4.0 arm64
*  cc:  Apple clang version 15.0.0 (clang-1500.3.9.4)
*  make:GNU Make 3.81
*  OpenSSL: OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-10.1.23.zip
* Valid GPG signature for apache-tomcat-10.1.23.zip
* Valid SHA-512 signature for apache-tomcat-10.1.23.tar.gz
* Valid GPG signature for apache-tomcat-10.1.23.tar.gz
* Valid SHA-512 signature for apache-tomcat-10.1.23.exe
* Valid GPG signature for apache-tomcat-10.1.23.exe
* Valid SHA512 signature for apache-tomcat-10.1.23-src.zip
* Valid GPG signature for apache-tomcat-10.1.23-src.zip
* Valid SHA512 signature for apache-tomcat-10.1.23-src.tar.gz
* Valid GPG signature for apache-tomcat-10.1.23-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

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

[VOTE] Release Apache Tomcat 10.1.23


The proposed Apache Tomcat 10.1.23 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build 
mistake and Apache Tomcat 10.1.22 was cancelled due to an option in 
startup scripts which would have caused Java 11 environments to fail to 
start.


The notable changes compared to 10.1.20 are:

- Improve locking strategies in Catalina core

- Update Basic authentication to implement the requirements of RFC 7617

- Updates to Apache Commons dependencies

- Add OpenSSL support when FFM is available

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.23/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.23
https://github.com/apache/tomcat/commit/9062d27dc5122e8241ea62a4c4312af0dc71da49

Please reply with a +1 for release or -0/-1 with an explanation.

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

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

On 4/16/24 03:18, Mark Thomas wrote:

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


Meh. This doesn't seem too impactful. If any part of the credential 
needs to contain whitespace, that whitespace will be base64 encoded and 
therefore not-whitespace in the header value.



- allows embedded line breaks in the base64


Ew. -1 please


- missing padding


This seems okay to me. JWT as a very modern example of base64-encoded 
data in HTTP allows missing padding just to save 1-3 bytes even though 
the JWTs themselves are monstrous.



- illegal characters in the base64 (ignored)
- illegal characters in the base64 padding (ignored)


These these should probably no longer be ignored.


- excessive padding


Weird. I wonder if that was intentional.


- whitespace around the decoded password


Full -1 from me. Whitespace should be allowed as part of a username or 
password and trimming it is inappropriate.


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?


None here.

Do the relevant RFCs say anything about the missing padding? If Java 
allows us to accept pad-less values, I would allow that to continue.


-chris

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

[VOTE][CANCELLED] Release Apache Tomcat 10.1.22

2024-04-15 Thread Christopher Schultz


All,

I'm cancelling the vote due to an issue raised by rjung which could 
cause Java 11 environments to fail to start Tomcat due to the 
introduction of an unsupported JVM startup switch.


I'll re-roll the release with an updated script today.

Thanks,
-chris


The proposed Apache Tomcat 10.1.22 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build mistake. 
There are no source-level changes between 10.1.21 and 10.1.22.

The notable changes compared to 10.1.20 are:

- Add OpenSSL support when FFM is available

- Improve locking strategies in Catalina core

- Updates to Apache Commons dependencies

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be placed 
in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically 
convert them to Jakarta EE and copy them to the webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.22/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.22
fd9c0bb1f0a7e586daabfda625ef50827bcfddf3

Please reply with a +1 for release or -0/-1 with an explanation.

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


-
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

2024-04-15 Thread Christopher Schultz


Mark,

On 4/15/24 11:13, Mark Thomas wrote:

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.


+1

-chris

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

Re: [VOTE] Release Apache Tomcat 10.1.22

2024-04-11 Thread Christopher Schultz


Rémy,

On 4/11/24 05:18, Rémy Maucherat wrote:

On Wed, Apr 10, 2024 at 8:52 PM Christopher Schultz
 wrote:


The proposed Apache Tomcat 10.1.22 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build
mistake. There are no source-level changes between 10.1.21 and 10.1.22.

The notable changes compared to 10.1.20 are:

- Add OpenSSL support when FFM is available

- Improve locking strategies in Catalina core

- Updates to Apache Commons dependencies

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
without changes. Java EE applications designed for Tomcat 9 and earlier
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
will automatically convert them to Jakarta EE and copy them to the
webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.22/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.22
fd9c0bb1f0a7e586daabfda625ef50827bcfddf3

Please reply with a +1 for release or -0/-1 with an explanation.

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


+1 because it's good, but let's skip advertising FFM support for this
one (due to my mistake, as I had only verified FFM support earlier
using the testsuite).


Okay, when I announce the release, I'll use some other item in-place of 
the FFM highlight.


-chris

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

Re: [VOTE] Release Apache Tomcat 10.1.22


All,

On 4/10/24 2:51 PM, Christopher Schultz wrote:

The proposed Apache Tomcat 10.1.22 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build 
mistake. There are no source-level changes between 10.1.21 and 10.1.22.


The notable changes compared to 10.1.20 are:

- Add OpenSSL support when FFM is available

- Improve locking strategies in Catalina core

- Updates to Apache Commons dependencies

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.22/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.22
fd9c0bb1f0a7e586daabfda625ef50827bcfddf3

Please reply with a +1 for release or -0/-1 with an explanation.

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


+1 for stable release. Unit tests pass on both MacOS x86-64 and MacOS 
aarch64. Builds are 100% reproducible on both MacOS x86-64 and MacOS 
aarch64.


Details:

* Environment
*  Java (build):openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment Temurin-22+36 (build 22+36) OpenJDK 64-Bit Server VM 
Temurin-22+36 (build 22+36, mixed mode)
*  Java (test): openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment Temurin-22+36 (build 22+36) OpenJDK 64-Bit Server VM 
Temurin-22+36 (build 22+36, mixed mode)

*  OS:  Darwin 21.6.0 x86_64
*  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 
Jan 2024)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-10.1.22.zip
* Valid GPG signature for apache-tomcat-10.1.22.zip
* Valid SHA-512 signature for apache-tomcat-10.1.22.tar.gz
* Valid GPG signature for apache-tomcat-10.1.22.tar.gz
* Valid SHA-512 signature for apache-tomcat-10.1.22.exe
* Valid GPG signature for apache-tomcat-10.1.22.exe
* Valid SHA512 signature for apache-tomcat-10.1.22-src.zip
* Valid GPG signature for apache-tomcat-10.1.22-src.zip
* Valid SHA512 signature for apache-tomcat-10.1.22-src.tar.gz
* Valid GPG signature for apache-tomcat-10.1.22-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

* Environment
*  Java (build):openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment Temurin-22+36 (build 22+36) OpenJDK 64-Bit Server VM 
Temurin-22+36 (build 22+36, mixed mode)
*  Java (test): openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment Temurin-22+36 (build 22+36) OpenJDK 64-Bit Server VM 
Temurin-22+36 (build 22+36, mixed mode)
*  Ant: Apache Ant(TM) version 1.10.14 compiled on August 16 
2023

*  OS:  Darwin 23.3.0 arm64
*  cc:  Apple clang version 15.0.0 (clang-1500.1.0.2.5)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-10.1.22.zip
* Valid GPG signature for apache-tomcat-10.1.22.zip
* Valid SHA-512 signature for apache-tomcat-10.1.22.tar.gz
* Valid GPG signature for apache-tomcat-10.1.22.tar.gz
* Valid SHA-512 signature for apache-tomcat-10.1.22.exe
* Valid GPG signature for apache-tomcat-10.1.22.exe
* Valid SHA512 signature for apache-tomcat-10.1.22-src.zip
* Valid GPG signature for apache-tomcat-10.1.22-src.zip
* Valid SHA512 signature for apache-tomcat-10.1.22-src.tar.gz
* Valid GPG signature for apache-tomcat-10.1.22-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

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

[VOTE] Release Apache Tomcat 10.1.22


The proposed Apache Tomcat 10.1.22 release is now available for
voting. Apache Tomcat 10.1.21 was canceled due to a release-build 
mistake. There are no source-level changes between 10.1.21 and 10.1.22.


The notable changes compared to 10.1.20 are:

- Add OpenSSL support when FFM is available

- Improve locking strategies in Catalina core

- Updates to Apache Commons dependencies

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.22/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.22
fd9c0bb1f0a7e586daabfda625ef50827bcfddf3

Please reply with a +1 for release or -0/-1 with an explanation.

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

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

Re: [VOTE][CANCELLED] Release Apache Tomcat 10.1.21

I am cancelling this release because it was built with the wrong JDK 
version.


I will re-build the release shortly as 10.1.22.

-chris

On 4/9/24 15:42, Christopher Schultz wrote:

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

The notable changes compared to 10.1.21 are:

- Add OpenSSL support when FFM is available

- Improve locking strategies in Catalina core

- Updates to Apache Commons dependencies

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.21/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.21
9a207bc5e71b8bf0ecdcdc4cd99018186b8b0f39

Please reply with a +1 for release or -0/-1 with an explanation.

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


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


Rémy,

Thanks for RMing.

On 4/9/24 09:54, Rémy Maucherat wrote:

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

The notable changes compared to 9.0.87 are:

- Cookies header generation enhancements.

- Fix regression when reloading TLS configuration and files.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.88/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1489
The tag is:
https://github.com/apache/tomcat/tree/9.0.88
e644d98329aca2ccf7f2014c0670c5fabc7fcb16

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


+1 for stable release.

Unit tests pass on MacOS aarm64 for NIO, NIO2, and APR. Build is 
reproducible on MacOS aarm64 except for the "fulldocs" bundle likely due 
to a JDK bug.


Details:
* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Ant: Apache Ant(TM) version 1.10.14 compiled on August 16 
2023

*  OS:  Darwin 23.3.0 arm64
*  cc:  Apple clang version 15.0.0 (clang-1500.1.0.2.5)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-9.0.88.zip
* Valid GPG signature for apache-tomcat-9.0.88.zip
* Valid SHA-512 signature for apache-tomcat-9.0.88.tar.gz
* Valid GPG signature for apache-tomcat-9.0.88.tar.gz
* Valid SHA-512 signature for apache-tomcat-9.0.88.exe
* Valid GPG signature for apache-tomcat-9.0.88.exe
* Valid SHA512 signature for apache-tomcat-9.0.88-src.zip
* Valid GPG signature for apache-tomcat-9.0.88-src.zip
* Valid SHA512 signature for apache-tomcat-9.0.88-src.tar.gz
* Valid GPG signature for apache-tomcat-9.0.88-src.tar.gz
*
* Binary Zip and tarball: !! NOT SAME
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

-chris

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


Rémy,

On 4/10/24 5:18 AM, Rémy Maucherat wrote:

On Tue, Apr 9, 2024 at 9:42 PM Christopher Schultz
 wrote:


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

The notable changes compared to 10.1.21 are:

- Add OpenSSL support when FFM is available


This was built with Java 17 so there's no FFM. I'm ok with that though.

If this was a mistake and we want to make sure to avoid it in the
future, I can flip the script to fail when trying to use ant release
on older Java versions. I noted that it would be flipped when Java 22
has better availability, which is supposed to be "ok" now. Temurin has
builds for everything, it looks good.


I honestly wasn't thinking about it.

So if the release is built with 17 even downstream can't use FFM. Not great.

What does everybody think? Should we bump Tomcat 10.x up to Java 22+ 
required for release-build? Java 22 is finally GA, so this seems 
reasonable. I wouldn't have wanted to do it a few weeks ago with a 
pre-release Java 22.


I'm leaning toward re-rolling 10.1.21 with Java 22. I could also burn 
the version number though nothing will have changed.


Preferences?

-chris


- Improve locking strategies in Catalina core

- Updates to Apache Commons dependencies

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
without changes. Java EE applications designed for Tomcat 9 and earlier
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
will automatically convert them to Jakarta EE and copy them to the
webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.21/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.21
9a207bc5e71b8bf0ecdcdc4cd99018186b8b0f39

Please reply with a +1 for release or -0/-1 with an explanation.

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


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

[VOTE] Release Apache Tomcat 10.1.21

2024-04-09 Thread Christopher Schultz


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

The notable changes compared to 10.1.21 are:

- Add OpenSSL support when FFM is available

- Improve locking strategies in Catalina core

- Updates to Apache Commons dependencies

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.21/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.21
9a207bc5e71b8bf0ecdcdc4cd99018186b8b0f39

Please reply with a +1 for release or -0/-1 with an explanation.

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

-
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

2024-04-04 Thread 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+


?

-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 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, false, true);
-}
-
  /**
   * 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.
@@ -324,97 +260,6 @@ public class Base64 extends BaseNCodec {
  return StringUtils.newStringUsAscii(encodeBase64(binaryData, false, 
true));
  }
  
-/**

- * Encodes to a byte64-encoded integer according to crypto standards

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

2024-03-29 Thread Christopher Schultz


Romain,

On 3/29/24 08:50, Romain Manni-Bucau wrote:

Le ven. 29 mars 2024 à 13:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Romain,

On 3/29/24 03:18, Romain Manni-Bucau wrote:

Side note: what I meant about ASF is that there was a help habit between
communities. I know it got "broken" (=it is no more a general real thing)
some years ago to isolate all projects (give them a total independency)

but

I'm clearly not a fan of that, in particular when it deserves the project
but I totally respect your choice, didnt mean anything stronger than a

hope.

No problem. Adding the smile made it clear you were hoping about me
specifically. But it wasn't clear what you were saying about the
(Tomcat) project itself.


On the method addition/ TCK: no issue since signature of the api stays

the

same.
Can break tomcat facade object design - but not a big deal for me - but
clearly not tck compat.


Okay, I'm not super familiar with the TCK process itself. I had assumed
that if we added arbitrary methods to the jakarta.* public interfaces,
we'd fail the TCK.



This is true but the proposal is more to comply to servlet5 U servlet 6
(union) API in tomcat objects.
If ServletRequestImpl (RequestFacade mainly) has the union of methods then
it can run with api 5 or 6 and still repect the compliance of both in the
same codebase.

Indeed I'm only proposing it cause the diff is very low IMHO otherwise I
agree it would be a nightmare.




If that's not the case, then...

If you build a patch set for Tomcat 10.1.x to re-add those methods and
it passes your TCK, we can apply them to 10.1 nd see if we also pass the
TCK.

If it passes both, I have no objection to adding those methods back to
10.1 to help-out anyone who feels strongly about supporting Servlet 5.
You may find that others on the team are -1 on this; I'm not sure.

Back to practical things: if you maintain a patch set (which should be
fairly limited, as I asserted and you seem to agree with) that you can
apply in order to pass the TCK and that's neaarly all its for, then I
think it won't be much maintenance for you to keep that set.

That is, if you either directly-fork Tomcat 10.1 or if your build
process downloads the sources, patches and builds Tomcat locally, then
you will pass the TCK and everyone is happy.



The fork part is the unhappy part, not because of the work but because:

* It breaks security scans
* It breaks change tracking and needs adjustments (for tomcat you try to
limit the diff between branches but as soon the branch is outside the
project it will be more complicated and a change can break the downstream
project more easily)
* It requires yet another release cycle outside of the official project
* It confuses end users
* It makes it impossible for users to upgrade Tomcat without a release of
the fork - what is possible in embedded TomEE or other projects

This is why I was looking for another compromise.


Could another compromise be "TomEE ignores Servlet 5 and just goes 
directly to Servlet 6"? That seems to be what Rémy is recommending 
because he obviously has no affection for Servlet 5 :)


-chris

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

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

2024-03-29 Thread Christopher Schultz


Romain,

On 3/29/24 03:18, Romain Manni-Bucau wrote:

Side note: what I meant about ASF is that there was a help habit between
communities. I know it got "broken" (=it is no more a general real thing)
some years ago to isolate all projects (give them a total independency) but
I'm clearly not a fan of that, in particular when it deserves the project
but I totally respect your choice, didnt mean anything stronger than a hope.


No problem. Adding the smile made it clear you were hoping about me 
specifically. But it wasn't clear what you were saying about the 
(Tomcat) project itself.



On the method addition/ TCK: no issue since signature of the api stays the
same.
Can break tomcat facade object design - but not a big deal for me - but
clearly not tck compat.


Okay, I'm not super familiar with the TCK process itself. I had assumed 
that if we added arbitrary methods to the jakarta.* public interfaces, 
we'd fail the TCK.


If that's not the case, then...

If you build a patch set for Tomcat 10.1.x to re-add those methods and 
it passes your TCK, we can apply them to 10.1 nd see if we also pass the 
TCK.


If it passes both, I have no objection to adding those methods back to 
10.1 to help-out anyone who feels strongly about supporting Servlet 5. 
You may find that others on the team are -1 on this; I'm not sure.


Back to practical things: if you maintain a patch set (which should be 
fairly limited, as I asserted and you seem to agree with) that you can 
apply in order to pass the TCK and that's neaarly all its for, then I 
think it won't be much maintenance for you to keep that set.


That is, if you either directly-fork Tomcat 10.1 or if your build 
process downloads the sources, patches and builds Tomcat locally, then 
you will pass the TCK and everyone is happy.


If your build process is strictly "download Tomcat binaries and use 
them" then of course it will be more complicated.


-chris


Le jeu. 28 mars 2024 à 23:13, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Romain,

On 3/27/24 15:29, Romain Manni-Bucau wrote:

FYI here is the diff between servlet 5 and 6 API jars:

New API: - jakarta.servlet.ServletConnection Deleted API: -
jakarta.servlet.SingleThreadModel -

jakarta.servlet.http.HttpSessionContext

- jakarta.servlet.http.HttpUtils Changed API:
jakarta.servlet.ServletContext Deleted methods: - public abstract
jakarta.servlet.Servlet
jakarta.servlet.ServletContext.getServlet(java.lang.String) throws
jakarta.servlet.ServletException - public abstract java.util.Enumeration
jakarta.servlet.ServletContext.getServletNames() - public abstract
java.util.Enumeration jakarta.servlet.ServletContext.getServlets() -

public

abstract void
jakarta.servlet.ServletContext.log(java.lang.Exception,java.lang.String)
jakarta.servlet.ServletRequest Added methods: - public abstract
jakarta.servlet.ServletConnection
jakarta.servlet.ServletRequest.getServletConnection() - public abstract
java.lang.String jakarta.servlet.ServletRequest.getProtocolRequestId() -
public abstract java.lang.String
jakarta.servlet.ServletRequest.getRequestId() Deleted methods: - public
abstract java.lang.String
jakarta.servlet.ServletRequest.getRealPath(java.lang.String)
jakarta.servlet.ServletRequestWrapper Added methods: - public
jakarta.servlet.ServletConnection
jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
java.lang.String
jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
Deleted methods: - public java.lang.String
jakarta.servlet.ServletRequestWrapper.getRealPath(java.lang.String)
jakarta.servlet.SessionCookieConfig Added methods: - public abstract
java.lang.String
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String) -

public

abstract java.util.Map

jakarta.servlet.SessionCookieConfig.getAttributes()

- public abstract void


jakarta.servlet.SessionCookieConfig.setAttribute(java.lang.String,java.lang.String)

jakarta.servlet.UnavailableException Deleted methods: - public
jakarta.servlet.Servlet jakarta.servlet.UnavailableException.getServlet()
jakarta.servlet.descriptor.JspPropertyGroupDescriptor Added methods: -
public abstract java.lang.String


jakarta.servlet.descriptor.JspPropertyGroupDescriptor.getErrorOnELNotFound()

jakarta.servlet.http.Cookie Added methods: - public boolean
jakarta.servlet.http.Cookie.equals(java.lang.Object) - public int
jakarta.servlet.http.Cookie.hashCode() - public java.lang.String
jakarta.servlet.http.Cookie.getAttribute(java.lang.String) - public
java.lang.String jakarta.servlet.http.Cookie.toString() - public
java.util.Map jakarta.servlet.http.Cookie.getAttributes() - public void


jakarta.servlet.http.Cookie.setAttribute(java.lang.String,java.lang.String)

jakarta.servlet.http.HttpServlet Added fields: - public static final
java.lang.String jakarta.servlet.http.HttpServlet.LEGACY_DO_HEAD Added
methods: - public void
jakarta.ser

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

2024-03-28 Thread Christopher Schultz


Romain,

On 3/27/24 15:29, Romain Manni-Bucau wrote:

FYI here is the diff between servlet 5 and 6 API jars:

New API: - jakarta.servlet.ServletConnection Deleted API: -
jakarta.servlet.SingleThreadModel - jakarta.servlet.http.HttpSessionContext
- jakarta.servlet.http.HttpUtils Changed API:
jakarta.servlet.ServletContext Deleted methods: - public abstract
jakarta.servlet.Servlet
jakarta.servlet.ServletContext.getServlet(java.lang.String) throws
jakarta.servlet.ServletException - public abstract java.util.Enumeration
jakarta.servlet.ServletContext.getServletNames() - public abstract
java.util.Enumeration jakarta.servlet.ServletContext.getServlets() - public
abstract void
jakarta.servlet.ServletContext.log(java.lang.Exception,java.lang.String)
jakarta.servlet.ServletRequest Added methods: - public abstract
jakarta.servlet.ServletConnection
jakarta.servlet.ServletRequest.getServletConnection() - public abstract
java.lang.String jakarta.servlet.ServletRequest.getProtocolRequestId() -
public abstract java.lang.String
jakarta.servlet.ServletRequest.getRequestId() Deleted methods: - public
abstract java.lang.String
jakarta.servlet.ServletRequest.getRealPath(java.lang.String)
jakarta.servlet.ServletRequestWrapper Added methods: - public
jakarta.servlet.ServletConnection
jakarta.servlet.ServletRequestWrapper.getServletConnection() - public
java.lang.String
jakarta.servlet.ServletRequestWrapper.getProtocolRequestId() - public
java.lang.String jakarta.servlet.ServletRequestWrapper.getRequestId()
Deleted methods: - public java.lang.String
jakarta.servlet.ServletRequestWrapper.getRealPath(java.lang.String)
jakarta.servlet.SessionCookieConfig Added methods: - public abstract
java.lang.String
jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String) - public
abstract java.util.Map jakarta.servlet.SessionCookieConfig.getAttributes()
- public abstract void
jakarta.servlet.SessionCookieConfig.setAttribute(java.lang.String,java.lang.String)
jakarta.servlet.UnavailableException Deleted methods: - public
jakarta.servlet.Servlet jakarta.servlet.UnavailableException.getServlet()
jakarta.servlet.descriptor.JspPropertyGroupDescriptor Added methods: -
public abstract java.lang.String
jakarta.servlet.descriptor.JspPropertyGroupDescriptor.getErrorOnELNotFound()
jakarta.servlet.http.Cookie Added methods: - public boolean
jakarta.servlet.http.Cookie.equals(java.lang.Object) - public int
jakarta.servlet.http.Cookie.hashCode() - public java.lang.String
jakarta.servlet.http.Cookie.getAttribute(java.lang.String) - public
java.lang.String jakarta.servlet.http.Cookie.toString() - public
java.util.Map jakarta.servlet.http.Cookie.getAttributes() - public void
jakarta.servlet.http.Cookie.setAttribute(java.lang.String,java.lang.String)
jakarta.servlet.http.HttpServlet Added fields: - public static final
java.lang.String jakarta.servlet.http.HttpServlet.LEGACY_DO_HEAD Added
methods: - public void
jakarta.servlet.http.HttpServlet.init(jakarta.servlet.ServletConfig) throws
jakarta.servlet.ServletException jakarta.servlet.http.HttpServletRequest
Deleted methods: - public abstract boolean
jakarta.servlet.http.HttpServletRequest.isRequestedSessionIdFromUrl()
jakarta.servlet.http.HttpServletRequestWrapper Deleted methods: - public
boolean
jakarta.servlet.http.HttpServletRequestWrapper.isRequestedSessionIdFromUrl()
jakarta.servlet.http.HttpServletResponse Deleted methods: - public abstract
java.lang.String
jakarta.servlet.http.HttpServletResponse.encodeRedirectUrl(java.lang.String)
- public abstract java.lang.String
jakarta.servlet.http.HttpServletResponse.encodeUrl(java.lang.String) -
public abstract void
jakarta.servlet.http.HttpServletResponse.setStatus(int,java.lang.String)
jakarta.servlet.http.HttpServletResponseWrapper Deleted methods: - public
java.lang.String
jakarta.servlet.http.HttpServletResponseWrapper.encodeRedirectUrl(java.lang.String)
- public java.lang.String
jakarta.servlet.http.HttpServletResponseWrapper.encodeUrl(java.lang.String)
- public void
jakarta.servlet.http.HttpServletResponseWrapper.setStatus(int,java.lang.String)
jakarta.servlet.http.HttpSession Deleted methods: - public abstract
jakarta.servlet.http.HttpSessionContext
jakarta.servlet.http.HttpSession.getSessionContext() - public abstract
java.lang.Object
jakarta.servlet.http.HttpSession.getValue(java.lang.String) - public
abstract java.lang.String[]
jakarta.servlet.http.HttpSession.getValueNames() - public abstract void
jakarta.servlet.http.HttpSession.putValue(java.lang.String,java.lang.Object)
- public abstract void
jakarta.servlet.http.HttpSession.removeValue(java.lang.String)

It does not look crazy to get back (without @Override) deleted methods in
Tomcat - most of them are just either "return null" or a delegation to
another method so cost for tomcat is almost 0 for that side.
What I'm not yet sure - didn't have time to check yet - is if the new API
are used directly from jakarta package (if so it would fail running with
servlet 5 api else it will run

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

2024-03-28 Thread Christopher Schultz


Romain,

On 3/27/24 08:26, Romain Manni-Bucau wrote:

Hi Chris,

Le mer. 27 mars 2024 à 13:13, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Romain,

On 3/27/24 06:13, Romain Manni-Bucau wrote:

Le mer. 27 mars 2024 à 10:58, Rémy Maucherat  a écrit :


On Wed, Mar 27, 2024 at 9:49 AM Romain Manni-Bucau
 wrote:


Hi all,

Checkout out TomEE's notifications I realized Tomcat is in a weirdish
situation where Tomcat 9 is Servlet 4 and "+1" version is Tomcat 10.1

which

is Servlet 6.
It means Tomcat is no more a Servlet 5 friendly option.

I wonder if it means Tomcat < 10.1 should be stopped too or if Tomcat

10.0

should be maintained and released again - pretty sure we can find help

if

desired for that not that far.
Another option is to restore the deleted methods between servlet 5-6 in

the

code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?


Nothing. The Tomcat developers (= the committers) determined that the
EE 9 release was useless since the only change is the javax -> jakarta
package renaming. A big task for sure, but that seemed to us this was
more a developer oriented armaggeddon and not something that benefits
our users.

For reasons that elude my understanding, some other projects like
TomEE thought this was still useful and decided to release full
support for EE 9 rather than go to EE 10 like we did. Our plan about
EE was public. So I guess this is still our problem obviously, but I
don't feel like doing anything about it.



  From what I saw on other AsfEE projects, users requested it, nothing

more

and then you have CVE game.




BTW, about the last item. Recently, I tried to run CXF on the new EE
10 APIs (since OWB moved to that). It doesn't work as it uses
deprecated APIs, while IMO it should have moved away from them long
ago. And it's an ASF project, not some hack project somewhere.



This is fixed AFAIK on master (maybe last release, didnt check) so should
be fine soon.



Basically unless there's a cut somewhere, nothing will ever change :D
As a result, I don't think an API restoration in Tomcat 10.1 is a good
idea ...



Ok, so last option is TomEE community taking the lead on 10.0 branch, is
that an option if all the PR work is done?


Is the problem that you have customers actually using these APIs?

https://tomcat.apache.org/tomcat-10.0-doc/servletapi/deprecated-list.html

Or is the problem that you can't pass a TCK unless you have support for
these ancient methods?



A bit both, have to admit I lost a bit track of original user request and
if they adopted it or not but TCK point is important and justifies today a
complete tomcat fork which is quite not understandable for me from an ASF
standpoint.


It sounds like you are saying "we over at TomEE need something and 
because we are both ASF projects, Tomcat really ought to do this work 
for us". That doesn't sound very nice to me.


You asked us, and we told you we don't care to scratch that particular 
itch. *shrug*



Most of that stuff was deprecated ages ago and just finally removed.

Why is it super important for you to get certified for Servlet 5
specifically? Why not just get Jakarta EE 10 certified and move on? Any
applications that would actually fail on Tomcat 10.1 + Migration Tool
really really _really_ need to be updated to work properly. People have
had 15 years to stop using that stuff.



This is the plan, but for the same reason you don't want to release 10.0,
certification is not a one week fork, tomee 10m1 is planned but in the
meantime having tomee 9 (servlet 5) certified would be very welcomed.
That said should I read it as you are proposing yourself to help? (trying
;)).


Yeah... no.

I was just suggesting that maybe the patch set isn't really that big. 
And that you shouldn't bother yourself with 10.0 because nobody should 
use it. It's probably riddled with unfixed CVEs that actually-supported 
versions of Tomcat have fixed and released.



Honestly, I think it would be much more worth you while to fork Tomcat
10.1 and add-back the methods you need rather than trying to resurrect
the 10.0 branch. There have been no commits on that branch for 2 years,
and we've had something like ~24 releases of each other branch in the
meantime. That includes performance improvements, security fixes,
feature and stability improvements, etc.

Would it be as simple as providing your own replacements for deprecated
classes/methods to pass the TCK? That seems far less onerous than
bringing back zombie Tomcat 10.0.


Asked this morning the same question but it is still being investigated if
possible but still means forking at some point so gain is not really huge
for the project - can be for end users, agree.


You don't really need to fork. You just need a patch-set which is 
hopefully small. I suppose you could maintain a fork, but I don't think 
it would be that onerous.


I would like to see what you

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

2024-03-27 Thread Christopher Schultz


Romain,

On 3/27/24 06:13, Romain Manni-Bucau wrote:

Le mer. 27 mars 2024 à 10:58, Rémy Maucherat  a écrit :


On Wed, Mar 27, 2024 at 9:49 AM Romain Manni-Bucau
 wrote:


Hi all,

Checkout out TomEE's notifications I realized Tomcat is in a weirdish
situation where Tomcat 9 is Servlet 4 and "+1" version is Tomcat 10.1

which

is Servlet 6.
It means Tomcat is no more a Servlet 5 friendly option.

I wonder if it means Tomcat < 10.1 should be stopped too or if Tomcat

10.0

should be maintained and released again - pretty sure we can find help if
desired for that not that far.
Another option is to restore the deleted methods between servlet 5-6 in

the

code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?


Nothing. The Tomcat developers (= the committers) determined that the
EE 9 release was useless since the only change is the javax -> jakarta
package renaming. A big task for sure, but that seemed to us this was
more a developer oriented armaggeddon and not something that benefits
our users.

For reasons that elude my understanding, some other projects like
TomEE thought this was still useful and decided to release full
support for EE 9 rather than go to EE 10 like we did. Our plan about
EE was public. So I guess this is still our problem obviously, but I
don't feel like doing anything about it.



 From what I saw on other AsfEE projects, users requested it, nothing more
and then you have CVE game.




BTW, about the last item. Recently, I tried to run CXF on the new EE
10 APIs (since OWB moved to that). It doesn't work as it uses
deprecated APIs, while IMO it should have moved away from them long
ago. And it's an ASF project, not some hack project somewhere.



This is fixed AFAIK on master (maybe last release, didnt check) so should
be fine soon.



Basically unless there's a cut somewhere, nothing will ever change :D
As a result, I don't think an API restoration in Tomcat 10.1 is a good
idea ...



Ok, so last option is TomEE community taking the lead on 10.0 branch, is
that an option if all the PR work is done?


Is the problem that you have customers actually using these APIs?

https://tomcat.apache.org/tomcat-10.0-doc/servletapi/deprecated-list.html

Or is the problem that you can't pass a TCK unless you have support for 
these ancient methods?


Most of that stuff was deprecated ages ago and just finally removed.

Why is it super important for you to get certified for Servlet 5 
specifically? Why not just get Jakarta EE 10 certified and move on? Any 
applications that would actually fail on Tomcat 10.1 + Migration Tool 
really really _really_ need to be updated to work properly. People have 
had 15 years to stop using that stuff.


Honestly, I think it would be much more worth you while to fork Tomcat 
10.1 and add-back the methods you need rather than trying to resurrect 
the 10.0 branch. There have been no commits on that branch for 2 years, 
and we've had something like ~24 releases of each other branch in the 
meantime. That includes performance improvements, security fixes, 
feature and stability improvements, etc.


Would it be as simple as providing your own replacements for deprecated 
classes/methods to pass the TCK? That seems far less onerous than 
bringing back zombie Tomcat 10.0.


-chris

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

[ANN] Apache Tomcat 10.1.20 Available


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

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

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the /webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


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


 - Fix regression when reloading TLS configuration and files.

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

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

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

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

Migration guides from Apache Tomcat 8.5.x and 9.0.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

[ANN] Apache Tomcat 8.5.100 Available


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

*This will likely be the final release of Apache Tomcat 8.5. Please see 
the EOL notice linked at the end of this message.*


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

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

 - Fix regression when reloading TLS configuration and files.

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

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

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

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

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

Please note that Tomcat 8.5.x will reach End-of-life (EOL) on 31 March 
2024. For more information please visit 
https://tomcat.apache.org/tomcat-85-eol.html


Enjoy!

- The Apache Tomcat team

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

[VOTE][RESULT] Release Apache Tomcat 10.1.20


All,

Apologies for the delay on closing the vote for this release.

The following votes were cast:

+1: schultz, remm, isapir, markt

Non-binding:

+1: Romain Mannu-Bucau, Dimitris Soumis

There were no other votes, therefore the vote passes.

I will begin the release process shortly.

-chris


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

The notable changes compared to 10.1.19 are:

- Fix regression when reloading TLS configuration and files.

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

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

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be placed 
in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically 
convert them to Jakarta EE and copy them to the webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.20/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.20
ab4d890c6fa7be3f910370f00fb5c7f10152e21c

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



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

[VOTE][RESULT] Release Apache Tomcat 8.5.100


All,

Apologies for the delay on closing the vote for this release.

The following votes were cast:

+1: schultz, remm, isapir, markt

Non-binding:

+1: Dimitris Soumis

There were no other votes, therefore the vote passes.

I will begin the release process shortly.

-chris


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

The notable changes compared to 8.5.99 are:

- Fix regression when reloading TLS configuration and files.

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

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.100/

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.100/
eddcf278ad919382608ada1898b2c5b63675c6d5

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


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

Re: (tomcat) branch main updated: Use server's ClassLoader instead of application's when loading XMLInputFactory.


Rémy,

On 3/25/24 10:21, Rémy Maucherat wrote:

On Mon, Mar 25, 2024 at 2:32 PM Christopher Schultz
 wrote:


Rémy,

On 3/22/24 11:39, Rémy Maucherat wrote:

On Fri, Mar 22, 2024 at 2:40 PM  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 988992ba2e Use server's ClassLoader instead of application's when 
loading XMLInputFactory.
988992ba2e is described below

commit 988992ba2e9a8e2c3db47ac960c2fa6c3fc7a8a4
Author: Christopher Schultz 
AuthorDate: Fri Mar 22 09:37:08 2024 -0400

  Use server's ClassLoader instead of application's when loading 
XMLInputFactory.


It doesn't work because there's nothing corresponding to the
XMLInputFactory.class.getName() id. The default newFactory doesn't do
the same thing at all.


Ugh, sorry about that. Thanks for fixing it.

Setting the ContextClassLoader seems like the wrong approach. Isn't
there a ClassLoader parameter to getFactory for a reason?


Feel free to revert it if you don't like it.


Well, using the "obvious" solution didn't work, so ...

I didn't realize that the JRE classes would use 
Thread.currentClassLoader for anything. Does this actually achieve the 
goal of preventing an XMLInputFactory leak? I should probably ask the 
reporter...


-chris


   java/org/apache/jasper/compiler/EncodingDetector.java | 3 ++-
   webapps/docs/changelog.xml| 5 +
   2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/jasper/compiler/EncodingDetector.java 
b/java/org/apache/jasper/compiler/EncodingDetector.java
index bac9ade2ee..cf3b623104 100644
--- a/java/org/apache/jasper/compiler/EncodingDetector.java
+++ b/java/org/apache/jasper/compiler/EncodingDetector.java
@@ -35,7 +35,8 @@ class EncodingDetector {

   private static final XMLInputFactory XML_INPUT_FACTORY;
   static {
-XML_INPUT_FACTORY = XMLInputFactory.newInstance();
+XML_INPUT_FACTORY = 
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
+EncodingDetector.class.getClassLoader());
   }

   private final String encoding;
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 341c3a6596..0eca891322 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -179,6 +179,11 @@
   and the web application is deployed as a WAR file rather than an
   unpacked directory. (markt)
 
+  
+Prevent the web application's ClassLoader from being pinned by the JSP
+compiler if an application uses a custom XMLInputFactory. Based upon a
+suggestion from Simon Niederberger. (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



-
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: Use server's ClassLoader instead of application's when loading XMLInputFactory.


Rémy,

On 3/22/24 11:39, Rémy Maucherat wrote:

On Fri, Mar 22, 2024 at 2:40 PM  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 988992ba2e Use server's ClassLoader instead of application's when 
loading XMLInputFactory.
988992ba2e is described below

commit 988992ba2e9a8e2c3db47ac960c2fa6c3fc7a8a4
Author: Christopher Schultz 
AuthorDate: Fri Mar 22 09:37:08 2024 -0400

 Use server's ClassLoader instead of application's when loading 
XMLInputFactory.


It doesn't work because there's nothing corresponding to the
XMLInputFactory.class.getName() id. The default newFactory doesn't do
the same thing at all.


Ugh, sorry about that. Thanks for fixing it.

Setting the ContextClassLoader seems like the wrong approach. Isn't 
there a ClassLoader parameter to getFactory for a reason?


-chris



Rémy


---
  java/org/apache/jasper/compiler/EncodingDetector.java | 3 ++-
  webapps/docs/changelog.xml| 5 +
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/jasper/compiler/EncodingDetector.java 
b/java/org/apache/jasper/compiler/EncodingDetector.java
index bac9ade2ee..cf3b623104 100644
--- a/java/org/apache/jasper/compiler/EncodingDetector.java
+++ b/java/org/apache/jasper/compiler/EncodingDetector.java
@@ -35,7 +35,8 @@ class EncodingDetector {

  private static final XMLInputFactory XML_INPUT_FACTORY;
  static {
-XML_INPUT_FACTORY = XMLInputFactory.newInstance();
+XML_INPUT_FACTORY = 
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
+EncodingDetector.class.getClassLoader());
  }

  private final String encoding;
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 341c3a6596..0eca891322 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -179,6 +179,11 @@
  and the web application is deployed as a WAR file rather than an
  unpacked directory. (markt)

+  
+Prevent the web application's ClassLoader from being pinned by the JSP
+compiler if an application uses a custom XMLInputFactory. Based upon a
+suggestion from Simon Niederberger. (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: HTTP / 3 protocol updates


Koti,

On 3/24/24 11:30, Koteswararao Gundapaneni wrote:

When can I expect the update on the HTTP/3 protocol implementation?


HTTP/3

RFC 9114  (June 2022) -
HTTP/3

Not yet implemented by Apache Tomcat. (As of July 2022)


Why pick "July 2022" as an arbitrary date to be not-implemented-as-of 
instead of, say, TODAY?



https://datatracker.ietf.org/doc/html/rfc9114#section-1.1-2


(This reference doesn't seem relevant.)

h3 is not currently a priority for the Apache Tomcat team, for several 
reasons:


1. Tomcat is very often used behind a reverse proxy, where persistent 
HTTP or h2 connections can be used to "solve" the 
connection-establishment "problem".


2. Java does not currently provide an implementation of h3. This means 
we either have to wait for Java to provide such an implementation or 
look to outside libraries such as Quiche. One of the goals of Tomcat is 
to have as few dependencies as possible, so using Quiche, etc. would be 
contrary to those goals.


3. OpenSSL currently does provide an implementation of h3 but it is very 
different than both the current implementation of TLS and also anything 
offered by Java (which does not yet exist).


This is a project run by a small group of volunteers, not a large 
company with many resources. We all have "day jobs" where we spend most 
of our time.


You've been making inquiries about becoming a committer on the project. 
One way to score a lot of points towards that might be to propose a 
working implementation of h3 that can be added to a currently-supported 
version of Tomcat. I would encourage you to work exclusively on the 11.x 
branch, as that is where most new functionality is added before being 
back-ported to the other stable branches.


-chris

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

Re: (tomcat) branch main updated: Set context CL before calling XMLInputFactory.newFactory


Rémy,

On 3/25/24 05:45, r...@apache.org wrote:

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

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


The following commit(s) were added to refs/heads/main by this push:
  new 510c71b009 Set context CL before calling XMLInputFactory.newFactory
510c71b009 is described below

commit 510c71b009085f94122bc18501d1981322846540
Author: remm 
AuthorDate: Mon Mar 25 10:45:28 2024 +0100

 Set context CL before calling XMLInputFactory.newFactory
 
 Passing the CL to XMLInputFactory.newFactory does not work because it

 needs an id (basically the concrete class to load).
 Try the context CL instead.
 The class is preloaded for previous Tomcat versions so it shouldn't be a
 security manager issue.


Ugh, sorry about that. Thanks for fixing it.

Setting the ContextClassLoader seems like the wrong approach. Isn't 
there a ClassLoader parameter to newFactory for a reason?


-chris


---
  java/org/apache/jasper/compiler/EncodingDetector.java | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/jasper/compiler/EncodingDetector.java 
b/java/org/apache/jasper/compiler/EncodingDetector.java
index cf3b623104..fb7795ca16 100644
--- a/java/org/apache/jasper/compiler/EncodingDetector.java
+++ b/java/org/apache/jasper/compiler/EncodingDetector.java
@@ -35,8 +35,15 @@ class EncodingDetector {
  
  private static final XMLInputFactory XML_INPUT_FACTORY;

  static {
-XML_INPUT_FACTORY = 
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
-EncodingDetector.class.getClassLoader());
+ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
+try {
+
Thread.currentThread().setContextClassLoader(EncodingDetector.class.getClassLoader());
+XML_INPUT_FACTORY = XMLInputFactory.newFactory();
+} finally {
+if (oldCl != null) {
+Thread.currentThread().setContextClassLoader(oldCl);
+}
+}
  }
  
  private final String encoding;



-
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: Observability of virtual threads

2024-03-21 Thread Christopher Schultz


Romain,

On 3/20/24 16:25, Romain Manni-Bucau wrote:

Chris, added some comments inline.

Le mer. 20 mars 2024 à 19:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Romain,

On 3/20/24 13:34, Romain Manni-Bucau wrote:

Thread dumps being dump of threads - literally os threads - and virtual
threads not being threads at all - they are runnables in a dedicated

thread

pool - it is quite fair to not make them the same and have their

scheduler

- pool - only in the thread dump but not themselves no?


Maybe.

If you take a thread dump today (with a "real" thread), you only get a
Java stack trace, you get no "native stack trace" or anything like that.
So from that perspective, the "thread" is really the instance of
java.lang.Thread which could just as easily be a Virtual Thread.

You also get no scheduling information, other than what the thread's
"priority" is... but you can't get any real-time data about where it
sits in the scheduling queue, etc.



Well, this does not work like that, as mentionned it is a ForkJoinPool so
not a plain queue - except the design which is not a 1 task = 1 position,
it has multiple queues - so the position in "the queue" does not give you
the information you are mentionned there.


I was using "scheduling queue" as an abstract idea, there. I know it's a 
work-stealing queue which is not straightforward to describe.



If you really care about monitoring this pool you can just
instrument java.lang.VirtualThread#DEFAULT_SCHEDULER (plain reflection
works good enough if you open this part but agents too).


This is Rainer's complaint (which I agree with): there are no standard 
-- available -- APIs for this kind of thing. Use of reflection for 
instrumentation is an anti-pattern IMHO.


The JRE team over the years has learned that instrumentation is a vital 
part of application monitoring and has done a really great job of 
exposing JRE internals through standard APIs. This one is a sore spot 
that really needs to be fixed.



I'm much less interested in what the "native thread" is doing _below_
the Java part. Presumably, it's always running
Thread.cpp::runTheJavaCode and that's not useful information to anybody.



Depends how you instrument/query it, while at code level it does not change
much things and you still get the thread stack context.


... unless you can't get a reference to the threads in the first place, 
which is what Rainer is saying.



For raw thread dumps you indeed need the new jcmd command
(Thread.dump_to_file) and I agree there is no real point to not let it go
in the plain jstack with a new toggle you can enable at need (but hopefully
not by default since we'll end up with undownloadable/too big dumps).


I don't know why this is any different or worse than taking a heap dump. 
Heap dumps have been available for decades and nobody says "OMG what 
will we do with a 16GiB heap dump?!" You only take a heap-dump when you 
NEED it, and the same is true for a thread dump. If you want a thread 
dump and your system can't log it all because you have 100M threads, 
well, then you have made some bad choices.


If there existed an API to query (virtual) threads, your application or 
some tool could examine the threads and only log those you care about. 
That would solve BOTH problems.



Ultimately using reflection and opening jdk.internal.vm package you can
also just use ThreadContainers.root() and iterate over children()/threads()
but not sure how portable it will be.

There is a negative effect there, before we were often decorating executors
(the Runnable to execute) to add before/after context and potentially track
threads there but it does not work anymore since threads are totally
unbounded.




If the Virtual Thread is not mounted on an OS thread, then it's
"suspended" or "blocked" or whatever-it-is. If it's on an OS thread, it
had better be running: that's the whole point of the scheme. (I suppose
it could be BLOCKED-yet-on-an-OS-thread -- one of the current problems
which hopefully will be less of a problem in the future, but I'd like to
ignore that for now).

I don't know what's wrong with having millions of threads, and still
being able to walk through them using existing APIs. Nobody walks
through threads for no good reason... if you want to see the threads,
you should be able to see the threads.

If I wanted to walk-through every instance of java.lang.String in a JVM
(¡millions of them!), then I should be able to do it even if (a) it's a
weird thing to do and (b) it will take a while. Well, I want to do it,
so let me do it(!).

If you have only one "real" Thread (e.g. the main thread) and everything
else is Virtual... when you ask for a thread dump or walk all the
threads, do you only see "main" and not the mounted-on-OS-threads
Virtual Threads? If the JVM were willing to consider Virtual Threads
"visible&

Re: Observability of virtual threads


Romain,

On 3/20/24 13:34, Romain Manni-Bucau wrote:

Thread dumps being dump of threads - literally os threads - and virtual
threads not being threads at all - they are runnables in a dedicated thread
pool - it is quite fair to not make them the same and have their scheduler
- pool - only in the thread dump but not themselves no?


Maybe.

If you take a thread dump today (with a "real" thread), you only get a 
Java stack trace, you get no "native stack trace" or anything like that. 
So from that perspective, the "thread" is really the instance of 
java.lang.Thread which could just as easily be a Virtual Thread.


You also get no scheduling information, other than what the thread's 
"priority" is... but you can't get any real-time data about where it 
sits in the scheduling queue, etc.


I'm much less interested in what the "native thread" is doing _below_ 
the Java part. Presumably, it's always running 
Thread.cpp::runTheJavaCode and that's not useful information to anybody.


If the Virtual Thread is not mounted on an OS thread, then it's 
"suspended" or "blocked" or whatever-it-is. If it's on an OS thread, it 
had better be running: that's the whole point of the scheme. (I suppose 
it could be BLOCKED-yet-on-an-OS-thread -- one of the current problems 
which hopefully will be less of a problem in the future, but I'd like to 
ignore that for now).


I don't know what's wrong with having millions of threads, and still 
being able to walk through them using existing APIs. Nobody walks 
through threads for no good reason... if you want to see the threads, 
you should be able to see the threads.


If I wanted to walk-through every instance of java.lang.String in a JVM 
(¡millions of them!), then I should be able to do it even if (a) it's a 
weird thing to do and (b) it will take a while. Well, I want to do it, 
so let me do it(!).


If you have only one "real" Thread (e.g. the main thread) and everything 
else is Virtual... when you ask for a thread dump or walk all the 
threads, do you only see "main" and not the mounted-on-OS-threads 
Virtual Threads? If the JVM were willing to consider Virtual Threads 
"visible" and therefore dumpable, etc. through existing interfaces 
_while they were mounted on an OS thread_ I could almost agree that 
makes some sense. But if I have a unit of work not making any progress, 
I'm gonna want to be able to see that (Virtual) Thread in a thread dump 
or any other kind of analysis tool, including its stack trace.



Similarly to why threadlocal are not recommended for virtual thread this
would probably make an useless pressure on the JVM IMHO - why there is an
option to see it but it is mainly for debug purposes.
See virtual threads as continuations (suspendable/resumable "Runnable") in
a dedicated and not programmatically configurable nor selectable/proviable
thread pool, they are not in thread dumps and this doesnt bother you ;) -
ultimately if you want it you want all java objects to be monitored and in
the thread dump which would be weird - but I agree the semantic is
misleading.


I'm not sure why ThreadLocals are not recommended for Virtual Threads. 
Honestly, the presence ThreadLocal is a gigantic hack for badly-written 
APIs but if you accept that fact, there doesn't seem to be anything 
really bad about it. It "doesn't make sense" for Virtual Threads because 
it's wasteful: you probably use something once or twice and don't get 
the benefit of it when the thread dies -- because you aren't supposed to 
use thread pools anymore. But it's no less wasteful and dumb than it was 
in the first place.


IIRC, Tomcat uses ThreadLocal to store date-formatting objects for 
access logs. That's a great use for ThreadLocal. If the threads are no 
longer pooled, it's "wasteful" in that we create and discard a 
SimpleDateFormat for every log, but what's the alternative? Use a shared 
SimpleDateFormat and synchronize across threads? Yuck. So it's up to 
Tomcat to decide if ThreadLocal makes sense in a Virtual Thread world.


(Honestly, we need to start using java.time. Now that Tomcat 8.5 no 
longer needs to be supported, we should look at our options for moving-on.)



 From my tests virtual threads do their job but they stay slower than a
proper reactive/async impl mainly due to the overhead they add *everywhere*
compare to reactive programming plus this single thread pool issue which
adds a lot of contention when all the app/lot of tasks is/are done using it
- vs bulkhead pattern for ex.
But if you come from a plain sync application it can be very interesting if
it stays compatible and you don't need to add throttling to control the
memory - often in the old style you throttle with the number of threads,
now you need a semaphore or alike.
Will not be a free lunch ;).


Agreed, free lunches never exist.

But.

If an application exists that never bothered to convert to using 
non-blocking I/O but uses many threads, it could be very easily changed 
(slightly) to use Virtual Threads

Re: Observability of virtual threads

Rainer,

On 3/20/24 13:33, Rainer Jung wrote:

Am 20.03.24 um 18:17 schrieb Christopher Schultz:

Rainer,

Thanks for writing this up.

On 3/20/24 07:22, Rainer Jung wrote:
I wanted to share an observation and I hope the things are correct
how I am describing them. Maybe things have already improved and I am
not aware of it, hints welcome.

Part of JEP 425 (Project Loom, Java virtual threads) discusses how to
handle observability of virtual threads from inside the JVM and tooling.

The final outcome is, that virtual threads are not included in the
typical JVM APIs which one can use to observe threads, like
enumerating them or accessing the stacks of individual threads. As a
consequence, also jstack and "kill -QUIT" do not show virtual threads
at all, not even when they are attached to a native thread and
executing code.

O_O

There is one single method to help with observability of virtual threads

https://docs.oracle.com/en/java/javase/21/docs/api/jdk.management/com/sun/management/HotSpotDiagnosticMXBean.html#dumpThreads(java.lang.String,com.sun.management.HotSpotDiagnosticMXBean.ThreadDumpFormat)

which dumps a full thread dump to a file. Of course that is by no
means appropriate, if you want to do a fine grained observation. At
least you can choose to write a json structure instead of a hard to
parse text format, but that's it.

Boy, that's a real miss from the JVM team. I'm surprised that they
have overlooked this. I don't see a real reason that a Virtual Thread
would be treated any differently than a regular thread.

The JEP hints at "since thre could be millions of virtual threads it
makes no sense to support them in the existing JMX APIs". I don't by
this extremely simplistic reasoning.

Furthermore, the "dump to file" method they provided does not contain
any locking information you usually expect in a thread dump.

For instance I am often using a tool, that inspects our
RequestProcessors to find long running requests and then retrieves
the list of Java threads as ThreadInfo objects to find the one
executing the request and finally retrieves the stack of that request
from the JVM. Such an approach is no longer possible. Almost all of
JMX does not show any info about virtual threads.

It also seems Tomcat no longer uses a pool when a connector is
configured to use virtual threads. So there are no metrics like
currentThreadCount or currentThreadsBusy.

When using virtual threads, the number of requests is the same as the
number of threads, since each request -> new Virtual Thread though
I think the request-count is only incremented when the request has
completed, so maybe there are threads running that can't be counted
(yet).

But I understand that you were hoping to get some information about
these threads and though maybe Tomcat's metrics could help. I guess
not really.

But thread-busy count is the same as in-flight-request count. And
current thread count is the same as in-flight-request count as well.

I guess this also limits the use of some manager features and
probably also the StuckThreadsDetectionValve when combined with
virtual threads.

Most likely. I'm fairly sure that uses the "usual Thread-walker
things" which you are reporting do not work any more with VTs.

What JVM are you using for your investigations?

Zulu 21, but I expect the other OpenJDK variants to behave the same way.
It mostly comes out of the JEP.

Of course Tomcat has solved most of the problems, that virtual
threads want to solve, by doing the hard work of using the NIO and
NIO2 APIs. So virtual threads are probably not that important for us.
But we should be aware of the observability deficiencies whenever we
would discuss whether we could switch from NIO or NIO2 to virtual
threads to simplify connector code in some distant future.

I've been enthusiastically talking with markt about dropping all that
nasty NIO stuff and "going back to BIO with virtual threads" which, at
this point, is mostly a threat and not a promise. But if VTs really
deliver everything they are claiming to deliver, then it may be
possible to go back to BIO as long as servlet-async is retired. And
I'm not holding my breath on that one.

There was an interesting talk at FOSDEM about the current limitations of
the virtual thread implementation. They have several situations where
they switch over to blocking. I think for instance file I/O and also
some types of locks they can not yet handle well.

Yes, these are known issues. Specifically, synchronized blocks and
virtual threads don't play well together, which is why Tomcat recently
converted many synchronized { ... } to use ReentrantLocks, which DO work
with (today's) VTs.

They have some improvements in the pipeline, but I think one would at
least wait for those. And hopefully they improve the observability in
the meantime.

+100

I wish I had known this type

Re: [VOTE] Release Apache Tomcat 10.1.20


Dimitris,

On 3/20/24 09:09, Dimitris Soumis wrote:

+1 All tests pass on Fedora 38 with Java 21, tcnative-2.0.7, openssl-3.0.13.

(Just to mention that testing failed when running for the first time.
Crashed when running org.apache.tomcat.util.net.TestSSLHostConfigCompat.
Running again had no issues.)


If you can get it to fail again, please post the failure here so we can 
look.


We have found and fixed some timing issues when this exact thing happens 
to a tester.


Thanks,
-chris


On Tue, Mar 19, 2024 at 4:04 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


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

The notable changes compared to 10.1.19 are:

- Fix regression when reloading TLS configuration and files.

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

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

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
without changes. Java EE applications designed for Tomcat 9 and earlier
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
will automatically convert them to Jakarta EE and copy them to the
webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.20/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.20
ab4d890c6fa7be3f910370f00fb5c7f10152e21c

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

-
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: Observability of virtual threads

Rainer,

Thanks for writing this up.

On 3/20/24 07:22, Rainer Jung wrote:
I wanted to share an observation and I hope the things are correct how I
am describing them. Maybe things have already improved and I am not
aware of it, hints welcome.

Part of JEP 425 (Project Loom, Java virtual threads) discusses how to
handle observability of virtual threads from inside the JVM and tooling.

The final outcome is, that virtual threads are not included in the
typical JVM APIs which one can use to observe threads, like enumerating
them or accessing the stacks of individual threads. As a consequence,
also jstack and "kill -QUIT" do not show virtual threads at all, not
even when they are attached to a native thread and executing code.

O_O

There is one single method to help with observability of virtual threads

which dumps a full thread dump to a file. Of course that is by no means
appropriate, if you want to do a fine grained observation. At least you
can choose to write a json structure instead of a hard to parse text
format, but that's it.

Boy, that's a real miss from the JVM team. I'm surprised that they have
overlooked this. I don't see a real reason that a Virtual Thread would
be treated any differently than a regular thread.

For instance I am often using a tool, that inspects our
RequestProcessors to find long running requests and then retrieves the
list of Java threads as ThreadInfo objects to find the one executing the
request and finally retrieves the stack of that request from the JVM.
Such an approach is no longer possible. Almost all of JMX does not show
any info about virtual threads.

It also seems Tomcat no longer uses a pool when a connector is
configured to use virtual threads. So there are no metrics like
currentThreadCount or currentThreadsBusy.

When using virtual threads, the number of requests is the same as the
number of threads, since each request -> new Virtual Thread though I
think the request-count is only incremented when the request has
completed, so maybe there are threads running that can't be counted (yet).

But I understand that you were hoping to get some information about
these threads and though maybe Tomcat's metrics could help. I guess not
really.

But thread-busy count is the same as in-flight-request count. And
current thread count is the same as in-flight-request count as well.

I guess this also limits the use of some manager features and probably
also the StuckThreadsDetectionValve when combined with virtual threads.

Most likely. I'm fairly sure that uses the "usual Thread-walker things"
which you are reporting do not work any more with VTs.

What JVM are you using for your investigations?

Of course Tomcat has solved most of the problems, that virtual threads
want to solve, by doing the hard work of using the NIO and NIO2 APIs. So
virtual threads are probably not that important for us. But we should be
aware of the observability deficiencies whenever we would discuss
whether we could switch from NIO or NIO2 to virtual threads to simplify
connector code in some distant future.

I've been enthusiastically talking with markt about dropping all that
nasty NIO stuff and "going back to BIO with virtual threads" which, at
this point, is mostly a threat and not a promise. But if VTs really
deliver everything they are claiming to deliver, then it may be possible
to go back to BIO as long as servlet-async is retired. And I'm not
holding my breath on that one.

-chris

-
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


Jon,

On 3/19/24 13:50, Mcalexander, Jon J. wrote:

I know I'm not a tester, however is 8.5.100 relevant knowing that
8.5x is EOL at the end of the month?
That is correct. I expect this will be the final 8.5.x release unless 
something awful happens in the near future.


I'd be happy to have any member of this community (and you are such if 
you are reading this post) do any kind of testing they deem useful for a 
Tomcat release.


Feel free to run the unit tests (ant test) in your environment and 
report the results. Run your own application using this 
release-candidate and let us know if anything isn't working as expected. 
Or use the "verify-release" to keep us honest. Any of those things are 
helpful to any release manager.


Thanks,
-chris


-Original Message-----
From: Christopher Schultz 
Sent: Tuesday, March 19, 2024 11:09 AM
To: Tomcat Developers List 
Subject: Re: [VOTE] Release Apache Tomcat 8.5.100

All,

On 3/19/24 10:23, Christopher Schultz wrote:

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

The notable changes compared to 8.5.99 are:

- Fix regression when reloading TLS configuration and files.

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

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomcat
-

8.5.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtyS
moAV

SiTjPT2db8olE5tsg1Pcp5wt0SEnRqO3ek_Gc2yNI74-t2phO83t-

WxXwouIr8Sv8R32ve

xfP$

It can be obtained from:
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/tom
cat/tomcat-

8/v8.5.100/__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtySmoAVSiTj

PT2db8olE5tsg1Pcp5wt0SEnRqO3ek_Gc2yNI74-t2phO83t-

WxXwouIr8Sv8RyseCXd6$


The Maven staging repo is:
https://urldefense.com/v3/__https://repository.apache.org/content/repo
sitories/orgapachetomcat-

1487__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtySm

oAVSiTjPT2db8olE5tsg1Pcp5wt0SEnRqO3ek_Gc2yNI74-t2phO83t-

WxXwouIr8Sv8R8

MLP2bU$

The tag is:
https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/8.5.


100/__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtySmoAVSiTjPT2db8olE5ts
g1Pcp5

wt0SEnRqO3ek_Gc2yNI74-t2phO83t-WxXwouIr8Sv8RxxIvQsW$
eddcf278ad919382608ada1898b2c5b63675c6d5

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


+1 for stable release.

The build is 100% reproducible and the unit tests pass[1] including APR on
MacOS x86-64. Works on a vanilla servlet-based application in a development
environment.

[1] The unit tests that fail do so due to a class format error arising from the
combination of the Eclipse compiler, the version of Java, etc.
and can be ignored.

Details:
* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server
VM
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server
VM
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  OS:  Darwin 21.6.0 x86_64
*  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23
Nov 2023)
*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-8.5.100.zip
* Valid GPG signature for apache-tomcat-8.5.100.zip
* Valid SHA-512 signature for apache-tomcat-8.5.100.tar.gz
* Valid GPG signature for apache-tomcat-8.5.100.tar.gz
* Valid SHA-512 signature for apache-tomcat-8.5.100.exe
* Valid GPG signature for apache-tomcat-8.5.100.exe
* Valid SHA512 signature for apache-tomcat-8.5.100-src.zip
* Valid GPG signature for apache-tomcat-8.5.100-src.zip
* Valid SHA512 signature for apache-tomcat-8.5.100-src.tar.gz
* Valid GPG signature for apache-tomcat-8.5.100-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.catalina.mapper.TestMapperWebapps.APR.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO2.txt

Unit tests also pass on Linux x86-64. Details:

* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime
Environment (build 17.0.10+7-Debian-1deb12u1) OpenJDK 64-Bit Server VM
(build 17.0.10+7-Debian-1deb

Re: [VOTE] Release Apache Tomcat 8.5.100


All,

On 3/19/24 10:23, Christopher Schultz wrote:

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

The notable changes compared to 8.5.99 are:

- Fix regression when reloading TLS configuration and files.

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

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.100/

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.100/
eddcf278ad919382608ada1898b2c5b63675c6d5

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


+1 for stable release.

The build is 100% reproducible and the unit tests pass[1] including APR 
on MacOS x86-64. Works on a vanilla servlet-based application in a 
development environment.


[1] The unit tests that fail do so due to a class format error arising 
from the combination of the Eclipse compiler, the version of Java, etc. 
and can be ignored.


Details:
* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)

*  OS:  Darwin 21.6.0 x86_64
*  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-8.5.100.zip
* Valid GPG signature for apache-tomcat-8.5.100.zip
* Valid SHA-512 signature for apache-tomcat-8.5.100.tar.gz
* Valid GPG signature for apache-tomcat-8.5.100.tar.gz
* Valid SHA-512 signature for apache-tomcat-8.5.100.exe
* Valid GPG signature for apache-tomcat-8.5.100.exe
* Valid SHA512 signature for apache-tomcat-8.5.100-src.zip
* Valid GPG signature for apache-tomcat-8.5.100-src.zip
* Valid SHA512 signature for apache-tomcat-8.5.100-src.tar.gz
* Valid GPG signature for apache-tomcat-8.5.100-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.catalina.mapper.TestMapperWebapps.APR.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO2.txt

Unit tests also pass on Linux x86-64. Details:

* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment (build 17.0.10+7-Debian-1deb12u1) OpenJDK 64-Bit Server VM 
(build 17.0.10+7-Debian-1deb12u1, mixed mode, sharing)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment (build 17.0.10+7-Debian-1deb12u1) OpenJDK 64-Bit Server VM 
(build 17.0.10+7-Debian-1deb12u1, mixed mode, sharing)

*  OS:  Linux 6.1.0-12-amd64 x86_64
*  cc:  cc (Debian 12.2.0-14) 12.2.0
*  make:GNU Make 4.3
*  OpenSSL:   OpenSSL 1.1.1 11 Sep 2018
*  APR: 1.7.2
*
* Valid SHA-512 signature for apache-tomcat-8.5.100.zip
* Valid GPG signature for apache-tomcat-8.5.100.zip
* Valid SHA-512 signature for apache-tomcat-8.5.100.tar.gz
* Valid GPG signature for apache-tomcat-8.5.100.tar.gz
* Valid SHA-512 signature for apache-tomcat-8.5.100.exe
* Valid GPG signature for apache-tomcat-8.5.100.exe
* Valid Windows Digital Signature for apache-tomcat-8.5.100.exe
* Valid SHA512 signature for apache-tomcat-8.5.100-src.zip
* Valid GPG signature for apache-tomcat-8.5.100-src.zip
* Valid SHA512 signature for apache-tomcat-8.5.100-src.tar.gz
* Valid GPG signature for apache-tomcat-8.5.100-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.catalina.mapper.TestMapperWebapps.APR.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO2.txt

-
To unsubscribe, e-mail: dev-unsubscr...@tomc

[VOTE] Release Apache Tomcat 8.5.100


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

The notable changes compared to 8.5.99 are:

- Fix regression when reloading TLS configuration and files.

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

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.100/

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.100/
eddcf278ad919382608ada1898b2c5b63675c6d5

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

-
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


All,

On 3/19/24 09:52, Christopher Schultz wrote:

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

The notable changes compared to 10.1.19 are:

- Fix regression when reloading TLS configuration and files.

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

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

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.20/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.20
ab4d890c6fa7be3f910370f00fb5c7f10152e21c

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


+1 for stable release

The build is 100% reproducible and the unit tests pass on MacOS x86-64.

Details:
* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)

*  OS:  Darwin 21.6.0 x86_64
*  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-10.1.20.zip
* Valid GPG signature for apache-tomcat-10.1.20.zip
* Valid SHA-512 signature for apache-tomcat-10.1.20.tar.gz
* Valid GPG signature for apache-tomcat-10.1.20.tar.gz
* Valid SHA-512 signature for apache-tomcat-10.1.20.exe
* Valid GPG signature for apache-tomcat-10.1.20.exe
* Valid SHA512 signature for apache-tomcat-10.1.20-src.zip
* Valid GPG signature for apache-tomcat-10.1.20-src.zip
* Valid SHA512 signature for apache-tomcat-10.1.20-src.tar.gz
* Valid GPG signature for apache-tomcat-10.1.20-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

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

[VOTE] Release Apache Tomcat 10.1.20


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

The notable changes compared to 10.1.19 are:

- Fix regression when reloading TLS configuration and files.

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

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

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.20/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.20
ab4d890c6fa7be3f910370f00fb5c7f10152e21c

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

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

Re: [PR] Unify comma-separated-value code and optimize the implementation [tomcat]

2024-03-15 Thread Christopher Schultz


Mark,

On 3/15/24 13:27, markt-asf (via GitHub) wrote:


markt-asf commented on code in PR #707:
URL: https://github.com/apache/tomcat/pull/707#discussion_r1526610303


##
java/org/apache/catalina/realm/JNDIRealm.java:
##
@@ -966,7 +967,7 @@ private String[] getCipherSuitesArray() {
  containerLog.warn(sm.getString("jndiRealm.emptyCipherSuites"));
  this.cipherSuitesArray = null;
  } else {
-this.cipherSuitesArray = cipherSuites.trim().split("\\s*,\\s*");
+this.cipherSuitesArray = 
StringUtils.splitCommaSeparated(cipherSuites.trim());
  if (containerLog.isTraceEnabled()) {

Review Comment:
Is this trim necessary here? I know it was there before but it looks 
redundant.


Looking back, it does make sense to remove this. I was thinking that as 
I wrote it, but the trim was technically necessary before the change 
from regex to split-then-trim.


I'll shave off this sharp edge.


##
java/org/apache/tomcat/util/buf/StringUtils.java:
##
@@ -94,4 +94,28 @@ public static  void join(Iterable iterable, char 
separator, Function

Checkstyle was happy enough. :)

I'll get that corrected.

-chris

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

2024-03-15 Thread Christopher Schultz


Mark and Rémy,

On 3/13/24 10:53, Mark Thomas wrote:

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.


I'm going to make these changes immediately:

1. Implement -1 = disabled

2. Set default to -1 instead of 180 for main/10.1/9

3. Set default to 180 for 8.5.x

It would be "easy" to configure this for periodic checking, but I'm not 
going to do that quite yet.


-chris

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

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

2024-03-15 Thread Christopher Schultz


Mark,

On 3/15/24 07:52, Mark Thomas wrote:
Just wondering what your thinking was for the March releases of 10.1.x 
and 8.5.x


I definitely want to make the changes discussed on dev@ for the Tomcat 
age-nagging, plus one more thing to round-off before cutting 8.5.final.


I was planning to do both releases at the same time, which is why I 
haven't done either, yet.


I could have a release build by the end of the day, I'd imagine.

-chris

-
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

2024-03-14 Thread Christopher Schultz


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

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

2024-03-13 Thread Christopher Schultz


Rémy,

On 3/12/24 12:05, Rémy Maucherat wrote:

On Tue, Mar 12, 2024 at 3:02 PM Christopher Schultz
 wrote:


Mark,

On 3/12/24 05:00, Mark Thomas wrote:

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


I could add a special case for "disable" or you could set it to a very
high value.

If your Tomcat installation is still running in 32768 days, you
certainly won't give a damn if it starts issuing warnings.


I don't like this either. It might get me into real trouble with my
downstream, actually.

Unless there's a security issue, I think people don't really really
have to upgrade working production systems that often. For example,
between 9.0.62 and 9.0.71, no CVEs above low. And even if there was
most often a user will not be affected. Upgrading costs testing and
resources, so ...

I'm not advocating that users should never upgrade, but building in a
nag by default is not great. Esp 6 months. By the time things are
upgraded they will start nagging again the next day pretty much. Then
a warn log about security often cannot be simply ignored.


Okay. Are you suggestion any of the following?

1. A longer default nag-duration

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

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.


That's why I made it "on by default".

Another option would be:

5. Change the behavior between 8.5 and the other branches. 8.5 could 
have this on-by-default while the others do not. We might make it a 
policy to "change to on-by-default around EOL time" so that most people 
will not change the configuration from the default, but then the default 
changes for the final release(s) in a branch.


In terms of "you only need to upgrade if there are CVEs"... that would 
be a very difficult policy for us to manage, because any release we know 
has any CVEs would be released before we knew it had them. Any new 
release with fixes cannot announce to the old releases that they need to 
be upgraded.


My goal was to improve security for those who are unlikely to be paying 
attention to announce@tomcat or using any of the publicly (and 
non-publicly) available bug trackers and services to ensure they aren't 
running vulnerable versions of Tomcat.


We often release fixes without announcing them until long after the 
fact, which means that any new release could conceivably be a "security 
release". You (downstream) won't know until later whether or not you 
should have upgraded. So the best advice is to upgrade as often as it is 
convenient for you to do so. This is simply a reminder to do it.


Since we have releases roughly every month, I figured that 
every-6-months would be a good cadence. And it can always be configured 
to shut up "forever" if necessary.


-chris

-
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

2024-03-12 Thread Christopher Schultz


Rémy,

Thank for RMing.

On 3/11/24 07:09, Rémy Maucherat wrote:

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

The notable changes compared to 9.0.86 are:

- When restoring a saved POST request after a successful FORM
authentication, ensure that neither the URI, the query string nor
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.

- The standard thread pool implementations that are
configured using the Executor element now implement
ExecutorService for better support of NIO2 or others.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.87/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1485
The tag is:
https://github.com/apache/tomcat/tree/9.0.87
4c4c166c3d7fd2d00801657c7a78fc7d46c8ec32

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


+1 for stable release.

Works with a vanilla servlet-based application in a development environment.

Unit tests pass on arm64 MacOS. The build is reproducible except for the 
fulldocs package which is missing specific file content due to a JDK bug.


Details:
* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Ant: Apache Ant(TM) version 1.10.14 compiled on August 16 
2023

*  OS:  Darwin 23.3.0 arm64
*  cc:  Apple clang version 15.0.0 (clang-1500.1.0.2.5)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-9.0.87.zip
* Valid GPG signature for apache-tomcat-9.0.87.zip
* Valid SHA-512 signature for apache-tomcat-9.0.87.tar.gz
* Valid GPG signature for apache-tomcat-9.0.87.tar.gz
* Valid SHA-512 signature for apache-tomcat-9.0.87.exe
* Valid GPG signature for apache-tomcat-9.0.87.exe
* Valid SHA512 signature for apache-tomcat-9.0.87-src.zip
* Valid GPG signature for apache-tomcat-9.0.87-src.zip
* Valid SHA512 signature for apache-tomcat-9.0.87-src.tar.gz
* Valid GPG signature for apache-tomcat-9.0.87-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

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

Re: [VOTE] Release Apache Tomcat 11.0.0-M18

2024-03-12 Thread Christopher Schultz


Mark,

Thanks for RMing

On 3/9/24 1:52 PM, 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


+1 for alpha release.

Unit tests pass on x86-64 MacOS. The build is reproducible except for 
the fulldocs package which is missing specific file content due to a JDK 
bug.


Details:

* Environment
*  Java (build):openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment (build 22+35-2369) OpenJDK 64-Bit Server VM (build 
22+35-2369, mixed mode, sharing)
*  Java (test): openjdk version "22" 2024-03-19 OpenJDK Runtime 
Environment (build 22+35-2369) OpenJDK 64-Bit Server VM (build 
22+35-2369, mixed mode, sharing)

*  OS:  Darwin 21.6.0 x86_64
*  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
*  make:GNU Make 3.81
*  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-11.0.0-M18.zip
* Valid GPG signature for apache-tomcat-11.0.0-M18.zip
* Valid SHA-512 signature for apache-tomcat-11.0.0-M18.tar.gz
* Valid GPG signature for apache-tomcat-11.0.0-M18.tar.gz
* Valid SHA-512 signature for apache-tomcat-11.0.0-M18.exe
* Valid GPG signature for apache-tomcat-11.0.0-M18.exe
* Valid SHA512 signature for apache-tomcat-11.0.0-M18-src.zip
* Valid GPG signature for apache-tomcat-11.0.0-M18-src.zip
* Valid SHA512 signature for apache-tomcat-11.0.0-M18-src.tar.gz
* Valid GPG signature for apache-tomcat-11.0.0-M18-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED


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

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

2024-03-12 Thread Christopher Schultz


Mark,

On 3/12/24 05:00, Mark Thomas wrote:

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


I could add a special case for "disable" or you could set it to a very 
high value.


If your Tomcat installation is still running in 32768 days, you 
certainly won't give a damn if it starts issuing warnings.


-chris

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

Re: (tomcat) branch main updated: Add new valveSkip flag, also fix no rewrite rule match

2024-03-08 Thread Christopher Schultz


Rémy,

On 3/8/24 09:46, r...@apache.org wrote:

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

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


The following commit(s) were added to refs/heads/main by this push:
  new 7a3bbc6e30 Add new valveSkip flag, also fix no rewrite rule match
7a3bbc6e30 is described below

commit 7a3bbc6e300ced35268fe1c46c90f6b5c752dc5c
Author: remm 
AuthorDate: Fri Mar 8 15:46:04 2024 +0100

 Add new valveSkip flag, also fix no rewrite rule match
 
 This allows skipping the next valve in the Catalina pipeline, for

 conditional execution. This was inspired by BZ 60997, which the rewrite
 valve can do (set the rewrite valve, then set the semaphore valve next;
 if match then the semaphore is skipped).
 Also notice major issue where rewrite is considered to have occurred
 when the output is identical but equals return false due to type
 differences.
---
  .../apache/catalina/valves/rewrite/RewriteRule.java  | 14 ++
  .../apache/catalina/valves/rewrite/RewriteValve.java | 20 ++--
  .../catalina/valves/rewrite/TestRewriteValve.java| 18 ++
  webapps/docs/changelog.xml   |  9 +
  webapps/docs/rewrite.xml | 11 +++
  5 files changed, 70 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/catalina/valves/rewrite/RewriteRule.java 
b/java/org/apache/catalina/valves/rewrite/RewriteRule.java
index e4466d525b..269eedab7f 100644
--- a/java/org/apache/catalina/valves/rewrite/RewriteRule.java
+++ b/java/org/apache/catalina/valves/rewrite/RewriteRule.java
@@ -335,6 +335,11 @@ public class RewriteRule {
  protected boolean type = false;
  protected String typeValue = null;
  
+/**

+ * Allows skipping the next valve in the Catalina pipeline.
+ */
+protected boolean valveSkip = false;
+


Maybe "skipNextValve"? "valveSkip" isn't super descriptive.

Same with accessor/mutator.

Same for ValveSkip/VS flag name? Maybe SNV? SkipNextValve?

-chris


  public boolean isEscapeBackReferences() {
  return escapeBackReferences;
  }
@@ -560,4 +565,13 @@ public class RewriteRule {
  public void setCookieHttpOnly(boolean cookieHttpOnly) {
  this.cookieHttpOnly = cookieHttpOnly;
  }
+
+public boolean isValveSkip() {
+return this.valveSkip;
+}
+
+public void setValveSkip(boolean valveSkip) {
+this.valveSkip = valveSkip;
+}
+
  }
diff --git a/java/org/apache/catalina/valves/rewrite/RewriteValve.java 
b/java/org/apache/catalina/valves/rewrite/RewriteValve.java
index 492d45e26d..d15210621d 100644
--- a/java/org/apache/catalina/valves/rewrite/RewriteValve.java
+++ b/java/org/apache/catalina/valves/rewrite/RewriteValve.java
@@ -38,6 +38,7 @@ import org.apache.catalina.Context;
  import org.apache.catalina.Lifecycle;
  import org.apache.catalina.LifecycleException;
  import org.apache.catalina.Pipeline;
+import org.apache.catalina.Valve;
  import org.apache.catalina.connector.Connector;
  import org.apache.catalina.connector.Request;
  import org.apache.catalina.connector.Response;
@@ -319,11 +320,12 @@ public class RewriteValve extends ValveBase {
  boolean done = false;
  boolean qsa = false;
  boolean qsd = false;
+boolean valveSkip = false;
  for (int i = 0; i < rules.length; i++) {
  RewriteRule rule = rules[i];
  CharSequence test = (rule.isHost()) ? host : urlDecoded;
  CharSequence newtest = rule.evaluate(test, resolver);
-if (newtest != null && !test.equals(newtest.toString())) {
+if (newtest != null && 
!test.toString().equals(newtest.toString())) {
  if (containerLog.isTraceEnabled()) {
  containerLog.trace("Rewrote " + test + " as " + 
newtest
  + " with rule pattern " + 
rule.getPatternString());
@@ -345,6 +347,10 @@ public class RewriteValve extends ValveBase {
  qsd = true;
  }
  
+if (!valveSkip && newtest != null && rule.isValveSkip()) {

+valveSkip = true;
+}
+
  // Final reply
  
  // - forbidden

@@ -543,7 +549,15 @@ public class RewriteValve extends ValveBase {
  pipeline.getFirst().invoke(request, response);
  }
  } else {
-getNext().invoke(request, response);
+Valve next = getNext();
+if (valveSkip) {
+next = next.getNext();
+if (next == null) {
+// Ignore and invoke the next valve normally
+next = getNext();
+}
+}
+

Re: Planning for 8.5.final

2024-03-07 Thread Christopher Schultz


All,

On 3/6/24 08:54, Christopher Schultz wrote:

All,

I was wondering if anyone had any thoughts on adding anything to 
8.5.final (likely .100) to indicate that the build was the last in the 
series. Of course, we will advertise EOL on the web site, etc. but I was 
thinking something more runtime-oriented.


Would it be okay to add an INFO log on startup that says "8.5.x has 
reached EOL and you should consider upgrading to 9.0 or later. Bug fixes 
including security fixes are unlikely to be released for 8.5.x after 
2024-03-31."


Perhaps that's too annoying?

I'm even thinking that we might want to bake this kind of thing into all 
releases. Every release knows its release-date, and we could have a 
start message that warns the user whenever the release-date gets to be 
reasonably far in the past. Say, 6 months. Or a year. Something 
"reasonable". Just in case nobody bothers to upgrade to x.y.final to see 
this kind of message.


Any thoughts?


Mark Thomas and I discussed this last night over dinner while he was in 
town. I can't tell you how mice it is to get together with people from 
this community in-person. I hope I can meet some of you in Bratislava if 
possible.


In general, this seems like a Good Idea but it needs a little bit of tuning.

My plan is to work on a PR that looks something like this:

1. It will be a feature of the SecurityListener
2. It will simply log a WARN message once the release gets to be 
"somewhat old"

3. It will be tunable, at least slightly
4. It should not act oddly in development environments

-chris

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

Re: (tomcat) 03/03: Add new suspendWrappedResponseAfterForward


Rémy,

On 3/6/24 09:02, r...@apache.org wrote:

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

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

commit 6f85b32c545539f36266ef83218d85c9656ae6a9
Author: remm 
AuthorDate: Wed Mar 6 11:44:14 2024 +0100

 Add new suspendWrappedResponseAfterForward
 
 This allow configuring the suspend after forward unwrapping.

---
  java/org/apache/catalina/Context.java   | 17 +
  .../org/apache/catalina/core/ApplicationDispatcher.java |  3 ++-
  java/org/apache/catalina/core/StandardContext.java  | 14 ++
  java/org/apache/catalina/startup/FailedContext.java |  9 +
  test/org/apache/tomcat/unittest/TesterContext.java  |  5 +
  webapps/docs/changelog.xml  |  5 -
  webapps/docs/config/context.xml |  7 +++
  7 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/catalina/Context.java 
b/java/org/apache/catalina/Context.java
index fb50454dcc..2f66fb46c5 100644
--- a/java/org/apache/catalina/Context.java
+++ b/java/org/apache/catalina/Context.java
@@ -1994,6 +1994,23 @@ public interface Context extends Container, ContextBind {
  void setDispatcherWrapsSameObject(boolean dispatcherWrapsSameObject);
  
  
+/**

+ * If this is true, then following a forward the response will
+ * be unwrapped to suspend the Catalina response instead of simply closing
+ * the top level response. The default value is true.
+ * @return the flag value
+ */
+boolean getSuspendWrappedResponseAfterForward();
+
+
+/**
+ * Allows unwrapping the response object to suspend the response following
+ * a forward.
+ * @param suspendWrappedResponseAfterForward the new flag value
+ */
+void setSuspendWrappedResponseAfterForward(boolean 
suspendWrappedResponseAfterForward);
+
+
  /**
   * Find configuration file with the specified path, first looking into the
   * webapp resources, then delegating to
diff --git a/java/org/apache/catalina/core/ApplicationDispatcher.java 
b/java/org/apache/catalina/core/ApplicationDispatcher.java
index eff85041f6..abb7b2fe4d 100644
--- a/java/org/apache/catalina/core/ApplicationDispatcher.java
+++ b/java/org/apache/catalina/core/ApplicationDispatcher.java
@@ -355,7 +355,8 @@ final class ApplicationDispatcher implements 
AsyncDispatcher, RequestDispatcher
  if (response instanceof ResponseFacade) {
  finished = true;
  ((ResponseFacade) response).finish();
-} else if (response instanceof ServletResponseWrapper) {
+} else if (context.getSuspendWrappedResponseAfterForward()
+&& response instanceof ServletResponseWrapper) {
  ServletResponse baseResponse = response;
  do {
  baseResponse = ((ServletResponseWrapper) 
baseResponse).getResponse();
diff --git a/java/org/apache/catalina/core/StandardContext.java 
b/java/org/apache/catalina/core/StandardContext.java
index 698dadf132..4f13b69a3f 100644
--- a/java/org/apache/catalina/core/StandardContext.java
+++ b/java/org/apache/catalina/core/StandardContext.java
@@ -798,6 +798,8 @@ public class StandardContext extends ContainerBase 
implements Context, Notificat
  
  private boolean dispatcherWrapsSameObject = Globals.STRICT_SERVLET_COMPLIANCE;
  
+private boolean suspendWrappedResponseAfterForward = false;

+
  private boolean parallelAnnotationScanning = false;
  
  private boolean useBloomFilterForArchives = false;

@@ -881,6 +883,18 @@ public class StandardContext extends ContainerBase 
implements Context, Notificat
  }
  
  
+@Override

+public boolean getSuspendWrappedResponseAfterForward() {
+return suspendWrappedResponseAfterForward;
+}
+
+
+@Override
+public void setSuspendWrappedResponseAfterForward(boolean 
suspendWrappedResponseAfterForward) {
+this.suspendWrappedResponseAfterForward = 
suspendWrappedResponseAfterForward;
+}
+
+
  @Override
  public String getRequestCharacterEncoding() {
  return requestEncoding;
diff --git a/java/org/apache/catalina/startup/FailedContext.java 
b/java/org/apache/catalina/startup/FailedContext.java
index eb249a1d16..6ca2063a46 100644
--- a/java/org/apache/catalina/startup/FailedContext.java
+++ b/java/org/apache/catalina/startup/FailedContext.java
@@ -1425,4 +1425,13 @@ public class FailedContext extends LifecycleMBeanBase 
implements Context {
  public void setUseBloomFilterForArchives(boolean 
useBloomFilterForArchives) {
  }
  
+@Override

+public boolean getSuspendWrappedResponseAfterForward() {
+return false;
+}
+
+@Override
+public void setSuspendWrappedResponseAfterForward(boolean 
suspendWrappedResponseAfterForward) {
+}
+
  }
\ No newline at end of file
diff --git

Re: March releases


Mark,

On 3/5/24 07:18, Mark Thomas wrote:

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.


I have two Intel Macs where I can run unit tests for you if you are 
excited about getting started sooner.


But I agree: there is no rush. Releasing 8.5.x toward the end of the 
month is preferable just in case we discover something else we'd really 
like to fix.


-chris

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

Planning for 8.5.final


All,

I was wondering if anyone had any thoughts on adding anything to 
8.5.final (likely .100) to indicate that the build was the last in the 
series. Of course, we will advertise EOL on the web site, etc. but I was 
thinking something more runtime-oriented.


Would it be okay to add an INFO log on startup that says "8.5.x has 
reached EOL and you should consider upgrading to 9.0 or later. Bug fixes 
including security fixes are unlikely to be released for 8.5.x after 
2024-03-31."


Perhaps that's too annoying?

I'm even thinking that we might want to bake this kind of thing into all 
releases. Every release knows its release-date, and we could have a 
start message that warns the user whenever the release-date gets to be 
reasonably far in the past. Say, 6 months. Or a year. Something 
"reasonable". Just in case nobody bothers to upgrade to x.y.final to see 
this kind of message.


Any thoughts?

-chris

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


All,

*bump*

Any thoughts?

-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

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

2024-02-28 Thread Christopher Schultz


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

Re: March releases

2024-02-27 Thread Christopher Schultz


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.


-chris

-
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

2024-02-26 Thread Christopher Schultz


Rémy,

On 2/23/24 08: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 ?


I'm not sure why, but I find it annoying that you can't build some 
Tomcat releases with the versions on which they are intended to run.


It's too bad the FFM stuff didn't land until Java 19.

-chris

-
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

2024-02-26 Thread Christopher Schultz


Mark,

On 2/22/24 15:11, Mark Thomas wrote:

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.


Whoops. Thanks for taking care of this, Mark.

-chris

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

Re: JDK 22 Release Candidates & Virtual Threads pinning heads-up

2024-02-26 Thread Christopher Schultz

All,

On 2/20/24 03:05, David Delabassee wrote:

Welcome to the latest OpenJDK Quality Outreach update!

The first JDK 22 Release Candidates builds are now available [1]. At this
stage, only P1 issues will still be evaluated. And with the JDK 22 General
Availability set for March 19th, it is now time to fully focus on JDK 23. At
the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP
455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But
new JEP candidates [3][4] have recently been announced, so things should evolve
rapidly.

I'd like to thank those of you who have already provided feedback on the JDK 22 EA
builds. Feedback is always extremely useful, even more, when it comes early in the
development cycle. Another area where we need your help is Loom. So, please make sure to
check the heads-up below that discusses the so-called Virtual Threads "pinning"
issue.

[1] https://openjdk.org/projects/jdk/22/
[2] https://openjdk.org/jeps/455
[3] https://openjdk.org/jeps/465
[4] https://openjdk.org/jeps/466

## Heads-up: Virtual Threads “Pinning” Issue

Virtual threads became a permanent feature in JDK 21. This feature has been extremely well received by the
Java ecosystem but there are still a few pain points. Much has been written about the so-called
"pinning" issue that arises with synchronized methods or synchronized statements. The two most
common cases are (a) a virtual thread parks (ex. doing socket I/O) while in a synchronized method, and (b) a
virtual thread blocks entering a synchronized method because the object's associated monitor is held by
another thread. In both cases, the underlying carrier/native thread is not "released" to do other
work. Performance and scalability may suffer and in some cases, starvation and deadlock might happen. This
recent "Virtual Threads Next Steps" video [5] explains in more details the why's and discusses some
potential solutions.

New Loom early-access builds haven been recently published [6]. Those Loom EA
builds have changes to the object monitor implementation that do not pin for
these two common cases. The Loom team needs your help to test these updated
object monitors with code that you know is using virtual threads and with
libraries that are heavily synchronized. The goal is to gauge both reliability
and performance.

This has the potential to make a real positive impact on real-world
applications. Most applications I know use network connections during
most request-processing activities e.g. contacting a database where the
JDBC driver has lots of synchronized blocks.

For those who have tried using Virtual Threads and found that there was
either no observable performance improvement or, worse, a significant
performance *drop* should consider testing this out.

I haven't set up a test environment to exercise Virtual Threads so I'm
not in a great position to reply about this, but I know there have been
some posts to this mailing-list. I hope those who have been trying it
out are able to re-try with Java 22 and confirm that (a) you get a
performance benefit of some kind and (b) your application doesn't crash
all over the place with this new locking strategy.

-chris

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

[VOTE][RESULT] Release Apache Tomcat 8.5.99


All,

The following votes were cast:

+1: remm, schultz, fschumacher

Non-binding:

+1: Dimitris Soumis

There were no other votes, therefore, the vote passes.

Thanks to everyone who contributed toward this release.

-chris


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

The notable changes compared to 8.5.99 are:

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.99/

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.99/
fe841cca81f15355ed4096c5c155f0ceb49a05da

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



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

[VOTE] Release Apache Tomcat 8.5.99


All,

The following votes were cast:

+1: remm, schultz, fschumacher

Non-binding:

+1: Dimitris Soumis

There were no other votes, therefore, the vote passes.

Thanks to everyone who contributed toward this release.

-chris


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

The notable changes compared to 8.5.99 are:

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.99/

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.99/
fe841cca81f15355ed4096c5c155f0ceb49a05da

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



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

[VOTE][RESULT] Release Apache Tomcat 10.1.19


All,

The following votes were cast:

+1: remm, jflere, schultz, fschumacher

Non-binding:

+1: Dimitris Soumis

There were no other votes, therefore, the vote passes.

Thanks to everyone who contributed toward this release.

-chris


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

The notable changes compared to 10.1.18 are:

- 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-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be placed 
in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically 
convert them to Jakarta EE and copy them to the webapps directory.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.19/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.19
9287d3342f12d20cbdb66c11228b0f80a40a43a0

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



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





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?


-chris

-
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

2024-02-16 Thread Christopher Schultz


Rémy,

On 2/15/24 18:26, Christopher Schultz wrote:

Rémy,

Thanks for RMing.

On 2/14/24 03:53, Rémy Maucherat wrote:

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

The notable changes compared to 9.0.85 are:

- 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 changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.86/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1481
The tag is:
https://github.com/apache/tomcat/tree/9.0.86
542c35ae834fb29616b184a0e4276a5b7f8542de

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


+1 for stable release.

Build is reproducible on MacOS arm64 and x86-64, except for the 
"fulldocs" package which has known issues for reproducibility.


The unit tests for NIO and NIO2 pass on those platforms as well. APR 
tests passed on x86-84 but the APR library wasn't loaded successfully on 
arm64 for some reason which I will investigate later.


My tests on the arm64 platform were not correctly-specifying the 
location of the apr library, so tcnative was not loadable.


Fixing that has proved all unit tests for NIO, NIO2, and APR all passing 
on MacOS arm64.


-chris

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

2024-02-16 Thread Christopher Schultz


All,

On 2/14/24 18:10, Christopher Schultz wrote:

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

The notable changes compared to 8.5.99 are:

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.99/

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.99/
fe841cca81f15355ed4096c5c155f0ceb49a05da

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


+1 for stable release.

Works on plain servlet-based application in a development environment.

The build is reproducible on Linux minus a few discrepancies with exact 
JDK build numbers in JAR file MANIFEST.MF files.


Unit tests pass on MacOS and Linux.

Note that the TestMapperWebapps unit-test fails because the version of 
ECJ that ships with Tomcat is too old for Java 17, and I haven't made 
arrangements in my test harness to upgrade ECJ.


Details:

* Environment
*  Java (build): openjdk version "17.0.10" 2024-01-16 OpenJDK 
Runtime Environment (build 17.0.10+7-Debian-1deb12u1) OpenJDK 64-Bit 
Server VM (build 17.0.10+7-Debian-1deb12u1, mixed mode, sharing)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment (build 17.0.10+7-Debian-1deb12u1) OpenJDK 64-Bit Server VM 
(build 17.0.10+7-Debian-1deb12u1, mixed mode, sharing)

*  OS:   Linux 6.1.0-12-amd64 x86_64
*  cc:   cc (Debian 12.2.0-14) 12.2.0
*  make: GNU Make 4.3
*  OpenSSL:  OpenSSL 1.1.1 11 Sep 2018
*  APR:  1.7.2
*
* Valid SHA-512 signature for apache-tomcat-8.5.99.zip
* Valid GPG signature for apache-tomcat-8.5.99.zip
* Valid SHA-512 signature for apache-tomcat-8.5.99.tar.gz
* Valid GPG signature for apache-tomcat-8.5.99.tar.gz
* Valid SHA-512 signature for apache-tomcat-8.5.99.exe
* Valid GPG signature for apache-tomcat-8.5.99.exe
* Valid Windows Digital Signature for apache-tomcat-8.5.99.exe
* Valid SHA512 signature for apache-tomcat-8.5.99-src.zip
* Valid GPG signature for apache-tomcat-8.5.99-src.zip
* Valid SHA512 signature for apache-tomcat-8.5.99-src.tar.gz
* Valid GPG signature for apache-tomcat-8.5.99-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.catalina.mapper.TestMapperWebapps.APR.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO.txt
* org.apache.catalina.mapper.TestMapperWebapps.NIO2.txt

-
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

2024-02-15 Thread Christopher Schultz


Rémy,

Thanks for RMing.

On 2/14/24 03:53, Rémy Maucherat wrote:

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

The notable changes compared to 9.0.85 are:

- 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 changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.86/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1481
The tag is:
https://github.com/apache/tomcat/tree/9.0.86
542c35ae834fb29616b184a0e4276a5b7f8542de

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


+1 for stable release.

Build is reproducible on MacOS arm64 and x86-64, except for the 
"fulldocs" package which has known issues for reproducibility.


The unit tests for NIO and NIO2 pass on those platforms as well. APR 
tests passed on x86-84 but the APR library wasn't loaded successfully on 
arm64 for some reason which I will investigate later.


-chris

-
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

2024-02-15 Thread Christopher Schultz


Mark,

Thanks for RMing.

On 2/13/24 17: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


+1 for Alpha release.

The build is 100% reproducible on MacOS aarch64 and x86-64.

The unit tests pass on those platforms as well.

-chris

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

2024-02-15 Thread Christopher Schultz


All,

On 2/14/24 17:43, Christopher Schultz wrote:

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

The notable changes compared to 10.1.18 are:

- 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-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.19/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.19
9287d3342f12d20cbdb66c11228b0f80a40a43a0

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


+1 for stable release. Unit tests pass on MacOS aarch64 and x86-64.

Details below:

* Environment
*  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
*  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime 
Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM 
Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)

*  OS:  Darwin 23.2.0 arm64
*  cc:  Apple clang version 15.0.0 (clang-1500.1.0.2.5)
*  make:GNU Make 3.81
*  OpenSSL: OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-10.1.19.zip
* Valid GPG signature for apache-tomcat-10.1.19.zip
* Valid SHA-512 signature for apache-tomcat-10.1.19.tar.gz
* Valid GPG signature for apache-tomcat-10.1.19.tar.gz
* Valid SHA-512 signature for apache-tomcat-10.1.19.exe
* Valid GPG signature for apache-tomcat-10.1.19.exe
* Valid SHA512 signature for apache-tomcat-10.1.19-src.zip
* Valid GPG signature for apache-tomcat-10.1.19-src.zip
* Valid SHA512 signature for apache-tomcat-10.1.19-src.tar.gz
* Valid GPG signature for apache-tomcat-10.1.19-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

And also:

* Environment
*  Java (build): openjdk version "17.0.9" 2023-10-17 OpenJDK Runtime 
Environment Temurin-17.0.9+9 (build 17.0.9+9) OpenJDK 64-Bit Server VM 
Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)
*  Java (test): openjdk version "17.0.9" 2023-10-17 OpenJDK Runtime 
Environment Temurin-17.0.9+9 (build 17.0.9+9) OpenJDK 64-Bit Server VM 
Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)

*  OS:  Darwin 21.6.0 x86_64
*  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
*  make:GNU Make 3.81
*  OpenSSL: OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23 
Nov 2023)

*  APR: 1.7.4
*
* Valid SHA-512 signature for apache-tomcat-10.1.19.zip
* Valid GPG signature for apache-tomcat-10.1.19.zip
* Valid SHA-512 signature for apache-tomcat-10.1.19.tar.gz
* Valid GPG signature for apache-tomcat-10.1.19.tar.gz
* Valid SHA-512 signature for apache-tomcat-10.1.19.exe
* Valid GPG signature for apache-tomcat-10.1.19.exe
* Valid SHA512 signature for apache-tomcat-10.1.19-src.zip
* Valid GPG signature for apache-tomcat-10.1.19-src.zip
* Valid SHA512 signature for apache-tomcat-10.1.19-src.tar.gz
* Valid GPG signature for apache-tomcat-10.1.19-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: PASSED

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

[VOTE] Release Apache Tomcat 8.5.99

2024-02-14 Thread Christopher Schultz


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

The notable changes compared to 8.5.99 are:

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

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.99/

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.99/
fe841cca81f15355ed4096c5c155f0ceb49a05da

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

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

[VOTE] Release Apache Tomcat 10.1.19

2024-02-14 Thread Christopher Schultz


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

The notable changes compared to 10.1.18 are:

- 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-10.1.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.19/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.19
9287d3342f12d20cbdb66c11228b0f80a40a43a0

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

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

Re: February release tagging

2024-02-13 Thread Christopher Schultz


Rémy,

On 2/13/24 09:34, Rémy Maucherat wrote:

On Tue, Feb 13, 2024 at 3:28 PM Christopher Schultz
 wrote:


Mark,

On 2/13/24 08:11, 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 still have OpenSSL 3.2.0 on MacOS, both x86-64 and M2 available.

How do I specifically test FFM? Just run the unit tests as usual on main
HEAD?


On CI, it is using 1.1.1 ;)
OpenSSLLibrary.init OpenSSL successfully initialized using FFM
[OpenSSL 1.1.1f  31 Mar 2020]

So you can run whatever OpenSSL but only using the latest Java.


I've just run all the unit tests on main-HEAD on aarch64 MacOS with Java 
21 and OpenSSL 3.2.0, and only a singe test failed:


org.apache.tomcaat.util.net.TestSsl.NIO

The error is "SSLHandshakeException: Remote host terminated the 
handshake" caused by "EOLException: SSL peer shut down incorrectly".


The failure appears to be in the client, reporting that the server 
shut-down the connection incorrectly.


In the same test report, there are some "SKIPPED" items, inclluding 
"expected true, got false" for a number of them. Are those ... expected? 
Copy/paste isn't convenient from my M2 Mac into this email, but I can 
provide the full report if that would be helpful.


There are about 10 unit-tests with skipped tests for both NIO and NIO2.

-chris

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

Re: February release tagging

2024-02-13 Thread Christopher Schultz


Mark,

On 2/13/24 08:11, 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 still have OpenSSL 3.2.0 on MacOS, both x86-64 and M2 available.

How do I specifically test FFM? Just run the unit tests as usual on main 
HEAD?


-chris

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

Required build version(s)


All,

The release managers have bumped-up their tool chains to Java 17 or 
later for all supported releases. Tomcat 11 requires Java 21. Tomcat 
8.5.x only requires Java 11.


But the documented Java versions for each release are actually:

Tomcat 11 - Java 21
Tomcat 10 - Java 11
Tomcat  9 - Java 8
Tomcat  8 - Java 7

Theoretically, anyone ought to be able to build Tomcat with the 
minimum-required Java version for that branch. There are some practical 
reasons why you can't build Tomcat 8.5.x with Java 7 but those have more 
to do with supporting versions of Java *after* 7 than anything else.


I'd like to be able to allow anyone to build their Tomcat from source 
using our tooling (e.g. ant-based build) and the minimum Java version 
(with one exception: No support for Java 7 for builds).


Take Tomcat 9.0.x for example. The ant-based build will complain if you 
are using Java 11 to build, because the build tools demand the use of 
Java 17. If you simply change the "required version" from 17 to 11, the 
build works perfectly fine.


I honestly can't remember why we switched everything from Java 11 to 
Java 17 for Tomcat 9.0.x, but the point is that it works. We may still 
want to do official releases using Java 17 or 21 or whatever, but 
*regular users* ought to be able to build from source without too much 
trouble.


I'm wondering if we could do something like the following:

1. Change build.java.version to be the *actual* minimum supported JDK 
for the build. This would be the lowest version of Java known to 
successfully compile the package. I would argue this should be set to 
the "Minimum Java Version" for that release.


2. Introduce a new release.java.version to be set to the minimum 
supported JDK for a *release* build. This can be set to whatever the 
release managers deem appropriate.


3. During "ant pre-release", we take the release.java.version setting 
and copy it into the build.properties.release file like this:


build.java.version=${release.java.version}

Then, when a release-build is performed, it will require the (likely) 
later version of Java. But that will still allow non-release-managers to 
build locally using potentially older versions of Java.


WDYT?

-chris

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

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?


-chris

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

Re: (tomcat) 05/05: Need for force GC to avoid duplicate clean-up (which triggers a crash)


Mark,

On 2/8/24 16:18, 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 967be0a2d5bb90a5f962359e80fe3e6a78b1ea51
Author: Mark Thomas 
AuthorDate: Thu Feb 8 21:17:24 2024 +

 Need for force GC to avoid duplicate clean-up (which triggers a crash)
---
  java/org/apache/catalina/core/AprLifecycleListener.java | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/java/org/apache/catalina/core/AprLifecycleListener.java 
b/java/org/apache/catalina/core/AprLifecycleListener.java
index da2c0e3862..974af71ba2 100644
--- a/java/org/apache/catalina/core/AprLifecycleListener.java
+++ b/java/org/apache/catalina/core/AprLifecycleListener.java
@@ -170,6 +170,8 @@ public class AprLifecycleListener implements 
LifecycleListener {
  
  private static void terminateAPR() {

  Library.terminatePrepare();
+// Need to force GC here as some components do APR clean-up in 
finalize()
+System.gc();
  AprStatus.setAprInitialized(false);
  AprStatus.setAprAvailable(false);
  fipsModeActive = false;


I'm sure you we thinking "eew gross" when you wrote this.

Is there no other way to do this with volatile flags and 
intentional-cleanup rather than ugly finalizer-based cleanup?


-chris

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

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


Mark,

On 2/8/24 16:10, ma...@apache.org wrote:

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

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

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

 Reduce changes of crash on Library shutdown with OpenSSL connections
---
  .../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);
+}


Should this be in a synchronized block? Probably using Library as the 
monitor?


Also, maybe zero everything out afterward?

Honestly, this looks weird to my (untrained) eye. You are checking the 
state of Library to determine whether or not local resources ought to be 
cleaned up? That smells funny to me...


-chris

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

Re: (tomcat) 01/02: Re-order so library isn't reported as running after it is terminated


Mark,

On 2/8/24 16:10, ma...@apache.org wrote:

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

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

commit 712f6d8a70e0e89d66cba8a7b9cc81c717ecbe7d
Author: Mark Thomas 
AuthorDate: Thu Feb 8 18:54:18 2024 +

 Re-order so library isn't reported as running after it is terminated
---
  java/org/apache/catalina/core/AprLifecycleListener.java | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/catalina/core/AprLifecycleListener.java 
b/java/org/apache/catalina/core/AprLifecycleListener.java
index 4ed37531fa..8fea80148e 100644
--- a/java/org/apache/catalina/core/AprLifecycleListener.java
+++ b/java/org/apache/catalina/core/AprLifecycleListener.java
@@ -170,11 +170,11 @@ public class AprLifecycleListener implements 
LifecycleListener {
  
  private static void terminateAPR() {

  Library.terminatePrepare();
-Library.terminate();
-AprStatus.setAprAvailable(false);
  AprStatus.setAprInitialized(false);
-sslInitialized = false; // Well we cleaned the pool in terminate.
+AprStatus.setAprAvailable(false);
  fipsModeActive = false;
+sslInitialized = false; // Well we cleaned the pool in terminate.
+Library.terminate();


Shouldn't we confirm that the library has successfully shut-down before 
setting sslInitialized = false?


-chris

-
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


Michael,

On 2/7/24 14:14, Michael Osipov wrote:

On 2024/02/07 18:19:24 Christopher Schultz wrote:

Michael,

On 2/7/24 11:05, 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

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 have just tested Tomcat 9.0.x from Git repo against:
FreeBSD 13-STABLE:
OpenSSL 1.1.1w-freebsd  11 Sep 2023
Tomcat Native library [1.3.1-dev] using APR version [1.7.3]


HP-UX 11.31:
OpenSSL 1.1.1w  11 Sep 2023
Tomcat Native library [1.3.1-dev] using APR version [1.7.4]

I will try with OpenSSL 3.0.x soon. It is very unfortunate that 9.0.x requires 
Java 17 to build, it is not available on HP-UX and will never be by HPE. I had 
to downgrade BND to 6.4.0 to make it run. I still consider this a wrong move 
for at least Tomcat 9.0.x, Java 11 should have stayed the minimum.


I think it's actually possible to build with Java 11, but the release
builds require Java 17 for  #reasons.

Try just hacking the build files to allow Java 11 and see if you can build.


It does work:
diff --git a/build.properties.default b/build.properties.default
index 2ec1dbfb16..82aec7debb 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -307 +307 @@ 
spotbugs.loc=${base-maven.loc}/com/github/spotbugs/spotbugs/${spotbugs.version}/
-bnd.version=7.0.0
+bnd.version=6.4.0
diff --git a/build.xml b/build.xml
index 94e80620e2..83852a889f 100644
--- a/build.xml
+++ b/build.xml
@@ -110 +110 @@
-  
+  


I will do some thinking about maybe only enforcing Java 17 for 
release-builds and not "normal" builds.


-chris

-
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

2024-02-07 Thread Christopher Schultz


Michael,

On 2/7/24 11:05, 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

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 have just tested Tomcat 9.0.x from Git repo against:
FreeBSD 13-STABLE:
OpenSSL 1.1.1w-freebsd  11 Sep 2023
Tomcat Native library [1.3.1-dev] using APR version [1.7.3]


HP-UX 11.31:
OpenSSL 1.1.1w  11 Sep 2023
Tomcat Native library [1.3.1-dev] using APR version [1.7.4]

I will try with OpenSSL 3.0.x soon. It is very unfortunate that 9.0.x requires 
Java 17 to build, it is not available on HP-UX and will never be by HPE. I had 
to downgrade BND to 6.4.0 to make it run. I still consider this a wrong move 
for at least Tomcat 9.0.x, Java 11 should have stayed the minimum.


I think it's actually possible to build with Java 11, but the release 
builds require Java 17 for  #reasons.


Try just hacking the build files to allow Java 11 and see if you can build.

-chris

-
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

2024-02-06 Thread Christopher Schultz

Mark,

On 2/6/24 11:44, Mark Thomas wrote:

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.

I'm not sure I would bother. Just leave 8.5.x at the current libtcnative
level.

-chris

-
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

2024-02-06 Thread Christopher Schultz


Mark,

Thanks for RMing.

On 2/5/24 15: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 ...


+1 for stable release.

Builds cleanly with (expected) deprecation warnings on MacOS x86-64 with 
Clang 12.0.5 and APR 1.7.4 and OpenSSL 3.2.0.


Unit tests pass for Tomcat 8.5.x in this environment running Java 17.

-chris

-
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

2024-02-06 Thread Christopher Schultz


Mark,

It's odd that the Java unit tests pass without any native library having 
been built. I find that confusing.


-chris

On 2/5/24 15: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

Re: Moving to Tomcat Native 1.3.x


Mark,

On 2/5/24 11:39, Mark Thomas wrote:

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.


I was thinking we'd just let 8.5.x ride on it current tcnative release. 
We only have, what... 2 more 8.5.x releases in total?


-chris

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

Thanks for RMing.

On 2/4/24 15: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 ...


+1 for stable release.

Builds with (expected) deprecation warnings on MacOS x86-64 with clang 
12.0.5, APR 1.7.4, and OpenSSL 3.2.0.


Unit tests for 10.1.x trunk pass in this configuration and environment.

-chris

-
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


All,
On 2/5/24 09:03, Christopher Schultz wrote:

Mark,

On 2/4/24 14:54, Mark Thomas wrote:
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


What about going all the way up to OpenSSL *3.x* with tcnative 1.*3.x*?

Is that too far?


- update minimum APR to 1.6.3
- remove code supporting OpenSSL < 1.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.


If anyone else is interested in dumping OpenSSL 1.x, we'd have to make 
some changes, here. I think only 10.x and 11.x could upgrade without 
ruffling a lot of feathers.


Ignore this post. OpenSSL 3.xis what tcnative 2.x is for.

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.


-chris

-
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