As far as I can tell, the problem occurs regardless of wether the DS component is (or not) in a separate bundle. My project is a mix of Camel routes defined in Blueprint DSL with some of the Camel routes calling services defined as DS components. Is this not a common/valid scenario?
Best regards, Alex soto > On Feb 3, 2017, at 9:11 AM, Christian Schneider <[email protected]> > wrote: > > Is there any good reason for using DS and blueprint in the same bundle. While > it can work we never test this case and recommend to not mix two DI > frameworks in the same bundle. > > Christian > > > On 03.02.2017 14:42, Alex Soto wrote: >> Yes, I hear you, I’ve read about it here as well. It is the same bundle; >> both the Blueprint context and the component are in the same bundle. >> To summarize: a single bundle with both a DS component and a Blueprint >> context referencing the same configuration PID. The Blueprint context >> depends on the service exposed by the DS component. Initial deployment is >> fine. A change in the configuration after steady state causes the Blueprint >> context to wait for the service forever. It does not matter if the >> component’s immediate attribute is true or false; it fails in both cases. >> >> Best regards, >> Alex soto > > -- > Christian Schneider > http://www.liquid-reality.de <http://www.liquid-reality.de/> > > Open Source Architect > http://www.talend.com <http://www.talend.com/>
