That sounds like a bug in blueprint then, unless there's a filter on the blueprint reference which prevents it from picking the reconfigured service it should definitely re-wire.
Tim Sent from my iPhone > On 3 Feb 2017, at 13:42, Alex Soto <[email protected]> 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 > > >> On Feb 3, 2017, at 3:00 AM, Timothy Ward <[email protected]> wrote: >> >> 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]> 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]> 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]> >>>>>> 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]> 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]> 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]>: >>>>>>>>> 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 >>>>>>>> >>>>>>>> Open Source Architect >>>>>>>> http://www.talend.com >>>>>>> >>>>>> >>>>> >>>> >>> >> >
