I agree it is not the best, this is is just a way to overcome the multiple bundle needing the same configuration PID limitation. On the other hand it provides a convenient, centralized way to validate that the configuration is valid. Agree that a higher abstraction is the best, but it is not always possible or practical, because the same configuration setting can be used by many unrelated services, some implemented as DS components, some as Camel routes. Take for example, a host name, user credentials, etc.
Best regards, Alex soto > On Feb 3, 2017, at 11:05 AM, Christian Schneider <[email protected]> > wrote: > > A service that provides all config settings will create a lot of coupling. I > rather thought about logically providing a common functionality on a higher > level. > > Can you give some examples what you have in the current config? > > Christian > > On 03.02.2017 16:58, Alex Soto wrote: >> I actually played with the idea of centralizing all configuration settings >> in a global service. This service is just a holder of the configuration. >> It is a DS component with just an activation method to load the >> configuration, and a bunch of getters. The rest of the services, even if >> in different bundles, reference this config service to access the >> configuration values. This seems to work, the problem comes when you need >> these same properties in a Blueprint context. Having a lot of Camel routes >> defined in Blueprint, it is not possible (as far as I know) to use the >> placeholder in Camel routes, e.g. {{my.property}} and get the property >> value from this service. >> >> Best regards, >> Alex soto >> >> >> >>> On Feb 3, 2017, at 10:28 AM, Christian Schneider <[email protected]> >>> wrote: >>> >>> I fully agree. I never understood why this decision was made for config >>> admin. In newer versions of the spec it now is possible to share configs >>> but in practice I had lots of problems with it. Still sometimes a common >>> service can help. >>> >>> Christian >>> >>> On 03.02.2017 16:13, Alex Soto wrote: >>>> No, services should be small and highly cohesive. Just because they need >>>> the same configuration setting, it does not mean they provide the same >>>> functionality or should be combined. This CM limitation is actually >>>> pushing for bigger less cohesive services. I am disappointed having >>>> invested in the CM for configuration, and it will cause me painful project >>>> delays now. >>>> >>>> Best regards, >>>> >>>> Alex soto >>>> [email protected] >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
