On 10 Oct 2014, at 09:43, Wang Weijun <weijun.w...@oracle.com> wrote:
> > On Oct 8, 2014, at 23:30, Sean Mullan <sean.mul...@oracle.com> wrote: > >>>> This enhancement could then be useful for more than just jssecacerts. For >>>> example, in my JavaOne presentation, I gave an example of creating a >>>> Domain KeyStore that encompasses two root stores: >>> >>> This means we will need to provide both store type and store path (or >>> config file) in the same option. It looks like multiple system properties >>> is good at this. >> >> Good point. >> >>> >>> Or, shall we invent a URI scheme? >> >> No, that seems like too much work. > > In your slide, the DKS keystore is loaded by > > keystore.load(new DomainLoadStoreParameter(uri, Collections.emptyMap()); > > which means we cannot simply provide two system properties (or two new > options) > > jdk.keytool.cacerts = dks.config > jdk.keytool.cacerts.type = dks > > and write a common code to load it. > > BTW, I see that DomainKeyStore#load(stream,pass) is designed to load a > keystore of JKS (or another default storetype). Why didn't we load a DKS > config file (with common passwords or all null)? The DKS implementation supports the common use case of loading a single keystore from a file to aid compatibility with existing keystore applications and existing keystores. Although I can also see the advantage of supporting a DKS configuration file via that load method. Maybe the implementation should support both? > >> In fact, it is plausible we should defer this RFE for now if it is a lot of >> work, and we have higher priority things to work on. > > OK. The bug report already included a workaround. > > --Max > >> How common is jssecacerts used anyway? I never really understood why there >> was a separate JSSE specific file for ca root certificates, I believe this >> may have been an artifact from when JSSE was shipped as a standalone >> extension. >> >> --Sean >
