On 16/05/2023 18:12, koteswara Rao Gundapaneni wrote:
To service the SSL tomcat end users are now engaged mostly with HTTPD
SERVER and IBM HTTPD
I don't think that is the case.
Yes, lots of Tomcat instances are behind reverse proxies and yes, lots
of those reverse proxies are terminating TLS but there is still a high
demand for Tomcat to be able to terminate TLS since:
- Some users are happy running Tomcat without a reverse proxy.
- Many users use Tomcat in environments (e.g. banking) where it is a
requirement that the channel between the reverse proxy and Tomcat uses
TLS.
Also, if I had to list the most commonly used proxies, I don't think
IBM's HTTP server would be on that list. httpd, ATS, NginX and F5 are
the first few that come to mind.
If we look at the c,c++,etc API vendors they rarely change thier
Products production at user level
Yes, but.
The timescales were are talking about here are large - at least for
software. The average Tomcat release is supported for 10 years. Factor
in LTS policies of Linux distributions such as Debian and Ubuntu and you
can easily get to timescales in the 15-20 year range.
The OpenSSL API that Tomcat Native uses has been very stable over an
extended time frame but even with that we have had to use #ifdef
directives and the like to have a single code base that can be used with
multiple versions - often related to access to new features.
Once we switch to using Panama, we are going to have to figure out how
to handle this. My primary concern is new features that depend on API
calls only present in newer OpenSSL versions.
Mark
On Sat, May 13, 2023 at 1:48 AM Mark Thomas <ma...@apache.org> wrote:
On 12/05/2023 22:24, Rémy Maucherat wrote:
On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
We would normally make Java 21 the minimum Java version. Given that Java
21 is still in EA, I don't plan to do that yet.
Since the update to Java 21 has now been made and seems to make
everyone happy, I would like to discuss Panama.
- Panama as it is right now removes the need for tomcat-native 2.0. It
is stable, fast enough, works out of the box, is much much better for
cloud environments (no funny custom binary to add, only the usual
Java), and so on. Actually, all of these statements were already true
with Java 17, although the API was a bit rougher. Unfortunately at the
moment, it is still preview in Java 21.
- It is possible to include the support right now, but since the API
would change in Java 22, then Tomcat 11 (or at least that feature)
would only target Java 21. Compilation would have to occur on Java 21.
- Support for Java 21 ends in 2028. This means then there would be a
needed API update to Java LTS.next, dropping support for Java 21 (for
that feature), and causing a more complex build (targeting Java 21
with a newer Panama API would cause the compiler to scream).
- Multi release JARs are an option, but this is annoying as it would
require multiple Java versions to build Tomcat (since it is a preview
API), then assemble the multi release JAR. Not looking too good ...
Given all this, there are two main options:
A) (unfortunately) *not* including the Panama support until it is non
preview. Once this happens, then my proposal would be to update the
minimum build Java version (not runtime !) for Tomcat 11, add the
Panama "final API" support, and use the release option to still target
21 (except for the Panama feature classes, of course, which would be
compiled separately). Also as a consequence tomcat-native 2 would have
to be supported for the entire lifecycle of Tomcat 11.
B) Add full support using Java 21, drop tomcat-native. Once Java
LTS.next is released towards the end of 2025 (with non preview Panama,
hopefully), update to use the new API. Users of OpenSSL will have to
move to Java LTS.next
Although I would like B), A) seems more reasonable and in line with
our support practices.
Comments ?
Is there any chance Panama will come out of preview in Java 21?
OpenSSL supports versions for less time than the typical support period
for a major Tomcat version (10 years). And then you have the Linux
distributions that have specific OpenSSL versions and their support
periods. With Tomcat Native we have been able to manage this reasonably
well without too much maintenance burden for us.
How would this work with different versions of OpenSSL? Is it possible
to support multiple OpenSSL versions?
Of the two options you present, I agree that option A is more in-line
with how we typically do things (as much as I would like to say goodbye
to native code).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
