Done.. ID: 9057278
Thanks Norman > On 17. Sep 2018, at 18:51, Xuelei Fan <xuelei....@oracle.com> wrote: > > Hi Norman, > > Please file an issue for the tracking. > > Thanks, > Xuelei > > On 9/17/2018 5:57 AM, Norman Maurer wrote: >> Should I open an issue somewhere to keep track of it or will you take care >> of it ? >> Bye >> Norman >>> On 11. Sep 2018, at 17:01, Norman Maurer <norman.mau...@googlemail.com> >>> wrote: >>> >>> 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