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 >>> >>> >>> >>> >>> >>> >> >
