(tomcat-tck) 01/02: Copy certs from Tomcat unit tests for CLIENT_CERT auth tests
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-tck.git commit d00bb81ca7316a6510fc4f1336ec9c44fbb8f785 Author: Mark Thomas AuthorDate: Thu Mar 21 13:12:48 2024 + Copy certs from Tomcat unit tests for CLIENT_CERT auth tests --- servlet-tck/src/test/resources/ca.jks| Bin 0 -> 1766 bytes servlet-tck/src/test/resources/localhost-rsa.jks | Bin 0 -> 4403 bytes 2 files changed, 0 insertions(+), 0 deletions(-) diff --git a/servlet-tck/src/test/resources/ca.jks b/servlet-tck/src/test/resources/ca.jks new file mode 100644 index 000..61076e4 Binary files /dev/null and b/servlet-tck/src/test/resources/ca.jks differ diff --git a/servlet-tck/src/test/resources/localhost-rsa.jks b/servlet-tck/src/test/resources/localhost-rsa.jks new file mode 100644 index 000..918fa65 Binary files /dev/null and b/servlet-tck/src/test/resources/localhost-rsa.jks differ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat-tck) branch main updated (26ff84d -> f9e6fd9)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-tck.git from 26ff84d Remove unused imports new d00bb81 Copy certs from Tomcat unit tests for CLIENT_CERT auth tests new f9e6fd9 Get SSL tests passing The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: servlet-tck/pom.xml| 45 ++- .../tck/servlet/TomcatServletTckConfiguration.java | 132 ++--- servlet-tck/src/test/resources/ca.jks | Bin 0 -> 1766 bytes servlet-tck/src/test/resources/localhost-rsa.jks | Bin 0 -> 4403 bytes 4 files changed, 159 insertions(+), 18 deletions(-) create mode 100644 servlet-tck/src/test/resources/ca.jks create mode 100644 servlet-tck/src/test/resources/localhost-rsa.jks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat-tck) 02/02: Get SSL tests passing
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-tck.git
commit f9e6fd902c7d492c97be0895bfc7c117f05dfd0c
Author: Mark Thomas
AuthorDate: Thu Mar 21 14:15:51 2024 +
Get SSL tests passing
---
servlet-tck/pom.xml| 45 ++-
.../tck/servlet/TomcatServletTckConfiguration.java | 132 ++---
2 files changed, 159 insertions(+), 18 deletions(-)
diff --git a/servlet-tck/pom.xml b/servlet-tck/pom.xml
index 9525f09..f47abf9 100644
--- a/servlet-tck/pom.xml
+++ b/servlet-tck/pom.xml
@@ -94,23 +94,62 @@
${failsafe.plugin.version}
+http
integration-test
-verify
jakarta.servlet:tck-runtime
- **/*Test.java
- **/*Tests.java
+**/*Test.java
+**/*Tests.java
+
+**/ClientCertTests.java
+**/ClientCertAnnoTests.java
+
5
false
5
true
false
+http
+
+
target/failsafe-reports/failsafe-summary-http.xml
+
+
+
+https
+
+integration-test
+
+
+
jakarta.servlet:tck-runtime
+
+ **/ClientCertTests.java
+ **/ClientCertAnnoTests.java
+
+false
+
+5
+true
+
false
+https
+
target/failsafe-reports/failsafe-summary-https.xml
+
+
+
+verify
+
+verify
+
+
+
+
target/failsafe-reports/failsafe-summary-http.xml
+
target/failsafe-reports/failsafe-summary-https.xml
+
diff --git
a/servlet-tck/src/test/java/org/apache/tomcat/tck/servlet/TomcatServletTckConfiguration.java
b/servlet-tck/src/test/java/org/apache/tomcat/tck/servlet/TomcatServletTckConfiguration.java
index beba4d5..19c554f 100644
---
a/servlet-tck/src/test/java/org/apache/tomcat/tck/servlet/TomcatServletTckConfiguration.java
+++
b/servlet-tck/src/test/java/org/apache/tomcat/tck/servlet/TomcatServletTckConfiguration.java
@@ -16,13 +16,29 @@
*/
package org.apache.tomcat.tck.servlet;
+import java.io.File;
+import java.io.FileOutputStream;
+import java.io.InputStream;
+import java.io.OutputStream;
import java.lang.reflect.Field;
+import java.net.URL;
+import java.security.KeyStore;
+import java.security.cert.Certificate;
+import java.security.cert.X509Certificate;
+import java.util.Enumeration;
import java.util.Locale;
+import javax.net.ssl.X509TrustManager;
+
import org.apache.catalina.Container;
import org.apache.catalina.connector.Connector;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.startup.Tomcat;
+import org.apache.catalina.util.IOTools;
+import org.apache.tomcat.util.net.SSLHostConfig;
+import org.apache.tomcat.util.net.SSLHostConfigCertificate;
+import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
+
import org.jboss.arquillian.container.spi.event.container.AfterDeploy;
import org.jboss.arquillian.container.spi.event.container.AfterStart;
import org.jboss.arquillian.core.api.annotation.Observes;
@@ -45,36 +61,101 @@ public class TomcatServletTckConfiguration implements
LoadableExtension {
Field tomcatField =
Tomcat10EmbeddedContainer.class.get
Re: Observability of virtual threads
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" and therefore dumpable, etc. through existing interfaces _while they were mounted on an OS thread_ I could almost agree that makes so
[PR] Adds the possibility to change the USE_TLS_RESPONSE HTTP response [tomcat]
Leon-Schwandt opened a new pull request, #709: URL: https://github.com/apache/tomcat/pull/709 Enables the USE_TLS_RESPONSE message to be changed at a global level. A possible use case would be a redirect to HTTPS -- 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: Add default implementation to align with Servlet 6.1
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 fd25948538 Add default implementation to align with Servlet 6.1
fd25948538 is described below
commit fd25948538d424f66befde14605d75c9a221d320
Author: Mark Thomas
AuthorDate: Fri Mar 22 01:09:32 2024 +
Add default implementation to align with Servlet 6.1
---
java/jakarta/servlet/http/HttpSession.java | 4 +++-
webapps/docs/changelog.xml | 4
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/java/jakarta/servlet/http/HttpSession.java
b/java/jakarta/servlet/http/HttpSession.java
index ccd055c8c5..963e4e4d97 100644
--- a/java/jakarta/servlet/http/HttpSession.java
+++ b/java/jakarta/servlet/http/HttpSession.java
@@ -229,5 +229,7 @@ public interface HttpSession {
*
* @throws IllegalStateException if this method is called on an invalid
session
*/
-Accessor getAccessor();
+default Accessor getAccessor() {
+return null;
+}
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 78bc1f2619..341c3a6596 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -124,6 +124,10 @@
NullPointerException, if an attempt is made to use the
AsyncContext after it has been recycled. (markt)
+
+Add a default implementation for HttpSession.getAccessor()
+to align with the Servlet 6.1 API. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Restore @SuppressWarnings - it is needed when using Java 22
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 511c4e209a Restore @SuppressWarnings - it is needed when using Java 22
511c4e209a is described below
commit 511c4e209a84af09e62369c1646004a774c9f94a
Author: Mark Thomas
AuthorDate: Tue Mar 19 11:01:30 2024 +
Restore @SuppressWarnings - it is needed when using Java 22
---
java/org/apache/tomcat/util/net/AbstractEndpoint.java | 1 +
1 file changed, 1 insertion(+)
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index b63a493c27..2c8a77ddd2 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -1240,6 +1240,7 @@ public abstract class AbstractEndpoint {
this.executor = null;
if (executor instanceof ThreadPoolExecutor) {
//this is our internal one, so we need to shut it down
+@SuppressWarnings("resource")
ThreadPoolExecutor tpe = (ThreadPoolExecutor) executor;
tpe.shutdownNow();
long timeout = getExecutorTerminationTimeoutMillis();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
