Page History

...

1. Should not ideally we move out the common SSL configurations in the EncryptionOption and may be define a parent class like CommonEncryptionOption?
   1. Response: Ideally yes. While it is little weird to have conflicting configuration options in the EncryptionOption (i.e. file based keystore/truststore paths and pluggable sslcontext factory which mostly intended toward not using file based artifacts), practically we could still live with little imperfection. However we will be open to discuss if the community members feel it is best to have a parent class to move out 'common' ssl configurations between file based and pluggable sslcontext factory.
   2. Above stated reason results into the current design of the interface which requires EncryptionOptions to be passed to most of it's methods because the implementation needs to know the "common SSL configurations".
   3. Changes would look like this Git commit
2. Should we move to model of having Map<String,String> type as passing all the SSL configuration options to any implementation of the ISslContextFactory including the Default/Common one?
   1. Yes we could do that but for that we would have to "copy" all the common SSL configurations to the Map<String,String> while creating the instance of the ISslContextFactory's implementation including the Default one. This would also help make the imperfection of not adding CommonEncryptionOption suggested in the 1st question.
   2. Again, we would need community's input on the preference. Changes would look like this Git commit
   3. As you would notice from the above Git commit link, this option means we would need to move EncryptedOptions#acceptedProtocols() and EncryptionOptions#cipherSuiteArray() to ISslContextFactory interface 

...