On 11/12/2020 16:41, Rémy Maucherat wrote: > On Fri, Dec 11, 2020 at 5:36 PM Mark Thomas <ma...@apache.org> wrote: > >> On 11/12/2020 16:24, Michael Osipov wrote: >>> Am 2020-12-10 um 15:07 schrieb ma...@apache.org: >>>> + * @deprecated The scope of the APR/Native Library will be reduced >>>> in Tomcat >>>> + * 10.1.x / Tomcat Native 2.x onwards to only include >> those >>>> + * components required to provide OpenSSL integration >>>> with the NIO >>>> + * and NIO2 connectors. >>> >>> I think there should *not* be a Tomcat Native 2.x for the following >>> reasons: >>> >>> * It has been mentioned numerous times that Tomcat Native is a bad name >>> without a good meaning >>> * > 50 % of the essential parts of Tomcat Native will be gone. It won't >>> be Tomcat Native anymore as previously. >>> * Since the APR connector is deprecated, de facto, it does not logically >>> make sense to evolve Tomcat Native to a new major version. Just >>> counter-intuitive. >>> >>> My counter proposal is to split Tomcat Native, phase it out and >>> introduce Tomcat OpenSSL (Bridge) (libtcopenssl.so) or similar. The name >>> should clearly say what it does. >> >> Using a new name is already one of the options. That possibility was >> mentioned in one of these threads about a week ago. >> >>> You won't going to continue the APRLifecycleListener, will you? >> >> There will almost certainly need to be something like it. I had imagined >> it would get a new name but hadn't given much though to what that name >> should be. >> >>> WDYT? >> >> We need to be careful when we use other organisation's trademarks in our >> product names. Some like: >> >> Apache Tomcat Bridge to OpenSSL >> >> would be fine. The other option is to give it an entirely new name. >> >> Apache Tomcat Phoenix >> >> for example. (I haven't done any checks on that name. It may be >> completely unsuitable - it is just an example). >> > > I'm not sure this native code will stay for that long (replaced with > integrated Java code possibly), so I'm not convinced a name is needed. -> > modules/openssl ?
I think the lifetime of the code is likely to be driven by the minimum Java version required by Jakarta EE and the typical lifecycle of Tomcat major versions. Assuming Tomcat 10.1.x has a minimum Java version that doesn't provide integration with native libraries OOTB then any library we provide to link Tomcat and OpenSSL is likely to have a lifespan of at least 10 years. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
