Am 18.07.24 um 16:59 schrieb Rémy Maucherat:
On Thu, Jul 18, 2024 at 2:41 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
Am 18.07.24 um 14:15 schrieb Michael Osipov:
On 2024/07/17 15:33:02 Mark Thomas wrote:
All,
I've spent some time today trying to build Tomcat Native with Visual
Studio 2022 rather then the current, more involved process without success.
Therefore, my short-term plan for Tomcat Native is to get the next 2.0.x
and 1.3.x releases completed using the existing build process. I'll be
starting that shortly.
Longer term, thinking about Tomcat Native and FFM I have the following
rough plan in mind:
- stop providing x86 binaries for Windows
- require Windows 10 onwards
- provide:
- libssl.dll
- libcrypto.dll
- tomcat-native-2.dll
- openssl.exe
along with appropriate debug symbols.
This sounds reasonable...but did you rename tcnative on purpose?
I'm not sure if we'd need an apr.dll in there as well.
The idea is that users can then use either the AprLifecycleListener or
OpenSSLLifecycleListener.
This would probably require moving Tomcat Native to 2.1.x and 1.4.x
This really needs someone more familiar with building C libraries
generally and these libraries in particular - i.e. Mladen - to say
whether the above is possible and to provide some pointers on how to do it.
I would prefer that all APR-related stuff in the build is also removed in
2.1.x. Why does one need it if it is not used? That is weird.
I'll try to clarify a few things: we have a few different cases where
native libraries are used. Please correct me where I am wrong:
- the APR connector; only supported in TC 9.0. Implemented via tcnative
1.3. Needs code from tcnative and the APR libraries.
- doing OpenSSL crypto instead of JSSE crypto in a connector using
tcnative. supported in TC 9+; Implemented via tcnative 1.3 and 2.0.
Needs code from tcnative, the APR library and the OpenSSL library. The
APR library is needed, because tcnative uses the memory pool
implementation of APR for its own memory management.
- doing OpenSSL crypto instead of JSSE crypto in a connector using the
new Java 22+ foreign function interface. Supported in TC 10.1+;
Implemented via FFM plus OpenSSL library. Only needs code from the
OpenSSL library.
I was able to port the FFM support to Tomcat 9.0 (will be in 9.0.92)
with very little actual trouble, along with all the improvements in
TLS testing from 10.1. As suggested by someone (can't remember who,
maybe you ?), Ant's javac task allows specifying another javac
executable and it worked well to solve the blocker issue about the
Java 8 release target.
This really improves the long term support prospects for 9.0 as far as
I am concerned.
That's ultra cool!
Rémy
Concerning the existence of explicit separate libapr, libcrypto and
libssl dll files in the tcnative binary distribution for Windows: I
expect one can decide during copilation, which of these libraries will
be kept separate as dynmic library files and linked in dynamically and
which of them get linked in statically, so that no separate file needs
to be shipped.
It seems until 2.0.7 (8?) and 1.3.0 (1?) we link in the apr, crypto and
ssl libs statically, so no separate dll files are shipped.
Marks suggestion indicates that he suggests to link the two OpenSSL libs
dynamically and ship the crypto and ssl libs them bundled but keep the
apr lib linked statically, so no separate dll file for it.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
