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

Reply via email to