[Bug 66207] StringManager#getManager(String, Enumeration) cannot return the correct value
https://bz.apache.org/bugzilla/show_bug.cgi?id=66207 --- Comment #3 from HanLi --- It's not a bug, so close it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tcnative crashes during shutdown (TC 10.x unit tests)
On 19/07/2022 23:16, Rainer Jung wrote: Roughly the same pattern I saw for TC 10.0 now also seen for TC 10.1. A failure rate of 1 in 50 is going to make any testing a relatively slow process. We are going to need at least 250 test runs to get a reasonable degree of certainty in the results. I agree that it seems likely that the Connector shutdown code isn't 100% robust. I took a quick look and cleanup seems to be triggered by GC which should avoid these sorts of issues. This one may take a while to track down. Did you have any success in narrowing down the scope of the tests while still reproducing the issue? Mark Am 18.07.2022 um 12:09 schrieb Rainer Jung: Hi there, this is just an info, at this point probably not a showstopper. The topic is crashes in tcnative 1.2 and 2.0 for TC 10.0 during shutdown after TLS unit tests. Details: I ran the TC unit tests for latest 9.x, 10.x and 10.1.x with tcnative 1.2.35 OpenSSL 1.1.1q, 1.2.35 OpenSSL 3.0.2 and 2.0.1 OpenSSL 3.0.2. I ran the test for a variety of OpenJDK builds (Adoptium, Zulu, Oracle, RedHat) and versions (latest 1.8.0 except for 10.1, 11, 17 and current 19). The platforms where SLES 11, 12 and 15 and RHEL 6, 7 and 8. For RHEL 7 and 8 there were 48 runs, for the other platforms 39 (no RedHat JDK). I only ran about 150 test classes (for NIO and also for NIO2), because I also ran the full unit tests (about 450 classes) for JSSE and didn't want to rerun all tests for time and efficiency reasons. For TC 10 I observed crashes in TLS tests during shutdown: Out of the roughly 250 test runs, 5 produced such a crash. For TC 9 I did not observe a single one. Tests for TC 10.1 are ongoing, until now no crash, but it is a bit early for a final result. I think the crashes are not new. All hapened in the TLS tests in org.apache.tomcat.util.net. The list of crashes I saw for TC 10.0.23: RHEL7 jdk1.8.0 tcnative 1.2.35 OpenSSL 3.0.2 org.apache.tomcat.util.net.TestSsl FAILED (crashed) openjdk version "1.8.0_332-ea" OpenJDK Runtime Environment (build 1.8.0_332-ea-b06) OpenJDK 64-Bit Server VM (build 25.332-b06, mixed mode) double free or corruption (!prev): 0x7f473c19df50 === Backtrace: = /lib64/libc.so.6(+0x7d56d)[0x7f4742aa456d] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f472871923d] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x30)[0x7f4728719c10] [0x7f472d018427] RHEL7 jdk17 tcnative 1.2.35 OpenSSL 1.1.1q org.apache.tomcat.util.net.TestCustomSslTrustManager FAILED (crashed) openjdk version "17.0.2" 2022-01-18 OpenJDK Runtime Environment (build 17.0.2+8-86) OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing) corrupted double-linked list: 0x7f6bb8001d10 === Backtrace: = /lib64/libc.so.6(+0x7bfc7)[0x7f6bf481dfc7] /lib64/libc.so.6(+0x7d774)[0x7f6bf481f774] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f6bc543223d] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x30)[0x7f6bc5432c10] [0x7f6bd572249a] SLES11 oracle_jdk1.8.0 tcnative 2.0.1 OpenSSL 3.0.2 org.apache.tomcat.util.net.TestSsl FAILED (crashed) java version "1.8.0_331" Java(TM) SE Runtime Environment (build 1.8.0_331-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode) double free or corruption (!prev): 0x7fbf88c1de10 === Backtrace: = /lib64/libc.so.6(+0x75018)[0x7fbf87b35018] /lib64/libc.so.6(cfree+0x6c)[0x7fbf87b39f6c] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7fbf718a5aad] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x34)[0x7fbf718a66f4] [0x7fbf770264a7] SLES11 jdk11 tcnative 1.2.35 OpenSSL 1.1.1q org.apache.tomcat.util.net.TestSsl FAILED (crashed) openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment 18.9 (build 11.0.15+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.15+10, mixed mode) double free or corruption (!prev): 0x7f4f6bb93040 === Backtrace: = /lib64/libc.so.6(+0x75018)[0x7f4f6a171018] /lib64/libc.so.6(cfree+0x6c)[0x7f4f6a175f6c] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f4f49403aad] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x34)[0x7f4f494046f4] [0x7f4f508b88b0] RHEL 8 Adoptium jdk11 tcnative 1.2.35 OpenSSL 1.1.1q Test org.apache.tomcat.util.net.TestClientCert FAILED (crashed) Since they are rare and happen in various tests and version combinations, it seems the general shutdown behavior w.r.t. the library is not yet perfect. Once the tests for 10.1 complete, I will see, whether I can force the crashes more often by focusing on the TLS tests in org.apache.tomcat.util.net. Best regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional comman
[Bug 66210] Some unit tests are failing on a non-English PC
https://bz.apache.org/bugzilla/show_bug.cgi?id=66210 --- Comment #3 from Mark Thomas --- I think we have a number of options here: 1. (Similar to my previous 'fixes') reduce the text tested to that which doesn't change depending on locale. 2. Force the unit tests to run under en-US. 3. Use StringManager to retrieve the expected txt in the current locale and then compare the actual output to the locale specific expected text. My concern with 1 is that sometimes we may skip testing parts of the output that are relevant and miss bugs as a result. Option 2 is sufficient to test the functionality primarily being tested whereas option 3 (sort of) tests some of the i18n as well. I'm leaning towards option 3 as it doesn't look too challenging to implement for the small number of test cases where this is an issue. We do need to make sure we distinguish between the system locale and the locale we expected to be used for the response. Thoughts? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66209] CPU regression when classpath Bloom filters are active
https://bz.apache.org/bugzilla/show_bug.cgi?id=66209 --- Comment #1 from Mark Thomas --- This patch essentially trades memory for performance. We have some users that won't want to make that trade - even if the memory concerned is relatively small. Given the competing demands here, I think we need to find a way to make this configurable. Whether that is by expanding useBloomFilterForArchives beyond a simple boolean, by tweaking the background processing frequency or by a new configuration option is TBD. I want to mull this over a little bit before making any changes. Thoughts? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66196] HTTP/1 connector doesn't blow-up when HTTP header contains non-ASCII characters
https://bz.apache.org/bugzilla/show_bug.cgi?id=66196 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Mark Thomas --- Which header was this? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66196] HTTP/1 connector doesn't blow-up when HTTP header contains non-ASCII characters
https://bz.apache.org/bugzilla/show_bug.cgi?id=66196 --- Comment #2 from Boris Petrov --- Well, in my case it was the `ETag` header but I believe it's illegal to send non-ASCII characters in any header. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf closed pull request #534: Issue 66195 observe mr jar system property
markt-asf closed pull request #534: Issue 66195 observe mr jar system property URL: https://github.com/apache/tomcat/pull/534 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf commented on pull request #534: Issue 66195 observe mr jar system property
markt-asf commented on PR #534: URL: https://github.com/apache/tomcat/pull/534#issuecomment-1214871231 The sync block won't be reached: https://github.com/openjdk/jdk/blob/jdk-11%2B28/src/java.base/share/classes/java/util/jar/JarFile.java#L382 The case hasn't been made that this change is necessary nor has any evidence been provided of a genuine performance improvement. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66195] Observe multi-release JAR system property from JVM if available via system properties
https://bz.apache.org/bugzilla/show_bug.cgi?id=66195 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Mark Thomas --- The case hasn't been made that this change is necessary nor has any evidence been provided of a genuine performance improvement. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66194] When using http2 and maxHeaderSize is exceeded, nothing is logged
https://bz.apache.org/bugzilla/show_bug.cgi?id=66194 --- Comment #1 from Mark Thomas --- Logging every instance of this opens up the potential for a DoS. We can look at the possibility of mirroring the logging used for HTTP/1.1 which logs via a UserDataHelper instance. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66194] When using http2 and maxHeaderSize is exceeded, nothing is logged
https://bz.apache.org/bugzilla/show_bug.cgi?id=66194 --- Comment #2 from damien.hol...@unimarket.com --- Logging at least the first instance would be much more helpful than the current situation. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66210] Some unit tests are failing on a non-English PC
https://bz.apache.org/bugzilla/show_bug.cgi?id=66210 --- Comment #4 from Han Li --- (In reply to Mark Thomas from comment #3) > Option 2 is sufficient to test the functionality primarily being tested > whereas option 3 (sort of) tests some of the i18n as well. Agreed! I also think that option 3 is the best solution. > I'm leaning towards option 3 as it doesn't look too challenging to implement > for > the small number of test cases where this is an issue. It's not too difficult to implement, and i found that the only trouble is that we may need to process the parameters in the text via regular expressions (we may not get the parameters, e.g. connectionId). So i will refix the problematic unit tests (include previous PR) according to option 3, is that OK? Han -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66209] CPU regression when classpath Bloom filters are active
https://bz.apache.org/bugzilla/show_bug.cgi?id=66209 --- Comment #2 from John Engebretson --- I had a hand in the original implementation, and the intent was always to create the Bloom filters once and keep them around forever. In our internal implementation (Tomcat 8) we did exactly that. Relative to the intent, this is a bug. However, you have a valid point that the current state may be acceptable for some users, and changing it could cause challenges. FWIW the memory footprint is quite small - we saw ~1.5MB of heap to accommodate ~4000 jars. I'll defer to your judgment. Adding another configuration parameter is certainly doable. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66210] Some unit tests are failing on a non-English PC
https://bz.apache.org/bugzilla/show_bug.cgi?id=66210 --- Comment #5 from Mark Thomas --- Sounds great. Thanks. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66196] HTTP/1 connector doesn't blow-up when HTTP header contains non-ASCII characters
https://bz.apache.org/bugzilla/show_bug.cgi?id=66196 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #3 from Mark Thomas --- Generally, Tomcat doesn't validate response headers unless it needs to process them for some reason. Applications are expected to set valid data. This also gives applications the flexibility to bend (or even break) the HTTP specs which can sometimes be useful when dealing with clients that don't follow the specs. HTTP headers values are not restricted to US-ASCII. Many - including ETag - allow obs-text which is bytes in the range 0x80 to 0xFF. That said, RFC 9110 has a strong preference for US-ASCII. I suspect that requirement may get stronger over time. To add to the "fun" some cookies - despite RFC 6265 and the HTTP RFCs - have been observed to use UTF-8 values. And then there is RFC 8187 that I don't think I have ever seen in real world usage. So, in short, things are not at all clear cut. For HTTP/2, it will depend whether the implementation decides to use Huffman encoding or not. The specification doesn't define when to use Huffman and when not. You could argue that this imposes a requirement that the characters in header names and values must fall in the range 0x00 to 0xFF (other requirements limit this further). Which is stricter than HTTP/1.1. My thinking at this point was whether or not it was practical to add a similar limit to HTTP/1.1. Reviewing the code, I think it is. Only cookie headers are treated as UTF-8. All other headers are treated as ISO-8859-1. If you try passing in a String that uses characters above code point 255, they will get corrupted. On that basis, I think it is better to trigger an error early rather than passing corrupted data to the client. Triggering an error in the form of an exception problematic. Applications that appear to work at the moment would start failing once this change was applied. I think a reasonable compromise for HTTP/1.1 would be to log a warning (including the problematic String) and ignore the header. Thoughts? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf merged pull request #533: [Bug 66184] Ensure that all root loggers have a level or parent
markt-asf merged PR #533: URL: https://github.com/apache/tomcat/pull/533 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: [Bug 66184] Ensure that all root loggers have a level or parent
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new d54295e2d8 [Bug 66184] Ensure that all root loggers have a level or
parent
d54295e2d8 is described below
commit d54295e2d87650d654da1c2f9800104c39bbbfb6
Author: Piotr P. Karwasz
AuthorDate: Thu Jul 28 21:04:22 2022 +0200
[Bug 66184] Ensure that all root loggers have a level or parent
Since Java 8 the default level of a root logger is no longer set in the
constructor. This PR sets the level to INFO (LogManager's default) if it
is absent.
---
java/org/apache/juli/ClassLoaderLogManager.java| 4 ++
.../org/apache/juli/TestClassLoaderLogManager.java | 61 ++
2 files changed, 65 insertions(+)
diff --git a/java/org/apache/juli/ClassLoaderLogManager.java
b/java/org/apache/juli/ClassLoaderLogManager.java
index fc5106795e..b4ab262601 100644
--- a/java/org/apache/juli/ClassLoaderLogManager.java
+++ b/java/org/apache/juli/ClassLoaderLogManager.java
@@ -512,6 +512,10 @@ public class ClassLoaderLogManager extends LogManager {
if (is != null) {
readConfiguration(is, classLoader);
}
+
+if (localRootLogger.getParent() == null && localRootLogger.getLevel()
== null) {
+localRootLogger.setLevel(Level.INFO);
+}
try {
// Use a ThreadLocal to work around
// https://bugs.openjdk.java.net/browse/JDK-8195096
diff --git a/test/org/apache/juli/TestClassLoaderLogManager.java
b/test/org/apache/juli/TestClassLoaderLogManager.java
index 641a52b936..524a4b86f4 100644
--- a/test/org/apache/juli/TestClassLoaderLogManager.java
+++ b/test/org/apache/juli/TestClassLoaderLogManager.java
@@ -16,9 +16,17 @@
*/
package org.apache.juli;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertNotNull;
+import static org.junit.Assert.assertNull;
+
+import java.io.ByteArrayInputStream;
import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
import java.util.Collections;
import java.util.Random;
+import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.Logger;
@@ -30,6 +38,8 @@ import org.junit.Test;
*/
public class TestClassLoaderLogManager {
+private static final byte[] EMPTY_BYTES = {};
+
@Test
public void testReplace() {
ClassLoaderLogManager logManager = new ClassLoaderLogManager();
@@ -81,6 +91,26 @@ public class TestClassLoaderLogManager {
listThread.setRunning(false);
}
+/**
+ * Tests if a per-app root logger has a not {@code null} level.
+ */
+@Test
+public void testBug66184() throws IOException {
+final ClassLoader cl = new TestClassLoader();
+final ClassLoader oldCL =
Thread.currentThread().getContextClassLoader();
+try {
+Thread.currentThread().setContextClassLoader(cl);
+final ClassLoaderLogManager logManager = new
ClassLoaderLogManager();
+logManager.readConfiguration();
+final Logger rootLogger = logManager.getLogger("");
+assertNotNull("root logger is null", rootLogger);
+assertNull("root logger has a parent", rootLogger.getParent());
+assertEquals(Level.INFO, rootLogger.getLevel());
+} finally {
+Thread.currentThread().setContextClassLoader(oldCL);
+}
+}
+
private static class LoggerCreateThread extends Thread {
private final LogManager logManager;
@@ -133,4 +163,35 @@ public class TestClassLoaderLogManager {
this.running = running;
}
}
+
+private static class TestClassLoader extends ClassLoader implements
WebappProperties {
+
+@Override
+public String getWebappName() {
+return "webapp";
+}
+
+@Override
+public String getHostName() {
+return "localhost";
+}
+
+@Override
+public String getServiceName() {
+return "Catalina";
+}
+
+@Override
+public boolean hasLoggingConfig() {
+return true;
+}
+
+@Override
+public InputStream getResourceAsStream(final String resource) {
+if ("logging.properties".equals(resource)) {
+return new ByteArrayInputStream(EMPTY_BYTES);
+}
+return null;
+}
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf commented on pull request #533: [Bug 66184] Ensure that all root loggers have a level or parent
markt-asf commented on PR #533: URL: https://github.com/apache/tomcat/pull/533#issuecomment-1216008668 Thanks for the bug report and PR. I just want to clean up a few minor points (e.g. add a change log entry) and then I'll back-port this. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Follow-up to #533
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 46d7162237 Follow-up to #533
46d7162237 is described below
commit 46d7162237352f97b98d44123d293529c34ed7bb
Author: Mark Thomas
AuthorDate: Tue Aug 16 01:36:54 2022 +0100
Follow-up to #533
---
test/org/apache/juli/TestClassLoaderLogManager.java | 10 +++---
webapps/docs/changelog.xml | 5 +
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/test/org/apache/juli/TestClassLoaderLogManager.java
b/test/org/apache/juli/TestClassLoaderLogManager.java
index 524a4b86f4..8628deac16 100644
--- a/test/org/apache/juli/TestClassLoaderLogManager.java
+++ b/test/org/apache/juli/TestClassLoaderLogManager.java
@@ -16,10 +16,6 @@
*/
package org.apache.juli;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertNotNull;
-import static org.junit.Assert.assertNull;
-
import java.io.ByteArrayInputStream;
import java.io.File;
import java.io.IOException;
@@ -103,9 +99,9 @@ public class TestClassLoaderLogManager {
final ClassLoaderLogManager logManager = new
ClassLoaderLogManager();
logManager.readConfiguration();
final Logger rootLogger = logManager.getLogger("");
-assertNotNull("root logger is null", rootLogger);
-assertNull("root logger has a parent", rootLogger.getParent());
-assertEquals(Level.INFO, rootLogger.getLevel());
+Assert.assertNotNull("root logger is null", rootLogger);
+Assert.assertNull("root logger has a parent",
rootLogger.getParent());
+Assert.assertEquals(Level.INFO, rootLogger.getLevel());
} finally {
Thread.currentThread().setContextClassLoader(oldCL);
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 84e11ec9b2..baebf6c075 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -128,6 +128,11 @@
MemoryUserDatabase.save(). Deprecate and discontinue use of MemoryUser,
MemoryRole, and MemoryGroup classes. (schultz)
+
+66184: Ensure that JULI root loggers have a default level of
+INFO. Pull request 533 provided by Piotr P.
+Karwasz. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.0.x updated: [Bug 66184] Ensure that all root loggers have a level or parent
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new e5a5122d2b [Bug 66184] Ensure that all root loggers have a level or
parent
e5a5122d2b is described below
commit e5a5122d2b7dfe5c49e8a74367cb9c17f10e3329
Author: Piotr P. Karwasz
AuthorDate: Thu Jul 28 21:04:22 2022 +0200
[Bug 66184] Ensure that all root loggers have a level or parent
Since Java 8 the default level of a root logger is no longer set in the
constructor. This PR sets the level to INFO (LogManager's default) if it
is absent.
---
java/org/apache/juli/ClassLoaderLogManager.java| 4 ++
.../org/apache/juli/TestClassLoaderLogManager.java | 57 ++
webapps/docs/changelog.xml | 5 ++
3 files changed, 66 insertions(+)
diff --git a/java/org/apache/juli/ClassLoaderLogManager.java
b/java/org/apache/juli/ClassLoaderLogManager.java
index b290972ec8..7ab5f4a3f4 100644
--- a/java/org/apache/juli/ClassLoaderLogManager.java
+++ b/java/org/apache/juli/ClassLoaderLogManager.java
@@ -525,6 +525,10 @@ public class ClassLoaderLogManager extends LogManager {
if (is != null) {
readConfiguration(is, classLoader);
}
+
+if (localRootLogger.getParent() == null && localRootLogger.getLevel()
== null) {
+localRootLogger.setLevel(Level.INFO);
+}
try {
// Use a ThreadLocal to work around
// https://bugs.openjdk.java.net/browse/JDK-8195096
diff --git a/test/org/apache/juli/TestClassLoaderLogManager.java
b/test/org/apache/juli/TestClassLoaderLogManager.java
index 641a52b936..8628deac16 100644
--- a/test/org/apache/juli/TestClassLoaderLogManager.java
+++ b/test/org/apache/juli/TestClassLoaderLogManager.java
@@ -16,9 +16,13 @@
*/
package org.apache.juli;
+import java.io.ByteArrayInputStream;
import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
import java.util.Collections;
import java.util.Random;
+import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.Logger;
@@ -30,6 +34,8 @@ import org.junit.Test;
*/
public class TestClassLoaderLogManager {
+private static final byte[] EMPTY_BYTES = {};
+
@Test
public void testReplace() {
ClassLoaderLogManager logManager = new ClassLoaderLogManager();
@@ -81,6 +87,26 @@ public class TestClassLoaderLogManager {
listThread.setRunning(false);
}
+/**
+ * Tests if a per-app root logger has a not {@code null} level.
+ */
+@Test
+public void testBug66184() throws IOException {
+final ClassLoader cl = new TestClassLoader();
+final ClassLoader oldCL =
Thread.currentThread().getContextClassLoader();
+try {
+Thread.currentThread().setContextClassLoader(cl);
+final ClassLoaderLogManager logManager = new
ClassLoaderLogManager();
+logManager.readConfiguration();
+final Logger rootLogger = logManager.getLogger("");
+Assert.assertNotNull("root logger is null", rootLogger);
+Assert.assertNull("root logger has a parent",
rootLogger.getParent());
+Assert.assertEquals(Level.INFO, rootLogger.getLevel());
+} finally {
+Thread.currentThread().setContextClassLoader(oldCL);
+}
+}
+
private static class LoggerCreateThread extends Thread {
private final LogManager logManager;
@@ -133,4 +159,35 @@ public class TestClassLoaderLogManager {
this.running = running;
}
}
+
+private static class TestClassLoader extends ClassLoader implements
WebappProperties {
+
+@Override
+public String getWebappName() {
+return "webapp";
+}
+
+@Override
+public String getHostName() {
+return "localhost";
+}
+
+@Override
+public String getServiceName() {
+return "Catalina";
+}
+
+@Override
+public boolean hasLoggingConfig() {
+return true;
+}
+
+@Override
+public InputStream getResourceAsStream(final String resource) {
+if ("logging.properties".equals(resource)) {
+return new ByteArrayInputStream(EMPTY_BYTES);
+}
+return null;
+}
+}
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index c1726e38d0..f13e29fafd 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -128,6 +128,11 @@
MemoryUserDatabase.save(). Deprecate and discontinue use of MemoryUser,
MemoryRole, and MemoryGroup classes. (schultz)
+
+66184: Ensure that JULI root loggers have a default level of
+INFO. Pull request 533 provided b
[tomcat] branch 9.0.x updated: [Bug 66184] Ensure that all root loggers have a level or parent
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
The following commit(s) were added to refs/heads/9.0.x by this push:
new 9c9dc83e5a [Bug 66184] Ensure that all root loggers have a level or
parent
9c9dc83e5a is described below
commit 9c9dc83e5a1f7d129f664a429a4787c76d8afd77
Author: Piotr P. Karwasz
AuthorDate: Thu Jul 28 21:04:22 2022 +0200
[Bug 66184] Ensure that all root loggers have a level or parent
Since Java 8 the default level of a root logger is no longer set in the
constructor. This PR sets the level to INFO (LogManager's default) if it
is absent.
---
java/org/apache/juli/ClassLoaderLogManager.java| 4 ++
.../org/apache/juli/TestClassLoaderLogManager.java | 57 ++
webapps/docs/changelog.xml | 5 ++
3 files changed, 66 insertions(+)
diff --git a/java/org/apache/juli/ClassLoaderLogManager.java
b/java/org/apache/juli/ClassLoaderLogManager.java
index b290972ec8..7ab5f4a3f4 100644
--- a/java/org/apache/juli/ClassLoaderLogManager.java
+++ b/java/org/apache/juli/ClassLoaderLogManager.java
@@ -525,6 +525,10 @@ public class ClassLoaderLogManager extends LogManager {
if (is != null) {
readConfiguration(is, classLoader);
}
+
+if (localRootLogger.getParent() == null && localRootLogger.getLevel()
== null) {
+localRootLogger.setLevel(Level.INFO);
+}
try {
// Use a ThreadLocal to work around
// https://bugs.openjdk.java.net/browse/JDK-8195096
diff --git a/test/org/apache/juli/TestClassLoaderLogManager.java
b/test/org/apache/juli/TestClassLoaderLogManager.java
index 641a52b936..8628deac16 100644
--- a/test/org/apache/juli/TestClassLoaderLogManager.java
+++ b/test/org/apache/juli/TestClassLoaderLogManager.java
@@ -16,9 +16,13 @@
*/
package org.apache.juli;
+import java.io.ByteArrayInputStream;
import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
import java.util.Collections;
import java.util.Random;
+import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.Logger;
@@ -30,6 +34,8 @@ import org.junit.Test;
*/
public class TestClassLoaderLogManager {
+private static final byte[] EMPTY_BYTES = {};
+
@Test
public void testReplace() {
ClassLoaderLogManager logManager = new ClassLoaderLogManager();
@@ -81,6 +87,26 @@ public class TestClassLoaderLogManager {
listThread.setRunning(false);
}
+/**
+ * Tests if a per-app root logger has a not {@code null} level.
+ */
+@Test
+public void testBug66184() throws IOException {
+final ClassLoader cl = new TestClassLoader();
+final ClassLoader oldCL =
Thread.currentThread().getContextClassLoader();
+try {
+Thread.currentThread().setContextClassLoader(cl);
+final ClassLoaderLogManager logManager = new
ClassLoaderLogManager();
+logManager.readConfiguration();
+final Logger rootLogger = logManager.getLogger("");
+Assert.assertNotNull("root logger is null", rootLogger);
+Assert.assertNull("root logger has a parent",
rootLogger.getParent());
+Assert.assertEquals(Level.INFO, rootLogger.getLevel());
+} finally {
+Thread.currentThread().setContextClassLoader(oldCL);
+}
+}
+
private static class LoggerCreateThread extends Thread {
private final LogManager logManager;
@@ -133,4 +159,35 @@ public class TestClassLoaderLogManager {
this.running = running;
}
}
+
+private static class TestClassLoader extends ClassLoader implements
WebappProperties {
+
+@Override
+public String getWebappName() {
+return "webapp";
+}
+
+@Override
+public String getHostName() {
+return "localhost";
+}
+
+@Override
+public String getServiceName() {
+return "Catalina";
+}
+
+@Override
+public boolean hasLoggingConfig() {
+return true;
+}
+
+@Override
+public InputStream getResourceAsStream(final String resource) {
+if ("logging.properties".equals(resource)) {
+return new ByteArrayInputStream(EMPTY_BYTES);
+}
+return null;
+}
+}
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index f2f3f6fde6..38168a5e34 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -128,6 +128,11 @@
MemoryUserDatabase.save(). Deprecate and discontinue use of MemoryUser,
MemoryRole, and MemoryGroup classes. (schultz)
+
+66184: Ensure that JULI root loggers have a default level of
+INFO. Pull request 533 provided by
[tomcat] branch 8.5.x updated: [Bug 66184] Ensure that all root loggers have a level or parent
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 55067d1ff1 [Bug 66184] Ensure that all root loggers have a level or
parent
55067d1ff1 is described below
commit 55067d1ff1f37cbac297f1391c7b861ff0162c97
Author: Piotr P. Karwasz
AuthorDate: Thu Jul 28 21:04:22 2022 +0200
[Bug 66184] Ensure that all root loggers have a level or parent
Since Java 8 the default level of a root logger is no longer set in the
constructor. This PR sets the level to INFO (LogManager's default) if it
is absent.
---
java/org/apache/juli/ClassLoaderLogManager.java| 4 ++
.../org/apache/juli/TestClassLoaderLogManager.java | 57 ++
webapps/docs/changelog.xml | 9
3 files changed, 70 insertions(+)
diff --git a/java/org/apache/juli/ClassLoaderLogManager.java
b/java/org/apache/juli/ClassLoaderLogManager.java
index 2243e5703e..53f99f50f1 100644
--- a/java/org/apache/juli/ClassLoaderLogManager.java
+++ b/java/org/apache/juli/ClassLoaderLogManager.java
@@ -536,6 +536,10 @@ public class ClassLoaderLogManager extends LogManager {
if (is != null) {
readConfiguration(is, classLoader);
}
+
+if (localRootLogger.getParent() == null && localRootLogger.getLevel()
== null) {
+localRootLogger.setLevel(Level.INFO);
+}
try {
// Use a ThreadLocal to work around
// https://bugs.openjdk.java.net/browse/JDK-8195096
diff --git a/test/org/apache/juli/TestClassLoaderLogManager.java
b/test/org/apache/juli/TestClassLoaderLogManager.java
index 641a52b936..8628deac16 100644
--- a/test/org/apache/juli/TestClassLoaderLogManager.java
+++ b/test/org/apache/juli/TestClassLoaderLogManager.java
@@ -16,9 +16,13 @@
*/
package org.apache.juli;
+import java.io.ByteArrayInputStream;
import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
import java.util.Collections;
import java.util.Random;
+import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.Logger;
@@ -30,6 +34,8 @@ import org.junit.Test;
*/
public class TestClassLoaderLogManager {
+private static final byte[] EMPTY_BYTES = {};
+
@Test
public void testReplace() {
ClassLoaderLogManager logManager = new ClassLoaderLogManager();
@@ -81,6 +87,26 @@ public class TestClassLoaderLogManager {
listThread.setRunning(false);
}
+/**
+ * Tests if a per-app root logger has a not {@code null} level.
+ */
+@Test
+public void testBug66184() throws IOException {
+final ClassLoader cl = new TestClassLoader();
+final ClassLoader oldCL =
Thread.currentThread().getContextClassLoader();
+try {
+Thread.currentThread().setContextClassLoader(cl);
+final ClassLoaderLogManager logManager = new
ClassLoaderLogManager();
+logManager.readConfiguration();
+final Logger rootLogger = logManager.getLogger("");
+Assert.assertNotNull("root logger is null", rootLogger);
+Assert.assertNull("root logger has a parent",
rootLogger.getParent());
+Assert.assertEquals(Level.INFO, rootLogger.getLevel());
+} finally {
+Thread.currentThread().setContextClassLoader(oldCL);
+}
+}
+
private static class LoggerCreateThread extends Thread {
private final LogManager logManager;
@@ -133,4 +159,35 @@ public class TestClassLoaderLogManager {
this.running = running;
}
}
+
+private static class TestClassLoader extends ClassLoader implements
WebappProperties {
+
+@Override
+public String getWebappName() {
+return "webapp";
+}
+
+@Override
+public String getHostName() {
+return "localhost";
+}
+
+@Override
+public String getServiceName() {
+return "Catalina";
+}
+
+@Override
+public boolean hasLoggingConfig() {
+return true;
+}
+
+@Override
+public InputStream getResourceAsStream(final String resource) {
+if ("logging.properties".equals(resource)) {
+return new ByteArrayInputStream(EMPTY_BYTES);
+}
+return null;
+}
+}
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 03ac1895c5..80de61c8e3 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,15 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+66184: Ensure that JULI root loggers have a default level of
+INFO. Pull request 533 provided by Piotr P.
+Karwasz. (markt)
+
+
+
-
[Bug 66184] Null root logger level on Java 8
https://bz.apache.org/bugzilla/show_bug.cgi?id=66184 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEEDINFO|RESOLVED --- Comment #3 from Mark Thomas --- Thanks for the bug report and the PR. This has been fixed in: - 10.1.x for 10.1.0-M18 onwards - 10.0.x for 10.0.24 onwards - 9.0.x for 9.0.66 onwards - 8.5.x for 8.5.83 onwards -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Align IDE configuration with current dependency versions
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/8.5.x by this push: new ad54dc88e6 Align IDE configuration with current dependency versions ad54dc88e6 is described below commit ad54dc88e6222eb1c9c655863618371ba9a38af8 Author: Mark Thomas AuthorDate: Tue Aug 16 02:14:37 2022 +0100 Align IDE configuration with current dependency versions --- res/ide-support/eclipse/eclipse.classpath | 4 ++-- res/ide-support/idea/tomcat.iml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/res/ide-support/eclipse/eclipse.classpath b/res/ide-support/eclipse/eclipse.classpath index 7187042a31..5fca2947f3 100644 --- a/res/ide-support/eclipse/eclipse.classpath +++ b/res/ide-support/eclipse/eclipse.classpath @@ -25,10 +25,10 @@ - + - + diff --git a/res/ide-support/idea/tomcat.iml b/res/ide-support/idea/tomcat.iml index 2e8383bacc..747f7deec8 100644 --- a/res/ide-support/idea/tomcat.iml +++ b/res/ide-support/idea/tomcat.iml @@ -104,7 +104,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] aooohan commented on pull request #537: Bugfix for 66210 - Some unit tests are failing on a non-English PC
aooohan commented on PR #537: URL: https://github.com/apache/tomcat/pull/537#issuecomment-1216053591 Will be refix according to option 3, so close this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] aooohan closed pull request #537: Bugfix for 66210 - Some unit tests are failing on a non-English PC
aooohan closed pull request #537: Bugfix for 66210 - Some unit tests are failing on a non-English PC URL: https://github.com/apache/tomcat/pull/537 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66179] NPE when retrieving locale from request
https://bz.apache.org/bugzilla/show_bug.cgi?id=66179 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #5 from Mark Thomas --- I've reviewed the Tomcat code and I can't see a code path where a header name could be null. We either need a test case that reproduces this issue or to identify something in the application that triggers it. Can you provide the source for com.my.core.js.monitoring.tomcat.valve.RequestTracingValve please. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66183] AccessLogValve - %{xxx}c should output the value of all cookies with the same name
https://bz.apache.org/bugzilla/show_bug.cgi?id=66183 --- Comment #2 from Mark Thomas --- I agree that this needs to be fixed. Your plan sounds reasonable to me. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf merged pull request #540: Fix typo
markt-asf merged PR #540: URL: https://github.com/apache/tomcat/pull/540 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf commented on pull request #540: Fix typo
markt-asf commented on PR #540: URL: https://github.com/apache/tomcat/pull/540#issuecomment-1216130168 Thanks for the PR. Back-ported to all other supported branches. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf merged pull request #538: Fix typo
markt-asf merged PR #538: URL: https://github.com/apache/tomcat/pull/538 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf commented on pull request #538: Fix typo
markt-asf commented on PR #538: URL: https://github.com/apache/tomcat/pull/538#issuecomment-1216134107 Thanks for the PR. Back-ported to 10.0.x. (9.0.x and earlier does not have the affected code.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66183] AccessLogValve - %{xxx}c should output the value of all cookies with the same name
https://bz.apache.org/bugzilla/show_bug.cgi?id=66183 --- Comment #3 from Han Li --- (In reply to Mark Thomas from comment #2) > I agree that this needs to be fixed. Your plan sounds reasonable to me. Ok, I'll go ahead and fix this bug today. Thanks Mark! Han -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66183] AccessLogValve - %{xxx}c should output the value of all cookies with the same name
https://bz.apache.org/bugzilla/show_bug.cgi?id=66183 --- Comment #4 from Han Li --- There is also this problem in Extended Access Log Valve. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] aooohan opened a new pull request, #541: Bugfix for 66183 - AccessLogValve - %{xxx}c should output the value of all cookies with the same name
aooohan opened a new pull request, #541: URL: https://github.com/apache/tomcat/pull/541 Fix [BZ66183](https://bz.apache.org/bugzilla/show_bug.cgi?id=66183) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66183] AccessLogValve - %{xxx}c should output the value of all cookies with the same name
https://bz.apache.org/bugzilla/show_bug.cgi?id=66183 --- Comment #5 from Han Li --- PR: https://github.com/apache/tomcat/pull/541 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66196] HTTP/1 connector doesn't blow-up when HTTP header contains non-ASCII characters
https://bz.apache.org/bugzilla/show_bug.cgi?id=66196 --- Comment #4 from Boris Petrov --- Logging a warning (or even logging at the ERROR level) sounds great to me. Everyone should be monitoring their logs for warnings and errors so this should be visible to most. And would save people time as they won't have to debug to try to figure out what their problem is. Thanks! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
