I agree, this should work, and there is a bug. Whether anyone will succeed in fixing it is another question.
One thing to investigate might be what happens if you have 2 pids A and B, with identical configurations, one for blueprint and one for DS. What happens when you first update A then B, or B then A? I suspect what is happening is that the configuration change is triggering an asynchronous blueprint container restart, and during this restart the DS component recycles, and the blueprint container doesn’t deal properly with service changes while it is starting. (It was extremely tricky to get DS to do this properly). So, I suspect it doesn’t actually have to do with configuration at all, just timing. david jencks > On Feb 3, 2017, at 7:40 AM, Tim Ward <[email protected]> wrote: > > I disagree with the earlier statement that Blueprint and DS cannot coexist in > the same bundle. I have thought quite hard about this and can think of no > reason whatsoever why it should not work. > > Tim > > Sent from my iPhone > >> On 3 Feb 2017, at 15:28, 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 >>
