Re: [PR] Fix ide-support for idea [tomcat]
isapir commented on PR #731: URL: https://github.com/apache/tomcat/pull/731#issuecomment-2159528473 Thank you for your input on this @markt-asf - it makes sense to me, and is consistent with my proposed solution. > - Eclipse is configured to use the same Java version as the build (Java 22 in this case) This is what we have now. The reason that it is not working "out of the box" is that we also need to enable "Experimental" or "Preview" features as the FFM is not enabled in Java 22 by default, and should be enabled with a switch. I added that to the project at https://github.com/apache/tomcat/commit/f8eecc13b53fdca998565455d3c27e9b9a6cd8dc but reverted it after getting feedback above. We might want to reconsider adding back that flag, but if the user's IDE does not specify the latest Java version it breaks with an error that Experimental features can only be used with the latest Java SDK version, ATM 22. IMO it is reasonable to expect a user that is developing on the latest version of Tomcat, i.e. the `main` branch, to be using the latest Java SDK, which will work with the Experimental features flag. Users who use an older SDK will have to either disable that flag, or update to the latest SDK. But it is up to the user to choose how to configure their local environment. > - There are times when I have manually tweaked the build to exclude the packages that require Java 22 as I wanted to check something I was doing was still going to be Java 17 compatible and tweaking the IDE was easier than constantly running Ant. That is exactly the reason that I left the commented out lines that exclude the FFM directories in the project- making it easy to toggle the FFM directories by uncommenting or commenting back the lines. Keeping the exclusions in `res/ide-support/idea/compiler.xml` (or `res/ide-support/idea/tomcat.iml`, though I haven't tested that) commented out, allows the user to test the project with all of its features (e.g. FFM), and still make it easy to uncomment the lines and test without FFM on older SDKs. > As build.xml excludes openssl and panama directories from compilation, so should the IDE as well. @dsoumis That is not correct. The build.xml only excludes the FFM directories for Java versions < 22. See lines 1018 - 1033 which make use of the `use-ffm` flag at https://github.com/apache/tomcat/blob/main/build.xml#L1018 No settings will fit everyone 100% as IDEs set local environments with opinionated preferences, but the settings should be reasonable and fit most, and users can easily change the settings that do not fit their needs. We can improve the documentation and instructions to advise users how to configure the IDE, but disabling these directories in the IDE makes them unreachable when debugging/developing, and that's the primary reason to run Tomcat in an IDE. -- 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
Re: [PR] Added option to use custom SSLContext [tomcat]
alipsitz-sf commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-2158656022 Hey, I'm not really good navigating Bugzilla, so I don't know if it's been reported already but it looks like this PR broke the `AbstractHttp11Protocol.reloadSslHostConfigs()` API when relying on the generatedSslContext. You can see in my screenshot on the left side that the SSL Context would ALWAYS be regenerated (when the keystore content changed, the newer version of the certificate chain in the keystore would be used). On the right side, the SSL Context will only be regenerated if `getSslContext()` is null, which will never happen in this use case since that getter falls back to the existing `sslContextGenerated` (newer certificate within the keystore is never used unless a user provided SSL Context is created). Two ideas that come to mind would be to either edit the if-condition `sslContext==null || sslContext.equals(certificate.getSslContextGenerated())` or add and call another getter `certificate.getSslContextProvided()`.  -- 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 9.0.x updated: Change default value for discardFacades to true
This is an automated email from the ASF dual-hosted git repository.
remm 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 d2c6c6e875 Change default value for discardFacades to true
d2c6c6e875 is described below
commit d2c6c6e875cf049f7d7aca3506c2e1e337511a63
Author: remm
AuthorDate: Mon Jun 10 17:06:00 2024 +0200
Change default value for discardFacades to true
---
java/org/apache/catalina/connector/Connector.java | 2 +-
webapps/docs/changelog.xml| 8
webapps/docs/config/http.xml | 2 +-
webapps/docs/config/systemprops.xml | 2 +-
4 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/Connector.java
b/java/org/apache/catalina/connector/Connector.java
index ee1e94edd7..0e7b3ecd55 100644
--- a/java/org/apache/catalina/connector/Connector.java
+++ b/java/org/apache/catalina/connector/Connector.java
@@ -65,7 +65,7 @@ public class Connector extends LifecycleMBeanBase {
* Alternate flag to enable recycling of facades.
*/
public static final boolean RECYCLE_FACADES =
-
Boolean.parseBoolean(System.getProperty("org.apache.catalina.connector.RECYCLE_FACADES",
"false"));
+
Boolean.parseBoolean(System.getProperty("org.apache.catalina.connector.RECYCLE_FACADES",
"true"));
public static final String INTERNAL_EXECUTOR_NAME = "Internal";
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 0e06c11a6c..27569bd081 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -122,6 +122,14 @@
Update minimum recommended version of Tomcat Native to 1.3.0. Pull
request 728 provided by Dimitrios Soumis. (markt)
+
+The system property
+org.apache.catalina.connector.RECYCLE_FACADES will now
+default to true if not specified, which will in turn set
+the default value for the discardFacades connector
+attribute, thus causing facade objects to be discarded by default.
+(remm)
+
diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml
index 1cfde6b55e..dcd1778d53 100644
--- a/webapps/docs/config/http.xml
+++ b/webapps/docs/config/http.xml
@@ -100,7 +100,7 @@
reused. This setting has no effect when the security manager is enabled.
If not specified, this attribute is set to the value of the
org.apache.catalina.connector.RECYCLE_FACADES system
- property, or false if not set.
+ property, or true if not set.
diff --git a/webapps/docs/config/systemprops.xml
b/webapps/docs/config/systemprops.xml
index 6f53cb9afa..d80518e7e9 100644
--- a/webapps/docs/config/systemprops.xml
+++ b/webapps/docs/config/systemprops.xml
@@ -284,7 +284,7 @@
If this is true or if a security manager is in use a new
facade object will be created for each request.
- If not specified, the default value of false will be
used.
+ If not specified, the default value of true will be
used.
(tomcat) branch 9.0.x updated: Fix typo reported by Chuck Caldarale
This is an automated email from the ASF dual-hosted git repository. remm 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 f1aec68e7a Fix typo reported by Chuck Caldarale f1aec68e7a is described below commit f1aec68e7a2fa81c6c157bb1dd761a4ed076a60b Author: remm AuthorDate: Mon Jun 10 16:12:43 2024 +0200 Fix typo reported by Chuck Caldarale --- webapps/docs/config/http.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index eb7f5c21c3..1cfde6b55e 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -625,9 +625,9 @@ This setting dictates how many of these objects get cached. -1 means unlimited, default is 200. 0 means no request processor reuse. This has a very - significant impact on performance depending on the workload, but gives - additional security guarantees by avoidoing reuse of all request - processing objects. + significant impact on performance and garbage collection depending on + the workload, but provides additional security guarantees by avoiding + reuse of all request processing objects. If not using Servlet 3.0 asynchronous processing, an appropriate value is to use the same as the maxThreads setting. If using Servlet 3.0 asynchronous processing, an appropriate value is to use the larger - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 10.1.x updated: Fix typo reported by Chuck Caldarale
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 The following commit(s) were added to refs/heads/10.1.x by this push: new 88e93576b8 Fix typo reported by Chuck Caldarale 88e93576b8 is described below commit 88e93576b874cb656d154b9e6c6caaa6d17b9236 Author: remm AuthorDate: Mon Jun 10 16:12:43 2024 +0200 Fix typo reported by Chuck Caldarale --- webapps/docs/config/http.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index 4303a28f8b..61317d8b5c 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -611,9 +611,9 @@ This setting dictates how many of these objects get cached. -1 means unlimited, default is 200. 0 means no request processor reuse. This has a very - significant impact on performance depending on the workload, but gives - additional security guarantees by avoidoing reuse of all request - processing objects. + significant impact on performance and garbage collection depending on + the workload, but provides additional security guarantees by avoiding + reuse of all request processing objects. If not using Servlet 3.0 asynchronous processing, an appropriate value is to use the same as the maxThreads setting. If using Servlet 3.0 asynchronous processing, an appropriate value is to use the larger - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Fix typo reported by Chuck Caldarale
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 a96458d390 Fix typo reported by Chuck Caldarale a96458d390 is described below commit a96458d390a46ab785b7db9d990291f602e8d57a Author: remm AuthorDate: Mon Jun 10 16:12:43 2024 +0200 Fix typo reported by Chuck Caldarale --- webapps/docs/config/http.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index 3a92d79ff3..fcd8453921 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -597,9 +597,9 @@ This setting dictates how many of these objects get cached. -1 means unlimited, default is 200. 0 means no request processor reuse. This has a very - significant impact on performance depending on the workload, but gives - additional security guarantees by avoidoing reuse of all request - processing objects. + significant impact on performance and garbage collection depending on + the workload, but provides additional security guarantees by avoiding + reuse of all request processing objects. If not using Servlet 3.0 asynchronous processing, an appropriate value is to use the same as the maxThreads setting. If using Servlet 3.0 asynchronous processing, an appropriate value is to use the larger - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 10.1.x updated: Document processorCache disable
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 The following commit(s) were added to refs/heads/10.1.x by this push: new b9e04c9323 Document processorCache disable b9e04c9323 is described below commit b9e04c93235ee62d819f00a8ae1008601d1c90e1 Author: remm AuthorDate: Mon Jun 10 12:14:31 2024 +0200 Document processorCache disable This avoids object reuse so could be good for some additional level of security, at a very significant performance cost in many cases. --- webapps/docs/config/http.xml | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index d11f51c893..4303a28f8b 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -609,11 +609,16 @@ The protocol handler caches Processor objects to speed up performance. This setting dictates how many of these objects get cached. - -1 means unlimited, default is 200. If not using - Servlet 3.0 asynchronous processing, a good default is to use the same as - the maxThreads setting. If using Servlet 3.0 asynchronous processing, a - good default is to use the larger of maxThreads and the maximum number of - expected concurrent requests (synchronous and asynchronous). + -1 means unlimited, default is 200. + 0 means no request processor reuse. This has a very + significant impact on performance depending on the workload, but gives + additional security guarantees by avoidoing reuse of all request + processing objects. + If not using Servlet 3.0 asynchronous processing, an appropriate value + is to use the same as the maxThreads setting. If using Servlet 3.0 + asynchronous processing, an appropriate value is to use the larger + of maxThreads and the maximum number of expected concurrent requests + (synchronous and asynchronous). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 9.0.x updated: Document processorCache disable
This is an automated email from the ASF dual-hosted git repository. remm 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 979ad3661f Document processorCache disable 979ad3661f is described below commit 979ad3661f3314cae21b3b118d92b301f826b99a Author: remm AuthorDate: Mon Jun 10 12:14:31 2024 +0200 Document processorCache disable This avoids object reuse so could be good for some additional level of security, at a very significant performance cost in many cases. --- webapps/docs/config/http.xml | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index c6beb0e130..eb7f5c21c3 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -623,11 +623,16 @@ The protocol handler caches Processor objects to speed up performance. This setting dictates how many of these objects get cached. - -1 means unlimited, default is 200. If not using - Servlet 3.0 asynchronous processing, a good default is to use the same as - the maxThreads setting. If using Servlet 3.0 asynchronous processing, a - good default is to use the larger of maxThreads and the maximum number of - expected concurrent requests (synchronous and asynchronous). + -1 means unlimited, default is 200. + 0 means no request processor reuse. This has a very + significant impact on performance depending on the workload, but gives + additional security guarantees by avoidoing reuse of all request + processing objects. + If not using Servlet 3.0 asynchronous processing, an appropriate value + is to use the same as the maxThreads setting. If using Servlet 3.0 + asynchronous processing, an appropriate value is to use the larger + of maxThreads and the maximum number of expected concurrent requests + (synchronous and asynchronous). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Document processorCache disable
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 3c032e0884 Document processorCache disable 3c032e0884 is described below commit 3c032e08844eb7618248d750c1984cfef35cd37b Author: remm AuthorDate: Mon Jun 10 12:14:31 2024 +0200 Document processorCache disable This avoids object reuse so could be good for some additional level of security, at a very significant performance cost in many cases. --- webapps/docs/config/http.xml | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index d8ccdf6a2c..3a92d79ff3 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -595,11 +595,16 @@ The protocol handler caches Processor objects to speed up performance. This setting dictates how many of these objects get cached. - -1 means unlimited, default is 200. If not using - Servlet 3.0 asynchronous processing, a good default is to use the same as - the maxThreads setting. If using Servlet 3.0 asynchronous processing, a - good default is to use the larger of maxThreads and the maximum number of - expected concurrent requests (synchronous and asynchronous). + -1 means unlimited, default is 200. + 0 means no request processor reuse. This has a very + significant impact on performance depending on the workload, but gives + additional security guarantees by avoidoing reuse of all request + processing objects. + If not using Servlet 3.0 asynchronous processing, an appropriate value + is to use the same as the maxThreads setting. If using Servlet 3.0 + asynchronous processing, an appropriate value is to use the larger + of maxThreads and the maximum number of expected concurrent requests + (synchronous and asynchronous). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Fix ide-support for idea [tomcat]
markt-asf commented on PR #731: URL: https://github.com/apache/tomcat/pull/731#issuecomment-2157847935 I'm not an Idea user so I have no strong view on this. I'd be happy with whatever consensus the Idea users reach. I am an Eclipse user and the approach I use there (which I think the other Eclipse users are happy with) is: - Eclipse is configured to use the same Java version as the build (Java 22 in this case) - I aim to keep the project warning free if used with the current, latest version of Eclipse (I'm currently using the RC for the next release which triggers a couple of extra warnings but I haven't fixed them yet as that will create different warnings for users still on the current release) There are times when I have manually tweaked the build to exclude the packages that require Java 22 as I wanted to check something I was doing was still going to be Java 17 compatible and tweaking the IDE was easier than constantly running Ant. To be honest, configuring the Eclipse IDE from the Ant task isn't something I do that often. Keeping the project error free and the configuration of the auto-format tools is far more important to me than whether the FFM code is included in the IDE by default or not. -- 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
Tagging June releases
Hi all, A bunch of minor issues built up in my TODO list while I was at Community over Code and the Tomcat security day. I'd like to clear these before I tag the June releases. In related news, the release ballots for Servlet and Pages have completed successfully. There is some admin that needs to be completed there as well but the key impact for us is that the next Tomcat 11 vote will be for a BETA release rather than an ALPHA release. My current guess is that I'll be in a position to tag 11.0.x towards the end of the week. I'll provide an update if that changes after I have triaged my inbox. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
JDK 23 Feature Freeze / New Loom EA builds
Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several measures were undertaken to help projects prepare for the switch to `-proc:full`: - As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`. - Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected. With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy. Additional details can be found in the original proposal [5]. [5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html ## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads Project Loom published new early-access builds [6]. These builds have an improved
