Hi Danesh, IMO, A hybrid of Option 1 and Option2 would be the best.
i.e: 1. If the instantiation of SecureVault and ConfigProvider is separated out, as you mentioned in the Option1, then we have the flexibility of providing the SecureVault implementation to the ConfigProvider. Which improves the clarity of the API and in the meantime improves the testability of the code. 2. If we can merge the secure-vault configurations into the deployment.yaml that would be the ideal case. As we are now trying to put all configurations related things in one file. But if we make a dependency in SecureVault for ConfigProvider, then it creates cyclic dependency. SecureVault <-> ConfigProvider. One way to avoid this conflict is to read the deployment.yaml separately in the SecureVault and read only the relevant section for the SecureVault. WDYT? Thanks, Jayanga. *Jayanga Dissanayake* Associate Technical Lead WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware email: [email protected] mobile: +94772207259 <http://wso2.com/signature> On Fri, Mar 31, 2017 at 3:40 PM, Vidura Nanayakkara <[email protected]> wrote: > Hi Danesh, > > IMO, option 2 can be used in OSGi mode. However, in non-OSGi mode, we may > use the secure vault only rather than using the config provider and the > secure vault. Therefore having a deployment.yaml file including the secure > vault yaml configuration sounds a bit odd. Furthermore in this case how are > we extracting the secure vault configuration out of the deployment yaml. > > *Suggestion: *IMO we should proceed with option 2 in OSGi mode and option > 1 in non-OSGi mode. So in non-OSGi mode how the user initializes secure > vault would be like: > > Example 1: > > Path secureVaultconfigPath = <secure-vault.yaml file path>; > SecureVaultFactory secureVaultFactory = new SecureVaultFactory(); > SecureVault secureVault = secureVaultFactory.getSecureVault( > secureVaultconfigPath); > or > > Example 2: > > Path secureVaultconfigPath = <secure-vault.yaml file path>; > SecureVaultConfiguration securevaultconfiguration = > SecureVaultConfigProvider.createSecureVaultConfiguration > (secureVaultconfigPath); > SecureVaultFactory secureVaultFactory = new SecureVaultFactory(); > SecureVault secureVault = secureVaultFactory.getSecureVault( > securevaultconfiguration); > > In the OSGi mode we can use Example 2 when initializing securevault inside > the config provider. > > WDYT? > > > On Fri, Mar 31, 2017 at 11:02 AM, Danesh Kuruppu <[email protected]> wrote: > >> Hi all, >> >> In the current non-OSGi securevault implementation, we need to pass >> securevault configuration file path when initializing the securevault >> service instance. like below, >> >>> Path *configPath* = <secure-vault.yaml file path>;SecureVaultFactory >>> secureVaultFactory = new SecureVaultFactory();SecureVault secureVault = >>> secureVaultFactory.getSecureVault(*configPath*); >>> >>> >> Since Configuration Provider directly depends on securevault, we need to >> initialize securevault instance because initializing the Configuration >> Provider. Below are few options we can follow when initializing Config >> Provider non-OSGi mode >> >> Option 01: Force user to create securevault instance before creating >> Configuration Provider instance. We will provide method in provider factory >> to get ConfigProvider by passing deployment config file path and >> securevault instance. like below, >> >> Path *secureVaultconfigPath* = <secure-vault.yaml file >> path>;SecureVaultFactory secureVaultFactory = new >> SecureVaultFactory();SecureVault *secureVault* = >> secureVaultFactory.getSecureVault(*secureVaultconfigPath*); >>> >>> Path *deploymentConfigPath* = <deployment.yaml file path>; >>> ConfigProviderFactory configProviderFactory = new ConfigProviderFactory(); >>> ConfigProvider configProvider = >>> configProviderFactory.getConfigProvider(*deploymentConfigPath*, >>> *secureVault*); >>> >>> >> Option 02: Allow user to pass deployment.yaml(can be any file name) file >> path only and we create the securevault instance. in order to do that, we >> should know the securevault config file path. Shall we add securevault >> configuration also to the deployment.yaml file(can be any file name. we >> keep same file to hold both server configs and securevault configs) and >> pass the same file to initialize securevault when initializing >> configuration provider. So configuration file will looks like, >> ... >> >> wso2.securevault: >> secretRepository: >> type: org.wso2.carbon.secvault.repository.DefaultSecretRepository >> parameters: >> privateKeyAlias: wso2carbon >> keystoreLocation: resources/security/wso2carbon.jks >> secretPropertiesFile: conf/secrets.properties >> masterKeyReader: >> type: org.wso2.carbon.secvault.reader.DefaultMasterKeyReader >> parameters: >> masterKeyReaderFile: conf/master-keys.yaml >> >> ... >> >> So when initializing the securevault, provider will read the same config >> file and get configurations under wso2.securevault. >> >> Please share your thoughts / suggestions. >> >> Thanks >> -- >> >> *Danesh Kuruppu* >> Senior Software Engineer | WSO2 >> >> Email: [email protected] >> Mobile: +94 (77) 1690552 <+94%2077%20169%200552> >> Web: WSO2 Inc <https://wso2.com/signature> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Best Regards, > > *Vidura Nanayakkara* > Software Engineer > > Email : [email protected] > Mobile : +94 (0) 717 919277 <+94%2071%20791%209277> > Web : http://wso2.com > Blog : https://medium.com/@viduran <http://wso2.com/> > LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara > <http://wso2.com/> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
