Do you know where should submit this? I can prepare a small project to reproduce it and submit a ticket, but I don’t know where. Thanks.
Best regards, Alex soto > On Feb 3, 2017, at 8:50 AM, Tim Ward <tim.w...@paremus.com> wrote: > > 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 <alex.s...@envieta.com > <mailto:alex.s...@envieta.com>> 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 <tim.w...@paremus.com >>> <mailto:tim.w...@paremus.com>> 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 <alex.s...@envieta.com >>>> <mailto:alex.s...@envieta.com>> 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 <david.a.jen...@gmail.com >>>>> <mailto:david.a.jen...@gmail.com>> 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 <alex.s...@envieta.com >>>>>> <mailto:alex.s...@envieta.com>> 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 <david.a.jen...@gmail.com >>>>>>> <mailto:david.a.jen...@gmail.com>> 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 <alex.s...@envieta.com >>>>>>>> <mailto:alex.s...@envieta.com>> 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 >>>>>>>>> <ch...@die-schneider.net <mailto:ch...@die-schneider.net>> 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 <alex.s...@envieta.com >>>>>>>>> <mailto:alex.s...@envieta.com>>: >>>>>>>>> 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> >>>>>>> >>>>>> >>>>> >>>> >>> >>
