One question - how is the configuration managed? If the blueprint context and DS component are in different bundles and the configuration gets bound to a single bundle location then you may only be configuring one of the bundles. Using the same PID across multiple bundles is usually a recipe for misery and pain…
Regards, Tim > On 2 Feb 2017, at 21:34, Alex Soto <[email protected]> wrote: > > I see how I confused you, I am sorry. I have been simplifying the > description of the problem to make it easier to understand. The reality is > that yes, both the Blueprint context and the component depend on the same > PID. The output I provided earlier does not show it, because this component > depends on another component which is the one that depends on the PID. So > the component is restarted due to its dependency on the other component. In > other words, when I update a property, the two components restart, as does > the blueprint context, but the Blueprint context doest not finish > initializing waiting forever for the service exposed by the component. > > Best regards, > Alex soto > > > >> On Feb 2, 2017, at 4:23 PM, David Jencks <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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] >>> <mailto:[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> >>>> >>> >> >
