Of note is that Jetty 10 has grown a dependency on SLF4J. At first I was concerned that this might conflict with the version of SLF4J we ship for plugins, but after reading https://www.eclipse.org/jetty/documentation/jetty-10/programming-guide/index.html#pg-server-http-handler-use-webapp-context I managed to convince myself that Jetty could load its own copy of SLF4J in one class loader and Jenkins core could load its own copy of SLF4J in a different class loader and both would delegate to the same copy of JUL seamlessly, in theory. The reasoning behind this is that Jetty 10 marks all Jetty classes as "server classes" which would in theory hide them (and all classes loaded by them, including SLF4J) from the web application (note that this definition of "server class" is different from the one in Jetty 9!). So there is no possibility of Jenkins core or a Jenkins plugin being able to successfully load a Jetty class, and therefore no possibility of Jenkins core or a Jenkins plugin being able to see the Jetty copy of SLF4J rather than the Jenkins core copy.
But this chain of reasoning led me to another conclusion as well: if we can hide SLF4J, then why not also hide Bouncy Castle in similar fashion? (Context: Bouncy Castle is the only obvious way to implement the --httpsPrivateKey and --httpsCertificate options for Java 17, since the Java Platform removed access to "sun.security.util.DerInputStream".) In theory we could configure Bouncy Castle classes to be "server classes", which would allow Jetty to see them but not Jenkins core and plugins, much like the Jetty classes themselves (which are "server classes" in Jetty 10) are not visible to web applications. This would in theory allow a Bouncy Castle based implementation of --httpsPrivateKey and --httpsCertificate. We may want to remove --httpsPrivateKey and --httpsCertificate regardless, because they have been deprecated since 2016. I certainly have no interest in prototyping the above idea myself. But I did want to note that it seems like a plausible option. I guess the question is, does anyone care enough about --httpsPrivateKey and --httpsCertificate to try and prototype the above solution, or do we all agree that it is time to dispense with these options that have been deprecated since 2016? -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjr4CRhwYVGq46-zV8L8dXxG69mbUkHhcFkX9Ng9qNgO6w%40mail.gmail.com.
