[8] code review for 8007755: Support the logical grouping of keystores

[Vincent Ryan]

On 13/02/2013 19:10, Sean Mullan wrote:
> On 02/13/2013 01:22 PM, Vincent Ryan wrote:
>> Latest webrev:
>>      http://cr.openjdk.java.net/~vinnie/8007755/webrev.01/
>
> Looks good.
>
>>> Also, this will require a CCC, so you won't be able to fix this now, but
>>> the DomainLoadStoreParameter should be a standalone class, since it is
>>> keystore-type specific.
>>
>> A more descriptive name would be useful since it'll no longer be nested
>> in the KeyStore class.
>>
>> For example,  java.security.KeyStoreDomainParameter.
>
> I actually prefer if the name starts with Domain, or DKS. I also think
> this is consistent with other type specific parameter classes like
> LDAPCertStoreParameters, etc ..
>

OK. DomainKeyStoreParameters would be consistent.


>>>
>>> Also, I don't think a policy keystore entry will work with a Domain
>>> Keystore since it doesn't use LoadStoreParameters. Please file another
>>> bug to fix this later.
>>
>> OK. That will require adding support for a new optional line in the
>> policy file that specifies the location of a DKS configuration.
>>
>> For example:
>>      keystore "NONE", "DKS";
>>      keystoreConfigURI "file:///x/y/z";
>
> Or you could treat the URL as the config URL just for domain keystores:
>
> keystore "file:///x/y/z", "DKS";


That'd certainly be convenient but it might lead to confusion since the
keystore file is normally in that location and we've already established
the practice of using "NONE" when a keystore file is not appplicable.

However it would also allow us to add similar support to keytool, for 
consistency. For example,

   % keytool -storetype DKS -keystore file:///x/y/z



>
> --Sean