FYI: Created ticket for this issue: https://issues.apache.org/jira/browse/FELIX-5549 <https://issues.apache.org/jira/browse/FELIX-5549>
Best regards, Alex soto > On Feb 14, 2017, at 3:22 PM, Alex Soto <[email protected]> wrote: > > 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] >> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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] <mailto:[email protected]> >>>> >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de <http://www.liquid-reality.de/> >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> >> >
