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