Assuming you’re using Aries blueprint then that would be a JIRA against Apache Aries at https://issues.apache.org/jira/secure/Dashboard.jspa <https://issues.apache.org/jira/secure/Dashboard.jspa>.
Tim > On 3 Feb 2017, at 13:57, Alex Soto <[email protected]> wrote: > > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[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] >>>> <mailto:[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] >>>>> <mailto:[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> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >
