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] 
>> <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>
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to