[Bug 67849] MIME type mapping for JavaScript is text/javascript instead of application/javascript
https://bz.apache.org/bugzilla/show_bug.cgi?id=67849 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Mark Thomas --- See RFC 9239 and bug 65995. -- 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 67849] MIME type mapping for JavaScript is text/javascript instead of application/javascript
https://bz.apache.org/bugzilla/show_bug.cgi?id=67849 --- Comment #1 from Guillaume Poirier-Morency --- Our workaround is to add a mime mapping in our web.xml configuration: js application/javascript https://github.com/PavlidisLab/Gemma/commit/578d04170c92595ad153bccc9f075e3afc96d2c8 -- 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 67849] New: MIME type mapping for JavaScript is text/javascript instead of application/javascript
https://bz.apache.org/bugzilla/show_bug.cgi?id=67849 Bug ID: 67849 Summary: MIME type mapping for JavaScript is text/javascript instead of application/javascript Product: Tomcat 9 Version: 9.0.80 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Examples Assignee: dev@tomcat.apache.org Reporter: poiri...@msl.ubc.ca Target Milestone: - This is a regression from Tomcat 8.5. Because of that change, our Apache HTTP server added the charset=UTF-8 to the MIME type which resulted in an error on the client side. -- 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 main updated: Refactor cert load using Tomcat file API and memory BIO
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 87ac09c056 Refactor cert load using Tomcat file API and memory BIO
87ac09c056 is described below
commit 87ac09c056f4befb886b5b7671503cb770673728
Author: remm
AuthorDate: Fri Oct 20 17:09:39 2023 +0200
Refactor cert load using Tomcat file API and memory BIO
Also avoid some useless file reads by using BIO_reset instead.
---
.../util/net/openssl/panama/OpenSSLContext.java| 394 +++--
.../tomcat/util/openssl/openssl_h_Macros.java | 9 +
2 files changed, 213 insertions(+), 190 deletions(-)
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index d81c688efd..9e224bafba 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -17,6 +17,7 @@
package org.apache.tomcat.util.net.openssl.panama;
import java.io.File;
+import java.io.IOException;
import java.lang.foreign.Arena;
import java.lang.foreign.FunctionDescriptor;
import java.lang.foreign.Linker;
@@ -57,6 +58,8 @@ import static
org.apache.tomcat.util.openssl.openssl_h_Compatibility.*;
import static org.apache.tomcat.util.openssl.openssl_h_Macros.*;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.util.file.ConfigFileLoader;
+import org.apache.tomcat.util.file.ConfigurationSource.Resource;
import org.apache.tomcat.util.net.AbstractEndpoint;
import org.apache.tomcat.util.net.Constants;
import org.apache.tomcat.util.net.SSLHostConfig;
@@ -576,6 +579,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
addCertificate(certificate, localArena);
+// SSLContext.setVerify(state.ctx, value,
sslHostConfig.getCertificateVerificationDepth());
// Client certificate verification
int value = 0;
switch (sslHostConfig.getCertificateVerification()) {
@@ -977,225 +981,235 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
//
SSLHostConfig.adjustRelativePath(certificate.getCertificateFile()),
//
SSLHostConfig.adjustRelativePath(certificate.getCertificateKeyFile()),
//certificate.getCertificateKeyPassword(),
getCertificateIndex(certificate));
-var certificateFileNative =
localArena.allocateFrom(SSLHostConfig.adjustRelativePath(certificate.getCertificateFile()));
-var certificateKeyFileNative =
(certificate.getCertificateKeyFile() == null) ? certificateFileNative
-:
localArena.allocateFrom(SSLHostConfig.adjustRelativePath(certificate.getCertificateKeyFile()));
-MemorySegment bio;
-MemorySegment cert = MemorySegment.NULL;
-MemorySegment key = MemorySegment.NULL;
-if (certificate.getCertificateFile().endsWith(".pkcs12")) {
-// Load pkcs12
-bio = BIO_new(BIO_s_file());
-if (BIO_read_filename(bio, certificateFileNative) <= 0) {
-BIO_free(bio);
+byte[] certificateFileBytes = null;
+try (Resource resource =
ConfigFileLoader.getSource().getResource(certificate.getCertificateFile())) {
+certificateFileBytes =
resource.getInputStream().readAllBytes();
+} catch (IOException e) {
+log.error(sm.getString("openssl.errorLoadingCertificate",
certificate.getCertificateFile()), e);
+return;
+}
+MemorySegment certificateFileBytesNative =
localArena.allocateFrom(ValueLayout.JAVA_BYTE, certificateFileBytes);
+MemorySegment certificateBIO = BIO_new(BIO_s_mem());
+try {
+if (BIO_write(certificateBIO, certificateFileBytesNative,
certificateFileBytes.length) <= 0) {
log.error(sm.getString("openssl.errorLoadingCertificate",
"[0]:" + certificate.getCertificateFile()));
return;
}
-MemorySegment p12 = d2i_PKCS12_bio(bio, MemorySegment.NULL);
-BIO_free(bio);
-if (MemorySegment.NULL.equals(p12)) {
-log.error(sm.getString("openssl.errorLoadingCertificate",
"[1]:" + certificate.getCertificateFile()));
-return;
-}
-MemorySegment passwordAddress = MemorySegment.NULL;
-int passwordLength = 0;
-String callbackPassword =
[Bug 67675] Tomcat and/or Java do not read encrypted private keys with DES-EDE3-CBC generated by openssl-req(1)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67675 --- Comment #15 from Michael Osipov --- (In reply to Mark Thomas from comment #14) > I have this working with the current test cases and a default OpenSSL > self-signed key as per the original report. > > The code needs to be cleaned up rather so I am currently expecting to commit > the fix early next week. Magic, if you want me to test it with real certs before you merge just let me know and point me to the branch or go with a PR on GH. -- 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 67675] Tomcat and/or Java do not read encrypted private keys with DES-EDE3-CBC generated by openssl-req(1)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67675 --- Comment #14 from Mark Thomas --- I have this working with the current test cases and a default OpenSSL self-signed key as per the original report. The code needs to be cleaned up rather so I am currently expecting to commit the fix early next week. -- 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: [PR] BZ 66670: Add SSLHostConfig#certificateKeyPasswordFile and SSLHostConfig#certificateKeystorePasswordFile [tomcat]
rmaucher commented on PR #672: URL: https://github.com/apache/tomcat/pull/672#issuecomment-1772689379 Ok, and I'll update the new OpenSSLContext to do things properly (eventually) since it would be better to use a memory BIO rather than a file BIO. -- 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: Non preview FFM (formerly known as Panama) API
On Fri, Oct 20, 2023 at 12:17 PM Michael Osipov wrote: > > On 2023/10/20 07:30:04 Rémy Maucherat wrote: > > Hi, > > > > I am very pleased to report that after years of development, the > > Foreign Function & Memory API is (finally !) no longer a preview API. > > It is now available in build 20 of Java 22 where it can be used > > without the preview flag. > > Downloads: https://jdk.java.net/22/ > > > > Assuming Mark accepts working with an alpha build of Java 22 to > > produce the releases of Tomcat 11, it is now possible to merge the > > OpenSSL code. > > As a reminder, it is located here right now: > > https://github.com/apache/tomcat/tree/main/modules/openssl-foreign > > > > The idea is to build the two packages that need it using a 22 release > > target, while the rest would release target 21 as usual. Using some > > conditionals, it should be possible to allow casual building with 21, > > as it would be bad to drive away contributors who would understandably > > not be very interested in alpha Java 22 yet. I would also add the > > jextract scripts in res/jextract (using jextract at this time is going > > to remain harder however). > > > > "Final" Java 22 will occur next March around the time Jakarta EE 11 is > > supposed to be released, so this aligns to a large extent even in the > > unlikely event where there is no EE schedule slippage. > > > > As for actual use of the component, that's where things will hurt. > > Given the Java support schedules, this would basically be mostly > > unused until the next Java LTS release (probably 25, almost two years > > away). However, the support lifecycle of a Tomcat branch being what it > > is, it would still be relatively early in the Tomcat 11 lifecycle. And > > in the meantime it would give the component a lot of testing, with > > probably a significant amount of niche uses (containers ?). > > > > Comments ? > > This is actually good news! While I will take a look at your code at some > point ot learn how this new API works and learn from you, do you think that > it could live in a separate module (repo) which produces a JAR implementing > an interface then making it available to Tomat 11+ instead of making the > build more complex and conditional? > That's what currently exists, the JAR built in the module can be used with Tomcat 9.0+ (SSLImplementation is the interface used). I believe the added temporary complexity to the build is small compared to the benefits. The obvious one is being able to avoid using tomcat-native out of the box, but there is also the possibility of using the quic API in the not too distant future. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Add OPENSSL_free macro
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 5952cf23a1 Add OPENSSL_free macro
5952cf23a1 is described below
commit 5952cf23a1209fc0e79bce833b86b7704992b050
Author: remm
AuthorDate: Fri Oct 20 14:36:53 2023 +0200
Add OPENSSL_free macro
---
.../apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java | 5 +++--
.../java/org/apache/tomcat/util/openssl/openssl_h_Macros.java | 10 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
index a4af1edc5f..4ef4f41c12 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
@@ -59,6 +59,7 @@ import javax.net.ssl.SSLSessionContext;
import static org.apache.tomcat.util.openssl.openssl_h.*;
import static org.apache.tomcat.util.openssl.openssl_h_Compatibility.*;
+import static org.apache.tomcat.util.openssl.openssl_h_Macros.*;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.buf.Asn1Parser;
@@ -873,7 +874,7 @@ public final class OpenSSLEngine extends SSLEngine
implements SSLUtil.ProtocolIn
MemorySegment buf = bufPointer.get(ValueLayout.ADDRESS, 0);
byte[] certificate = buf.reinterpret(length, localArena,
null).toArray(ValueLayout.JAVA_BYTE);
X509_free(x509);
-CRYPTO_free(buf, MemorySegment.NULL, 0); // OPENSSL_free macro
+OPENSSL_free(buf);
return certificate;
}
}
@@ -897,7 +898,7 @@ public final class OpenSSLEngine extends SSLEngine
implements SSLUtil.ProtocolIn
MemorySegment buf = bufPointer.get(ValueLayout.ADDRESS, 0);
byte[] certificate = buf.reinterpret(length, localArena,
null).toArray(ValueLayout.JAVA_BYTE);
certificateChain[i] = certificate;
-CRYPTO_free(buf, MemorySegment.NULL, 0); // OPENSSL_free macro
+OPENSSL_free(buf);
}
return certificateChain;
}
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/openssl/openssl_h_Macros.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/openssl/openssl_h_Macros.java
index 5d11bdf628..3937d58f59 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/openssl/openssl_h_Macros.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/openssl/openssl_h_Macros.java
@@ -170,6 +170,16 @@ public class openssl_h_Macros {
}
+/**
+ * Free memory.
+ * # define OPENSSL_free(addr) \
+ * CRYPTO_free(addr, OPENSSL_FILE, OPENSSL_LINE)
+ */
+public static void OPENSSL_free(MemorySegment segment) {
+CRYPTO_free(segment, MemorySegment.NULL, 0);
+}
+
+
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] BZ 66670: Add SSLHostConfig#certificateKeyPasswordFile and SSLHostConfig#certificateKeystorePasswordFile [tomcat]
michael-o commented on PR #672: URL: https://github.com/apache/tomcat/pull/672#issuecomment-1772580776 I'd like to merge this weekend unless there will be objections after my change. -- 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: Non preview FFM (formerly known as Panama) API
On 2023/10/20 07:30:04 Rémy Maucherat wrote: > Hi, > > I am very pleased to report that after years of development, the > Foreign Function & Memory API is (finally !) no longer a preview API. > It is now available in build 20 of Java 22 where it can be used > without the preview flag. > Downloads: https://jdk.java.net/22/ > > Assuming Mark accepts working with an alpha build of Java 22 to > produce the releases of Tomcat 11, it is now possible to merge the > OpenSSL code. > As a reminder, it is located here right now: > https://github.com/apache/tomcat/tree/main/modules/openssl-foreign > > The idea is to build the two packages that need it using a 22 release > target, while the rest would release target 21 as usual. Using some > conditionals, it should be possible to allow casual building with 21, > as it would be bad to drive away contributors who would understandably > not be very interested in alpha Java 22 yet. I would also add the > jextract scripts in res/jextract (using jextract at this time is going > to remain harder however). > > "Final" Java 22 will occur next March around the time Jakarta EE 11 is > supposed to be released, so this aligns to a large extent even in the > unlikely event where there is no EE schedule slippage. > > As for actual use of the component, that's where things will hurt. > Given the Java support schedules, this would basically be mostly > unused until the next Java LTS release (probably 25, almost two years > away). However, the support lifecycle of a Tomcat branch being what it > is, it would still be relatively early in the Tomcat 11 lifecycle. And > in the meantime it would give the component a lot of testing, with > probably a significant amount of niche uses (containers ?). > > Comments ? This is actually good news! While I will take a look at your code at some point ot learn how this new API works and learn from you, do you think that it could live in a separate module (repo) which produces a JAR implementing an interface then making it available to Tomat 11+ instead of making the build more complex and conditional? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66875] Handling async error after spring already handled error
https://bz.apache.org/bugzilla/show_bug.cgi?id=66875
--- Comment #8 from Han Li ---
(In reply to Mark Thomas from comment #7)
> The original bug report was for two JSON responses in a single HTTP
> response. Is that still an issue?
>
> Is the error message regarding the response already being committed in
> addition to the multiple JSON bodies or instead of the mutliple JSON bodies?
Hmm, I don't think it's a matter of how many JSON responses in a signle HTTP
response, but of exception handling.
I dug a little deeper and have written a simple unit test[1] to simulate this
scenario.
To put it simply, Spring encapsulates the exception into JSON and responds
normally, and at the same time sets the RequestDispatcher.ERROR_EXCEPTION
attribute. I am not sure whether this behavior is reasonable, but I don't think
it's a tomcat problem, the way I see it the handling is very reasonable. On the
other hand, spring's behavior is very odd.
There is a simple way to fix this issue, we can see whether the response is
committed, if true, do not deal with RequestDispatcher.ERROR_EXCEPTION.
---
if (request.isAsyncDispatching()) {
connector.getService().getContainer().getPipeline().getFirst().invoke(request,
response);
Throwable t = (Throwable)
request.getAttribute(RequestDispatcher.ERROR_EXCEPTION);
if (t != null && !response.isCommitted()) { < here
asyncConImpl.setErrorState(t, true);
}
}
---
Since I am not familiar with this specification, still need Mark to judge...
Hope this helps! ; )
[1].https://gist.github.com/aooohan/b4fd3e1bce5ddda09b51e45173b5ed33
--
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
JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up
Greetings!
JDK 21 has been released (General Availability) on September 19th as planned.
You can find "The Arrival of Java 21" announcement here [1], and some
additional Java 21 materials in the "Topics of Interest" section below. On
behalf of the entire Java team, let me send our thanks to all of you. Through
your active participation in this program, you are helping shape the Java
platform!
Needless to say, that Java 21 is an important release, so may I ask you to send
me a brief email with the Java 21 support status of your project(s): Already
supported - Plan to support short-term - Don't plan to support short-term ?
And now that JDK 21 is out, let's shift our attention to JDK 22 which will
enter the Rampdown Phase in less than 50 days on December 7 [2].
I want to conclude this update by briefly mentioning three different
initiatives to are relevant to this group as they are, in their own way and at
various levels, contributing to adopt newer Java releases more rapidly: the
Class-File API, Oracle's Java Platform extension for VS Code, and the Java
Playground.
### The Class-File API
The Class-File API is a new standard API for parsing, generating, and
transforming Java class files. One of its unique aspects is that it will
co-evolve with the class-file format, which overtime will greatly reduce the
friction of implementing new class-file features. With the fast-paced evolution
of the Java platform, this was much-needed. This API should soon be previewed
and as it matures, we expect the JDK to switch from using various custom
class-file libraries to this standard API. We also expect that overtime
frameworks relying on bytecode manipulation will also benefit from using this
new JDK class-file library. For more information, please check this recent
Newscast [3] for an overview, Brian Goetz's JVMLS session [4] for more details
and design considerations, and JEP 457: Class-File API (Preview) [5] for the
technical details.
### Oracle's Java Platform extension for Visual Studio Code
Oracle has just announced [6] a new Visual Studio Code extension for Java
developers. Unlike other VS Code extensions, this new extension is using under
the hood the `javac` compiler for code editing and compilation, and OpenJDK's
debugger interface for debugging. This enables us to offer VS Code IDE support
for new JDK features as soon as they are introduced, even during JDK Early
Access phases. To this effect, this VS Code Extension will support the current
JDK releases as well as the next upcoming JDK version. For more information,
please check the announcement [6].
### The Java Playground
The Java Playground [7] is an online sandbox that helps testing and exploring
new Java language features. No setup required, just type your Java snippet in
your browser and run it! Right now, the Playground is using Java 21 with
Preview Features enabled, and it will switch to a new Java version as soon as
there is a new Java language features integrated in OpenJDK Early-Access
builds. The Playground is focusing mostly on Project Amber and is certainly not
mean to be some sort of a lightweight online-IDE, it is instead a learning tool
to play with new Java language feature shortly after they have been integrated
into the platform.
[1] https://inside.java/2023/09/19/the-arrival-of-java-21/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html
[3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks
[4] https://www.youtube.com/watch?v=pcg-E_qyMOI
[5] https://openjdk.org/jeps/457
[6] https://inside.java/2023/10/18/announcing-vscode-extension/
[7] https://dev.java/playground
## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change
As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21
javac emits a note if _implicit_ annotation processing is being used, that is,
if one or more annotation processors are found and run from the class path when
no explicit annotation processing configuration options are used.
The note is reported since, quoting from the note text: "A future release of
javac may disable annotation processing unless at least one processor is
specified by name (-processor), or a search path is specified
(--processor-path, --processor-module-path), or annotation processing is
enabled explicitly (-proc:only, -proc:full)."
That future version of javac has arrived in JDK 22 b19+ with JDK-8306819
("Consider disabling the compiler's default active annotation processing"). In
the situation where a note was emitted in JDK 21, in JDK 22 no note is emitted,
and annotation processors are *not* run. To restore the previous behavior with
respect to running annotation processors, add the '-proc:full' javac option.
Feedback on the annotation processing policy change can be sent to compiler-dev
[9].
[8] https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html
[9] https://mail.openjdk.org/mailman/listinfo/compiler-dev
## JDK
Re: [PR] Added option to use custom SSLContext [tomcat]
Hakky54 commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-1772265010 I see indeed clearly that it was not the intention of the developers/maintainers to expose a setter method to set a custom sslcontext which is later on ignored. As it is clearly not a bug it must be that the maintainers didn't wanted to support a custom configuration like that. So what is your overall opinion regarding this topic, what do you think of enabling users to allow to configure ssl configuration of their server programatically? And if positive what would be the downside of supporting something like this and if negative why would you not allow the user the configure it like that? -- 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
Non preview FFM (formerly known as Panama) API
Hi, I am very pleased to report that after years of development, the Foreign Function & Memory API is (finally !) no longer a preview API. It is now available in build 20 of Java 22 where it can be used without the preview flag. Downloads: https://jdk.java.net/22/ Assuming Mark accepts working with an alpha build of Java 22 to produce the releases of Tomcat 11, it is now possible to merge the OpenSSL code. As a reminder, it is located here right now: https://github.com/apache/tomcat/tree/main/modules/openssl-foreign The idea is to build the two packages that need it using a 22 release target, while the rest would release target 21 as usual. Using some conditionals, it should be possible to allow casual building with 21, as it would be bad to drive away contributors who would understandably not be very interested in alpha Java 22 yet. I would also add the jextract scripts in res/jextract (using jextract at this time is going to remain harder however). "Final" Java 22 will occur next March around the time Jakarta EE 11 is supposed to be released, so this aligns to a large extent even in the unlikely event where there is no EE schedule slippage. As for actual use of the component, that's where things will hurt. Given the Java support schedules, this would basically be mostly unused until the next Java LTS release (probably 25, almost two years away). However, the support lifecycle of a Tomcat branch being what it is, it would still be relatively early in the Tomcat 11 lifecycle. And in the meantime it would give the component a lot of testing, with probably a significant amount of niche uses (containers ?). Comments ? Rémy - 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]
rmaucher commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-1772201584 It doesn't work like that because it was not supposed to. The item that is/was supposed to be configured is the SSLImplementation, which then provides the SSLUtil which will create the SSLContext. Now allowing your hack is not very complicated, so maybe, but we're never going to give any guarantees that it will never change in the future ... -- 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
