Please give me more time to think about the overall infrastructure. Xuelei
On 8/4/2014 9:48 AM, Wang Weijun wrote: > Hi Xuelei > > Are you OK with the code change? The updated webrev is now at > > http://cr.openjdk.java.net/~weijun/8038089/webrev.02/ > > Comparing to the last version. there are some comment changes and emptying > refs.allowed. The only major change is that the ServiecLoader now uses system > class loader. > > Thanks > Max > > On Jul 21, 2014, at 16:22, Wang Weijun <weijun.w...@oracle.com> wrote: > >> Please review the updated webrev at >> >> http://cr.openjdk.java.net/~weijun/8038089/webrev.01 >> >> Some comment changes. Some arguments rearrangement between classes. >> >> The interface is still in sun.security.ssl. It will be easy to move it to >> somewhere else later. When module is introduced, we may need to export the >> interface from java.base to java.security.jgss. >> >> Thanks >> Max >> >> On Jul 17, 2014, at 12:35, Xuelei Fan <xuelei....@oracle.com> wrote: >> >>> On 7/16/2014 4:41 PM, Wang Weijun wrote: >>>> Hi Xuelei >>>> >>>> A *primitive* version of webrev available at >>>> >>>> http://cr.openjdk.java.net/~weijun/8038089/webrev.00 >>>> >>>> Please confirm this is the way you like it. >>>> >>> I have not read too much about the details of the update. But looks >>> like it is in the right way. >>> >>>> ExternalCipherSuite is the service interface and Krb5CipherSuite >>>> implements it. It's a modification of the old Krb5Proxy but I've moved as >>>> many as Kerberos-related codes to the implementation side so it has less >>>> methods now. >>>> >>>> Most likely we will define this new interface in a public package. >>>> >>> If krb5 is the only external implementation of TLS cipher suites, I >>> think, we may want to try the best not to define public interface if >>> possible. >>> >>> Thanks, >>> Xuelei >>> >>>> I didn't touch any core SSL classes except for ClientHandshaker and >>>> ServerHandShaker. If you think there are other places too closely >>>> connected with kerberos, please let me know. >>>> >>>> Ideally, those >>>> >>>> case K_KRB5: case K_KRB5_EXPORT: >>>> Krb5Helper.doXXX(...): >>>> >>>> should be something like >>>> >>>> default: >>>> getExternalHelper(keyExchange).doXXX(...) >>>> >>>> but I guess we won't do that unless we know there will be a second >>>> implementation. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >