+1 for a common component in the kernel. And extending your idea, I was thinking why there is no common single OSGi service to read all the configuration files in the config directory. If that was implemented, there would be many advantages.
1. Coding would be cleaner as no file readers and if possible no XML parsing. (parsing requirement would be prevented if we can add JAXB for XML and GSON for JSON) 2. Configuration files would be read only in the server startup or only once, which would reduce performance issues due to bad code to read them frequently 3. Config files would not be written by the server code accidentally (though probability of having such a bug is low) 4. Possible to add listeners to config reader events >From the service consumers point of view it would see a unified configuration object. It would contain decrypted passwords etc. that is easy to access. And we can use that service extended so that when the configuration file contents are overridden by 1. the database contents (e.g. Log4j properties configuration is overridden by Management Console UI entered data) and 2. runtime parameters, (e.g. carbon.xml's port offset can be overridden by the -DportOffset at server startup) we can make that service updated automatically. Then the service consumer does not have to worry about the priorities given to each file, DB etc. and it would prevent the code duplication to manually implement the configuration priorities by the service client. We found issues in our products like not working with -DportOffset but working properly with carbon.xml configuration. Those issues will be prevented with that implementation. As a summary, the new service will 1. expose all the server configuration as a service 2. will not allow to write to configuration files but will allow to update some configuration changes into DB 3. unify configuration priorities given for config files, DB entries and server startup values 4. expose secured strings like passwords to the execution code in plain text which are encrypted by the secure vault in the config file. *Maninda Edirisooriya* Senior Software Engineer *WSO2, Inc.*lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *E-mail* : [email protected] *Skype* : @manindae *Twitter* : @maninda On Tue, Aug 12, 2014 at 5:10 PM, Amila Maha Arachchi <[email protected]> wrote: > Hi all, > > At the moment we cannot enable secure vault for all of our config files > because all the components do not support reading configs with secure vault. > > For example, we cannot enable secure vault for dep-sync password in > carbon.xml because cep-sync component is not written to support it (this > was the case as of August 2013). There are some other such configs in our > products (most of the new config files). So, if we want them to support > secure vault, those components need to be changed. > > But, if we have a common component in the kernel which can do this, then > we can make this a standard in our coding. i.e. Any component which needs > to read a password from a config file should do it via this special > component. > > WDYT? > > Regards, > AmilaM. > > -- > *Amila Maharachchi* > Senior Technical Lead > WSO2, Inc.; http://wso2.com > > Blog: http://maharachchi.blogspot.com > Mobile: +94719371446 > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
