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
>
