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. 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
