This sounds great. I have no idea how many people still use X509TrustManager, sorry.
It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. Bye Norman > Am 11.09.2018 um 16:44 schrieb Xuelei Fan <xuelei....@oracle.com>: > > Hi Norman, > > > It may be doable by adding a delegation mode to public TrustManagerFactory: > TrustManagerFactory.init(X509TrustManager proxy) > > However, the X509ExtendedTrustManager should be recommended for now since its > introducing in JDK 7. > > Do you know how many users are still using the X509TrustManager > implementation? > > Thanks, > Xuelei > >> On 9/11/2018 3:32 AM, Norman Maurer wrote: >> Hi all, >> Would it be possible to consider exposing >> SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible >> to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >> I am asking because it provides really nice extra functionality by wrapping >> for X509TrustManager implementation and do extra hostname checks etc. At the >> moment we can not make use of this extra functionality in netty with our >> custom SSLEngine implementation as there is no way to access this. Which >> means depending on if the user use our implementation or the default >> implementation the behaviour if quite different when using a >> X509TrustManager in the sense that when using the default implementation a >> lot of extra checks are done. >> As the extra checks done in AbstractTrustManagerWrapper is not really >> depending on the underlying SSLContextSpi implementation (at least as far as >> I was able to understand it so far) it would be nice to be able to make use >> of it. >> Bye >> Norman
