I think the problem is in blueprint somewhere. I’m a bit confused since you seem to be saying there is only one pid but the DS component uses “org.MyServiceImpl" and the blueprint container uses (IIUC, which I may not) “business”.
david jencks > On Feb 2, 2017, at 1:13 PM, Alex Soto <[email protected]> wrote: > > The Blueprint bundle restarts because it names the configuration PID that the > Component depends on: > i.e., it has something like this: > > <cm:property-placeholder persistent-id="business" update-strategy=“reload" > > Best regards, > Alex soto > > > >> On Feb 2, 2017, at 3:49 PM, David Jencks <[email protected] >> <mailto:[email protected]>> wrote: >> >> IMO it’s unlikely to be a problem in the DS framework. Why is a change in a >> configuration making a blueprint container restart? I’d expect the damping >> proxies to leave the same blueprint component instance in place. >> >> david jencks >> >>> On Feb 2, 2017, at 12:04 PM, Alex Soto <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Yes, the component did not have the immediate=true, and I have an annotated >>> activate method, but I don’t have a deactivated method. The fact that the >>> scr:info shows a name for this method caught my attention, since the >>> modified method is instead shown as a dash (-). This was just me looking >>> for a pattern of something different/wrong. >>> >>> Anyway, thanks for the clarification. >>> >>> The real problem I am having is that another Blueprint bundle is waiting >>> forever for the service exposed by my component. Apparently, the >>> Blueprint dependency for the service is NOT triggering the activation of >>> this component. >>> >>> Now, this does not occur during initial startup, but only after the >>> container has been running, and a change in the component configuration >>> causes the component to restart. I believe there may be a bug here. >>> >>> >>> Best regards, >>> Alex soto >>> >>> >>>> On Feb 2, 2017, at 2:50 PM, Christian Schneider <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi Alex, >>>> >>>> I suppose these components do not have immediate=true and are not used by >>>> any other component. This is just the normal lazy loading. >>>> Without the immediate flag a DS component is only activated if its service >>>> is used. >>>> >>>> Christian >>>> >>>> 2017-02-02 20:04 GMT+01:00 Alex Soto <[email protected] >>>> <mailto:[email protected]>>: >>>> Hello, >>>> >>>> I am using Karaf 4.0.8. >>>> >>>> Some DS components in my application do not show as ACTIVE in the output >>>> from the scr:components command, but show a blank state. >>>> I do no see any difference between the other DS components that are shown >>>> as ACTIVE, and the ones that show blank State. >>>> >>>> Digging a little I found the numeric state of these components is 4 >>>> (SATISFIED) and that the Service the component exposes is active/exported >>>> based on the service:list command. >>>> >>>> These components are declared using DS annotation @Component without any >>>> additional attributes. >>>> >>>> The scr:info command shows this (fragment): >>>> >>>> Default State: enabled >>>> Activation: delayed >>>> Configuration Policy: optional >>>> Activate Method: init >>>> Deactivate Method: deactivate >>>> Modified Method: - >>>> >>>> It is curious that the class does not have any deactivate method, not >>>> annotation for it. >>>> >>>> What is going on? >>>> >>>> Best regards, >>>> Alex soto >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> >> >
