On 03/11/2022 12:29, John Dale (DB2DOM) wrote:
Is Tomcat's HTTP/S processing libraries modular and portable?
That depends on how you define "HTTP/S processing libraries", "modular"
and "portable".
Can you take then and use them with something else where you just need
HTTP/S and no servlet API? Not easily.
Are they portable? Yes, they are as portable as Java is.
Are they modular? The classes are all in a single JAR but it is
structured so it easy to extend with new implementations.
Tomcat uses JSSE for TLS. When using OpenSSL, it is wrapped so it looks
like a JSSE implementation.
Mark
On 11/3/22, Mark Thomas <ma...@apache.org> wrote:
On 02/11/2022 18:51, Christopher Schultz wrote:
John,
On 11/2/22 14:32, John Dale (DB2DOM) wrote:
On 11/2/22, Christopher Schultz <ch...@christopherschultz.net> wrote:
John,
On 11/2/22 12:44, John Dale (DB2DOM) wrote:
I'd like to continue to invest in Raspberry Pi, but also try to put
together a functional 32bit build of my software for those poor old
neglected closeted towers (really, poor things!).
I should be able to do it, from the looks of this.
Are you guys doing any kind of pruned down version of Tomcat or maybe
a configurable Tomcat that will only include some bare bones stuff
like request parsing, connection pooling, and (obviously) threading?
You might be surprised to learn that Tomcat is pretty stripped-down
already. What do you imagine that Tomcat is doing that is beyond what
you have listed above?
Isn't there still a lot of J2E code allowing deployment and processing
of J2E standards that aren't necessarily needed? What else?
Well, it supports a few things that you may not use in your
application(s), such as WebSocket, asynchronous I/O, JSP/EL, and JASPIC.
Maybe you don't use JSPs, so you can throw-out the JSP and EL
components. But if you don't use them, they are a few inert kilobytes of
data on the disk. Same with JASPIC. Removing them would be more work
than simply ignoring them.
Tomcat 10.1 requires Java 11 because the specs it follows say that's the
minimum required version, for whatever reason.
The official Tomcat binary releases will be built using Java 11 and thus
they must be run by Java 11 or later.
But there's nothing stopping you from trying to use the source to build
a Java-8-compatible build of Tomcat 10.1. I don't think we are using any
source-level features of Java that actually require anything past Java
8. But if it vomits at runtime because something is missing because you
actually /do/ need Java 11, then we're gonna tell you "don't do that."
There are a few things that will break - and some of them are fairly
fundamental.
The simplest way to see what is going to break is to look at the
org.apache.tomcat.util.compat package. Then you need to look at the
JreNCompat classes that have been removed as a result of the increase in
minimum Java version. For 10.0.x to 10.1.x that is Jre9Compat.
If you want to run 10.1.x on Java 8, in theory you could revert the
commit that removed Jre9Compat but as Chris says you are very much on
your own in terms of support if things go wrong.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org