Sameera, WDYT? Shall we add this to roadmap/jira?
On Tue, Aug 12, 2014 at 6:31 PM, Maninda Edirisooriya <[email protected]> wrote: > +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 >> >> > -- *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
