Hello, It took me a while, but now I have a minimally working example of this problem. I now think the problem is in DS, and not in Blueprint.
I uploaded this into a public repository here: https://github.com/lexsoto/blueprint-ds-config-reload <https://github.com/lexsoto/blueprint-ds-config-reload> In case somebody wants to take a look. In the sample app, the FactoryComp initializes correctly but it fails to recover from a change in the configuration. Blueprint is not affected, as long as it does not depend on this component. Please let me know if this is valid bug, or something I am doing wrong. Best regards, Alex soto > On Feb 3, 2017, at 1:00 PM, David Jencks <[email protected]> wrote: > > 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 >>> >
