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
