ChristopherSchultz commented on PR #706: URL: https://github.com/apache/tomcat/pull/706#issuecomment-2173636514
> > The constructor captures its arguments and then ignores them forever after that. Why bother capturing them in the first place? > > Well actually it is using the KeyManager and TrustManager, see here: https://github.com/apache/tomcat/pull/706/files#diff-8ed2a43a8b2f354b707c0fdb8cd5b794e5a476ecbf603b2ba69af5eea18b3cc4R73-R81 Oops, I seem to have totally missed that part of the code. My apologies. > So the reloading of tomcat was just an example but I use it also for different use cases, such as: > > * Combining custom truststore, cacert and System keystore as a TrustManager > * Fetching certificates as pem from a database and constructing the KeyManager and TrustManager > * Using a custom TrustManager which can prompt when the certificate is not trusted yet and whether it needs to be trusted, ss it can be added to the exusting list of trusted certificates Really, using any custom SSLContext for whatever reason is a valid use case. It's not reasonable for Tomcat to provide all of these various combinations of features, so extensibility is certainly useful. I think the only question is whether this wrapper is really useful to ship with Tomcat. It's certainly not useful *outside* of Tomcat since it uses Tomcat's internal interface. But it does bridge the gap between Java-provided APIs and Tomcat's APIs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
