You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Alex Soto <al...@envieta.com> on 2017/02/02 19:04:25 UTC
DS components not Active
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
Re: DS components not Active
Posted by David Jencks <da...@gmail.com>.
I’m not sure exactly what the scr:components command is supposed to show, but everything looks consistent and fine based on my guesses about what it is doing. Did you have a specific question? Note that DS components are by default delayed, which means that if they expose a service they remain in SATISFIED state while the service is unused. The default for a deactivate method is “deactivate”. Whether or not there is such a method is determined when it’s time to call it (if present). I suspect you’ve annotated the activate method?
david jencks
> On Feb 2, 2017, at 11:04 AM, Alex Soto <al...@envieta.com> wrote:
>
> 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
>
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
Testing now with with immediate = true, the component is active. The exported service is shown by service:list command, yet the Blueprint bundle still show as waiting on the service:
karaf@root()> scr:components
ID | State | Component Name
----------------------------------------------------------------------------------------------------------
86 | ACTIVE | org.MyServiceImpl
karaf@root()> scr:info 86
*** Bundle: business (116)
Component Description:
Name: org.MyServiceImpl
Implementation Class: org.MyServiceImpl
Default State: enabled
Activation: immediate
Configuration Policy: optional
Activate Method: init
Deactivate Method: deactivate
Modified Method: -
Configuration Pid: [org.MyServiceImpl]
Services:
org.MyService
Service Scope: singleton
…..
karaf@root()> diag 116
business (116)
----------------------------
Status: Waiting
Blueprint
2/2/17 3:43 PM
Missing dependencies:
(objectClass=org.MyService)
karaf@root()> service:list org.MyServiceImpl
[org.MyServiceImpl]
----------------------------------------------------------------------
component.id = 86
component.name = org.MyServiceImpl
service.bundleid = 116
service.id = 535
service.scope = bundle
Provided by :
business (116)
Bundle 116 is the Blueprint bundle waiting for the service after a config change. It does not recover from this state.
Best regards,
Alex soto
> On Feb 2, 2017, at 3:49 PM, David Jencks <da...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
I agree it is not the best, this is is just a way to overcome the multiple bundle needing the same configuration PID limitation. On the other hand it provides a convenient, centralized way to validate that the configuration is valid. Agree that a higher abstraction is the best, but it is not always possible or practical, because the same configuration setting can be used by many unrelated services, some implemented as DS components, some as Camel routes. Take for example, a host name, user credentials, etc.
Best regards,
Alex soto
> On Feb 3, 2017, at 11:05 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> A service that provides all config settings will create a lot of coupling. I rather thought about logically providing a common functionality on a higher level.
>
> Can you give some examples what you have in the current config?
>
> Christian
>
> On 03.02.2017 16:58, Alex Soto wrote:
>> I actually played with the idea of centralizing all configuration settings in a global service. This service is just a holder of the configuration. It is a DS component with just an activation method to load the configuration, and a bunch of getters. The rest of the services, even if in different bundles, reference this config service to access the configuration values. This seems to work, the problem comes when you need these same properties in a Blueprint context. Having a lot of Camel routes defined in Blueprint, it is not possible (as far as I know) to use the placeholder in Camel routes, e.g. {{my.property}} and get the property value from this service.
>>
>> Best regards,
>> Alex soto
>>
>>
>>
>>> On Feb 3, 2017, at 10:28 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>>
>>> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>>>
>>> Christian
>>>
>>> On 03.02.2017 16:13, Alex Soto wrote:
>>>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>>>
>>>> Best regards,
>>>>
>>>> Alex soto
>>>> alex.soto@envieta.com
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: DS components not Active
Posted by Christian Schneider <ch...@die-schneider.net>.
A service that provides all config settings will create a lot of
coupling. I rather thought about logically providing a common
functionality on a higher level.
Can you give some examples what you have in the current config?
Christian
On 03.02.2017 16:58, Alex Soto wrote:
> I actually played with the idea of centralizing all configuration settings in a global service. This service is just a holder of the configuration. It is a DS component with just an activation method to load the configuration, and a bunch of getters. The rest of the services, even if in different bundles, reference this config service to access the configuration values. This seems to work, the problem comes when you need these same properties in a Blueprint context. Having a lot of Camel routes defined in Blueprint, it is not possible (as far as I know) to use the placeholder in Camel routes, e.g. {{my.property}} and get the property value from this service.
>
> Best regards,
> Alex soto
>
>
>
>> On Feb 3, 2017, at 10:28 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>>
>> Christian
>>
>> On 03.02.2017 16:13, Alex Soto wrote:
>>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>>
>>> Best regards,
>>>
>>> Alex soto
>>> alex.soto@envieta.com
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
I actually played with the idea of centralizing all configuration settings in a global service. This service is just a holder of the configuration. It is a DS component with just an activation method to load the configuration, and a bunch of getters. The rest of the services, even if in different bundles, reference this config service to access the configuration values. This seems to work, the problem comes when you need these same properties in a Blueprint context. Having a lot of Camel routes defined in Blueprint, it is not possible (as far as I know) to use the placeholder in Camel routes, e.g. {{my.property}} and get the property value from this service.
Best regards,
Alex soto
> On Feb 3, 2017, at 10:28 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>
> Christian
>
> On 03.02.2017 16:13, Alex Soto wrote:
>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>
>> Best regards,
>>
>> Alex soto
>> alex.soto@envieta.com
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
For me, the only issue so far is that Blueprint does not rewire after a config change. Seems to work other than that.
Best regards,
Alex soto
> On Feb 3, 2017, at 10:40 AM, Tim Ward <ti...@paremus.com> wrote:
>
> I disagree with the earlier statement that Blueprint and DS cannot coexist in the same bundle. I have thought quite hard about this and can think of no reason whatsoever why it should not work.
>
> Tim
>
> Sent from my iPhone
>
>> On 3 Feb 2017, at 15:28, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>>
>> Christian
>>
>>> On 03.02.2017 16:13, Alex Soto wrote:
>>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>>
>>> Best regards,
>>>
>>> Alex soto
>>> alex.soto@envieta.com
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
FYI:
Created ticket for this issue: https://issues.apache.org/jira/browse/FELIX-5549 <https://issues.apache.org/jira/browse/FELIX-5549>
Best regards,
Alex soto
> On Feb 14, 2017, at 3:22 PM, Alex Soto <al...@envieta.com> wrote:
>
> Hello,
>
> It took me a while, but now I have a minimally working example of this problem.
> I now think the problem is in DS, and not in Blueprint.
>
> I uploaded this into a public repository here: https://github.com/lexsoto/blueprint-ds-config-reload <https://github.com/lexsoto/blueprint-ds-config-reload>
> In case somebody wants to take a look.
>
> In the sample app, the FactoryComp initializes correctly but it fails to recover from a change in the configuration. Blueprint is not affected, as long as it does not depend on this component. Please let me know if this is valid bug, or something I am doing wrong.
>
>
> Best regards,
> Alex soto
>
>
>
>> On Feb 3, 2017, at 1:00 PM, David Jencks <david.a.jencks@gmail.com <ma...@gmail.com>> wrote:
>>
>> I agree, this should work, and there is a bug. Whether anyone will succeed in fixing it is another question.
>>
>> One thing to investigate might be what happens if you have 2 pids A and B, with identical configurations, one for blueprint and one for DS. What happens when you first update A then B, or B then A? I suspect what is happening is that the configuration change is triggering an asynchronous blueprint container restart, and during this restart the DS component recycles, and the blueprint container doesn’t deal properly with service changes while it is starting. (It was extremely tricky to get DS to do this properly). So, I suspect it doesn’t actually have to do with configuration at all, just timing.
>>
>> david jencks
>>
>>> On Feb 3, 2017, at 7:40 AM, Tim Ward <tim.ward@paremus.com <ma...@paremus.com>> wrote:
>>>
>>> I disagree with the earlier statement that Blueprint and DS cannot coexist in the same bundle. I have thought quite hard about this and can think of no reason whatsoever why it should not work.
>>>
>>> Tim
>>>
>>> Sent from my iPhone
>>>
>>>> On 3 Feb 2017, at 15:28, Christian Schneider <chris@die-schneider.net <ma...@die-schneider.net>> wrote:
>>>>
>>>> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>>>>
>>>> Christian
>>>>
>>>>> On 03.02.2017 16:13, Alex Soto wrote:
>>>>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Alex soto
>>>>> alex.soto@envieta.com <ma...@envieta.com>
>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
Hello,
It took me a while, but now I have a minimally working example of this problem.
I now think the problem is in DS, and not in Blueprint.
I uploaded this into a public repository here: https://github.com/lexsoto/blueprint-ds-config-reload <https://github.com/lexsoto/blueprint-ds-config-reload>
In case somebody wants to take a look.
In the sample app, the FactoryComp initializes correctly but it fails to recover from a change in the configuration. Blueprint is not affected, as long as it does not depend on this component. Please let me know if this is valid bug, or something I am doing wrong.
Best regards,
Alex soto
> On Feb 3, 2017, at 1:00 PM, David Jencks <da...@gmail.com> wrote:
>
> I agree, this should work, and there is a bug. Whether anyone will succeed in fixing it is another question.
>
> One thing to investigate might be what happens if you have 2 pids A and B, with identical configurations, one for blueprint and one for DS. What happens when you first update A then B, or B then A? I suspect what is happening is that the configuration change is triggering an asynchronous blueprint container restart, and during this restart the DS component recycles, and the blueprint container doesn’t deal properly with service changes while it is starting. (It was extremely tricky to get DS to do this properly). So, I suspect it doesn’t actually have to do with configuration at all, just timing.
>
> david jencks
>
>> On Feb 3, 2017, at 7:40 AM, Tim Ward <ti...@paremus.com> wrote:
>>
>> I disagree with the earlier statement that Blueprint and DS cannot coexist in the same bundle. I have thought quite hard about this and can think of no reason whatsoever why it should not work.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>>> On 3 Feb 2017, at 15:28, Christian Schneider <ch...@die-schneider.net> wrote:
>>>
>>> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>>>
>>> Christian
>>>
>>>> On 03.02.2017 16:13, Alex Soto wrote:
>>>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>>>
>>>> Best regards,
>>>>
>>>> Alex soto
>>>> alex.soto@envieta.com
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>
Re: DS components not Active
Posted by David Jencks <da...@gmail.com>.
I agree, this should work, and there is a bug. Whether anyone will succeed in fixing it is another question.
One thing to investigate might be what happens if you have 2 pids A and B, with identical configurations, one for blueprint and one for DS. What happens when you first update A then B, or B then A? I suspect what is happening is that the configuration change is triggering an asynchronous blueprint container restart, and during this restart the DS component recycles, and the blueprint container doesn’t deal properly with service changes while it is starting. (It was extremely tricky to get DS to do this properly). So, I suspect it doesn’t actually have to do with configuration at all, just timing.
david jencks
> On Feb 3, 2017, at 7:40 AM, Tim Ward <ti...@paremus.com> wrote:
>
> I disagree with the earlier statement that Blueprint and DS cannot coexist in the same bundle. I have thought quite hard about this and can think of no reason whatsoever why it should not work.
>
> Tim
>
> Sent from my iPhone
>
>> On 3 Feb 2017, at 15:28, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>>
>> Christian
>>
>>> On 03.02.2017 16:13, Alex Soto wrote:
>>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>>
>>> Best regards,
>>>
>>> Alex soto
>>> alex.soto@envieta.com
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
Re: DS components not Active
Posted by Tim Ward <ti...@paremus.com>.
I disagree with the earlier statement that Blueprint and DS cannot coexist in the same bundle. I have thought quite hard about this and can think of no reason whatsoever why it should not work.
Tim
Sent from my iPhone
> On 3 Feb 2017, at 15:28, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I fully agree. I never understood why this decision was made for config admin. In newer versions of the spec it now is possible to share configs but in practice I had lots of problems with it. Still sometimes a common service can help.
>
> Christian
>
>> On 03.02.2017 16:13, Alex Soto wrote:
>> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>>
>> Best regards,
>>
>> Alex soto
>> alex.soto@envieta.com
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: DS components not Active
Posted by Christian Schneider <ch...@die-schneider.net>.
I fully agree. I never understood why this decision was made for config
admin. In newer versions of the spec it now is possible to share configs
but in practice I had lots of problems with it. Still sometimes a common
service can help.
Christian
On 03.02.2017 16:13, Alex Soto wrote:
> No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
>
> Best regards,
>
> Alex soto
> alex.soto@envieta.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
No, services should be small and highly cohesive. Just because they need the same configuration setting, it does not mean they provide the same functionality or should be combined. This CM limitation is actually pushing for bigger less cohesive services. I am disappointed having invested in the CM for configuration, and it will cause me painful project delays now.
Best regards,
Alex soto
alex.soto@envieta.com
> On Feb 3, 2017, at 10:04 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> In most cases sharing the same pid means you have some duplication in functionality. So maybe you can have a service that is configured using this pid and that provides functionality for both.
>
> Christian
>
> On 03.02.2017 16:01, Alex Soto wrote:
>> Thanks, although I am curious why this would be.
>>
>> This puts me in quite a predicament, on the one side, two bundles referencing the same PID does not work, and on the other, DS and Blueprint can't coexisting in the same bundle. The only path I see is to not use the Configuration Manager at all, loosing the auto-reload, or to separate DS and Blueprint in two bundles, with two different configuration PIDs having the same settings, leading to redundant configurations. Not good either way.
>>
>>
>> Best regards,
>> Alex soto
>>
>>
>>> On Feb 3, 2017, at 9:22 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>>
>>> As long as it is not in the same bundles mixing DS and blueprint is fine.
>>>
>>> I guess that using the same config pid in two bundles or two frameworks is the main problem. I had lots of problems when I tried this.
>>> Theoretically sharing a config pid can work now as far as I know but I would not bet on it.
>>>
>>> Christian
>>>
>>> On 03.02.2017 15:19, Alex Soto wrote:
>>>> As far as I can tell, the problem occurs regardless of wether the DS component is (or not) in a separate bundle.
>>>> My project is a mix of Camel routes defined in Blueprint DSL with some of the Camel routes calling services defined as DS components.
>>>> Is this not a common/valid scenario?
>>>>
>>>> Best regards,
>>>> Alex soto
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: DS components not Active
Posted by Christian Schneider <ch...@die-schneider.net>.
In most cases sharing the same pid means you have some duplication in
functionality. So maybe you can have a service that is configured using
this pid and that provides functionality for both.
Christian
On 03.02.2017 16:01, Alex Soto wrote:
> Thanks, although I am curious why this would be.
>
> This puts me in quite a predicament, on the one side, two bundles referencing the same PID does not work, and on the other, DS and Blueprint can't coexisting in the same bundle. The only path I see is to not use the Configuration Manager at all, loosing the auto-reload, or to separate DS and Blueprint in two bundles, with two different configuration PIDs having the same settings, leading to redundant configurations. Not good either way.
>
>
> Best regards,
> Alex soto
>
>
>> On Feb 3, 2017, at 9:22 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> As long as it is not in the same bundles mixing DS and blueprint is fine.
>>
>> I guess that using the same config pid in two bundles or two frameworks is the main problem. I had lots of problems when I tried this.
>> Theoretically sharing a config pid can work now as far as I know but I would not bet on it.
>>
>> Christian
>>
>> On 03.02.2017 15:19, Alex Soto wrote:
>>> As far as I can tell, the problem occurs regardless of wether the DS component is (or not) in a separate bundle.
>>> My project is a mix of Camel routes defined in Blueprint DSL with some of the Camel routes calling services defined as DS components.
>>> Is this not a common/valid scenario?
>>>
>>> Best regards,
>>> Alex soto
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
Thanks, although I am curious why this would be.
This puts me in quite a predicament, on the one side, two bundles referencing the same PID does not work, and on the other, DS and Blueprint can't coexisting in the same bundle. The only path I see is to not use the Configuration Manager at all, loosing the auto-reload, or to separate DS and Blueprint in two bundles, with two different configuration PIDs having the same settings, leading to redundant configurations. Not good either way.
Best regards,
Alex soto
> On Feb 3, 2017, at 9:22 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> As long as it is not in the same bundles mixing DS and blueprint is fine.
>
> I guess that using the same config pid in two bundles or two frameworks is the main problem. I had lots of problems when I tried this.
> Theoretically sharing a config pid can work now as far as I know but I would not bet on it.
>
> Christian
>
> On 03.02.2017 15:19, Alex Soto wrote:
>> As far as I can tell, the problem occurs regardless of wether the DS component is (or not) in a separate bundle.
>> My project is a mix of Camel routes defined in Blueprint DSL with some of the Camel routes calling services defined as DS components.
>> Is this not a common/valid scenario?
>>
>> Best regards,
>> Alex soto
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: DS components not Active
Posted by Christian Schneider <ch...@die-schneider.net>.
As long as it is not in the same bundles mixing DS and blueprint is fine.
I guess that using the same config pid in two bundles or two frameworks
is the main problem. I had lots of problems when I tried this.
Theoretically sharing a config pid can work now as far as I know but I
would not bet on it.
Christian
On 03.02.2017 15:19, Alex Soto wrote:
> As far as I can tell, the problem occurs regardless of wether the DS
> component is (or not) in a separate bundle.
> My project is a mix of Camel routes defined in Blueprint DSL with some
> of the Camel routes calling services defined as DS components.
> Is this not a common/valid scenario?
>
> Best regards,
> Alex soto
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
As far as I can tell, the problem occurs regardless of wether the DS component is (or not) in a separate bundle.
My project is a mix of Camel routes defined in Blueprint DSL with some of the Camel routes calling services defined as DS components.
Is this not a common/valid scenario?
Best regards,
Alex soto
> On Feb 3, 2017, at 9:11 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> Is there any good reason for using DS and blueprint in the same bundle. While it can work we never test this case and recommend to not mix two DI frameworks in the same bundle.
>
> Christian
>
>
> On 03.02.2017 14:42, Alex Soto 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
>
> --
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>
Re: DS components not Active
Posted by Christian Schneider <ch...@die-schneider.net>.
Is there any good reason for using DS and blueprint in the same bundle.
While it can work we never test this case and recommend to not mix two
DI frameworks in the same bundle.
Christian
On 03.02.2017 14:42, Alex Soto wrote:
> Yes, I hear you, I\u2019ve 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\u2019s /immediate /attribute is true
> or false; it fails in both cases.
>
> Best regards,
> Alex soto
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DS components not Active
Posted by Timothy Ward <ti...@paremus.com>.
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 <al...@envieta.com> 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 <tim.ward@paremus.com <ma...@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.soto@envieta.com <ma...@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.ward@paremus.com <ma...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
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 <ti...@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.soto@envieta.com <ma...@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.ward@paremus.com <ma...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: DS components not Active
Posted by Tim Ward <ti...@paremus.com>.
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 <al...@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 <ti...@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 <al...@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 <da...@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 <al...@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 <da...@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 <al...@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> 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 <al...@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
>>>>>>>>
>>>>>>>> Open Source Architect
>>>>>>>> http://www.talend.com
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
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 <ti...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>>>>>
>>>>
>>>
>>
>
Re: DS components not Active
Posted by Timothy Ward <ti...@paremus.com>.
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 <al...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>>>>
>>>
>>
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
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 <da...@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.soto@envieta.com <ma...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>>>
>>
>
Re: DS components not Active
Posted by David Jencks <da...@gmail.com>.
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 <al...@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.jencks@gmail.com <ma...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>>
>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
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 <da...@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.soto@envieta.com <ma...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
>
Re: DS components not Active
Posted by David Jencks <da...@gmail.com>.
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 <al...@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 <chris@die-schneider.net <ma...@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.soto@envieta.com <ma...@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>
Re: DS components not Active
Posted by Alex Soto <al...@envieta.com>.
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> 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.soto@envieta.com <ma...@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>
Re: DS components not Active
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <al...@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>