You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Humeniuk, David P" <Da...@udri.udayton.edu> on 2013/12/17 21:32:05 UTC
uses ComponentInstances as part of the Declarative Services
specification
We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
Thanks,
Dave Humeniuk
RE: uses ComponentInstances as part of the Declarative Services
specification
Posted by "Humeniuk, David P" <Da...@udri.udayton.edu>.
I finally had the chance to test this with SCR 1.8 and it seems the behavior is indeed different. If the component relies on an optional, static service, the component instance will NOT be recreated by the SCR. If the optional service was previously there and unregistered, the component instance will be deactivated, but another will not be created (unlike 1.6.2). Also, if the optional service was not available and then later registered, the component instance will not be deactivated (again, unlike 1.6.2) and the previous instance will continue to exist, still not able to access the optional static service (even though it is there).
Therefore, it sounds like it is working according to how you described the spec.
I finally figured out how bind a factory configuration to a component. I always thought before there would only be a single component created unless it was a factory component. I didn't realize a configuration factory would also create multiple components. The specification (at least 4.x version) is not entirely clear about this, but I thinks utilizing this will help as that's really what we are wanting to do with these multiple instances of components.
Thanks,
Dave
-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Friday, December 27, 2013 7:51 PM
To: users@felix.apache.org
Subject: Re: uses ComponentInstances as part of the Declarative Services specification
Hi David,
I consulted the expert group and the behavior I think you originally described is not spec compliant (what I think the behavior was might or might not be what you were describing). I'll be writing some tests to assure that spec compliance is enforced. Once something happens to deactivate the implementation instance, such as an optional static reference going away, that component instance can never be used for anything again, you have to call newInstance again to get a new one.
I'm planning to implement an extension to felix ds that will act differently, and also propose a spec modification to support it, but I wouldn't hold your breath.
For clarity, let be describe something that does work but is not widely explained comprehensibly and might be what you need.
Lets say you have a component
@Component(configurationPid="myFooId")
public MyFoo {
...
}
Whenever you create a factory configuration in config admin
Configuration cfg = configAdmin.createFactoryConfiguration("myFooId");
and give it some properties
cfg.setProperties(new Hashtable());
a new instance of the MyFoo component will be created and configured with the properties you set (here, nothing). It's difficult to come up with a good name for this situation because this behavior relies on the DS component having a pid specified, but the config admin user deciding whether to create a single configuration (confgiAdmin.getConfiguration(pid), you'll only ever get a single instance) or factory configurations (as above, in which case you'll get as many instances as factory configurations you create).
So if you have a factory configuration for factory pid "myFactoryPid" but need to do some computation on the properties before deciding whether to use it to create a component, you can register a managed service factory (perhaps as a single DS component) that will receive and process the factory configurations, and if appropriate create additional factory configurations using say "myProcessedFactoryPid". Then register a DS component with configurationPid "myProcessedFactoryPid" and each such configuration will result in a DS component instance that behaves reasonably.... e.g. if an optional static reference disappears, the original instance will be discarded and a new one created to replace it. ( a service registration will be unregistered and reregistered to notify clients that they need to get the new instance).
Hope this helps. This situation is difficult to talk about clearly, I don't have a lot of confidence I'm succeeding better, but keep asking questions....
thanks
david jencks
On Dec 26, 2013, at 7:17 AM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> Trying to understand what you mean by the multiple pids explained below. The component that needs to be configured is a factory component and each instance needs to support a different configuration. From what I understand, that is not supported by OSGi so we have added are own handling of ManagedServiceFactory(ies) that will call on the component instance when properties are updated. It would be nice if this was supported by the spec in some way.
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 6:02 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> DS is certainly not ignoring the static reference policy.
>
> I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
>
> When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
>
> If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
>
> -----
> Is this what you are seeing? If not, how do you know something else is happening?
>
> -----
> This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
>
> Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
>
> thanks!
> david jencks
>
>
> On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>>
>> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>>
>> Thanks,
>> Dave
>>
>> -----Original Message-----
>> From: David Jencks [mailto:david_jencks@yahoo.com]
>> Sent: Tuesday, December 17, 2013 3:45 PM
>> To: users@felix.apache.org
>> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>>
>> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>>
>> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>>
>> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>>
>> thanks
>> david jencks
>>
>> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>>
>>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>>
>>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>>
>>> Thanks,
>>> Dave Humeniuk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: uses ComponentInstances as part of the Declarative Services specification
Posted by David Jencks <da...@yahoo.com>.
Hi David,
I consulted the expert group and the behavior I think you originally described is not spec compliant (what I think the behavior was might or might not be what you were describing). I'll be writing some tests to assure that spec compliance is enforced. Once something happens to deactivate the implementation instance, such as an optional static reference going away, that component instance can never be used for anything again, you have to call newInstance again to get a new one.
I'm planning to implement an extension to felix ds that will act differently, and also propose a spec modification to support it, but I wouldn't hold your breath.
For clarity, let be describe something that does work but is not widely explained comprehensibly and might be what you need.
Lets say you have a component
@Component(configurationPid="myFooId")
public MyFoo {
…
}
Whenever you create a factory configuration in config admin
Configuration cfg = configAdmin.createFactoryConfiguration("myFooId");
and give it some properties
cfg.setProperties(new Hashtable());
a new instance of the MyFoo component will be created and configured with the properties you set (here, nothing). It's difficult to come up with a good name for this situation because this behavior relies on the DS component having a pid specified, but the config admin user deciding whether to create a single configuration (confgiAdmin.getConfiguration(pid), you'll only ever get a single instance) or factory configurations (as above, in which case you'll get as many instances as factory configurations you create).
So if you have a factory configuration for factory pid "myFactoryPid" but need to do some computation on the properties before deciding whether to use it to create a component, you can register a managed service factory (perhaps as a single DS component) that will receive and process the factory configurations, and if appropriate create additional factory configurations using say "myProcessedFactoryPid". Then register a DS component with configurationPid "myProcessedFactoryPid" and each such configuration will result in a DS component instance that behaves reasonably…. e.g. if an optional static reference disappears, the original instance will be discarded and a new one created to replace it. ( a service registration will be unregistered and reregistered to notify clients that they need to get the new instance).
Hope this helps. This situation is difficult to talk about clearly, I don't have a lot of confidence I'm succeeding better, but keep asking questions….
thanks
david jencks
On Dec 26, 2013, at 7:17 AM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> Trying to understand what you mean by the multiple pids explained below. The component that needs to be configured is a factory component and each instance needs to support a different configuration. From what I understand, that is not supported by OSGi so we have added are own handling of ManagedServiceFactory(ies) that will call on the component instance when properties are updated. It would be nice if this was supported by the spec in some way.
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 6:02 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> DS is certainly not ignoring the static reference policy.
>
> I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
>
> When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
>
> If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
>
> -----
> Is this what you are seeing? If not, how do you know something else is happening?
>
> -----
> This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
>
> Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
>
> thanks!
> david jencks
>
>
> On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>>
>> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>>
>> Thanks,
>> Dave
>>
>> -----Original Message-----
>> From: David Jencks [mailto:david_jencks@yahoo.com]
>> Sent: Tuesday, December 17, 2013 3:45 PM
>> To: users@felix.apache.org
>> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>>
>> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>>
>> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>>
>> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>>
>> thanks
>> david jencks
>>
>> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>>
>>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>>
>>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>>
>>> Thanks,
>>> Dave Humeniuk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: uses ComponentInstances as part of the Declarative Services
specification
Posted by "Humeniuk, David P" <Da...@udri.udayton.edu>.
Trying to understand what you mean by the multiple pids explained below. The component that needs to be configured is a factory component and each instance needs to support a different configuration. From what I understand, that is not supported by OSGi so we have added are own handling of ManagedServiceFactory(ies) that will call on the component instance when properties are updated. It would be nice if this was supported by the spec in some way.
-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Tuesday, December 17, 2013 6:02 PM
To: users@felix.apache.org
Subject: Re: uses ComponentInstances as part of the Declarative Services specification
DS is certainly not ignoring the static reference policy.
I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
-----
Is this what you are seeing? If not, how do you know something else is happening?
-----
This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
thanks!
david jencks
On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>
> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 3:45 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>
> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>
> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>
> thanks
> david jencks
>
> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>
>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>
>> Thanks,
>> Dave Humeniuk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: uses ComponentInstances as part of the Declarative Services
specification
Posted by "Humeniuk, David P" <Da...@udri.udayton.edu>.
I wondered if the ComponentInstance would still be valid in that case. I will have to check that out and see that it does return the new instantiation each time. I will also test out 1.8, I didn't realize that just came out.
-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Wednesday, December 18, 2013 2:33 AM
To: users@felix.apache.org
Subject: Re: uses ComponentInstances as part of the Declarative Services specification
I've studied the spec some more and I think that:
-- the component factory service should not be unregistered and reregistered if an optional static reference is removed. I base this on 112.5.5 where it says that the factory service does not bind to any of the references. It remains satisfied while the optional reference is removed, so there seems to be no reason to unregister it.
-- the component created from newInstance should be disposed of and not recreated. I base this on the end of 112.5.5 which says
Once a component configuration created by the Component Factory has been deactivated, that com- ponent configuration will not be reactivated or used again.
Removing an optional static reference causes the configuration to be deactivated, so it should not be reactivated and reused. So I think there's a bug in 1.6.2 here. Before I spend much time investigating would you be able to see if the recent 1.8 release has the same behavior?
I'm not 100% convinced that this is really the intent of the spec. Does anyone else have an idea?
However, with the current behavior, it occurs to me that you might be able to solve your problem by, rather than caching the object returned from ComponentInstance.getInstance, caching the ComponentInstance and retrieving the object each time you want to use it. Then if the object is replaced, you'll get the new one.
Thanks!
david jencks
On Dec 17, 2013, at 5:09 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> What I'm seeing is that the ComponentFactory service instance (referenced by what is called an AssetFactory, i.e., the ComponentFactory will create an Asset type) is not unregistered when the optional static reference goes away. I'm seeing only the component instance itself being recreated (i.e., the Asset). If the ComponentFactory was unregistered that would be good because then my service (the AssetDirectoryService) that keeps track of the instances would be notified as it has a reference to the AssetFactory. However, I'm not see any evidence of the AssetFactory being deactivated (due to its ComponentFactory service reference being unregistered). What I do see is the service provided by the Asset being unregistered and registered again. This makes it look like the component instance is re-created automatically.
>
> As far as configuration goes, I do have the AssetDirectoryService register a ManagedServiceFactory that has some base properties and it adds other properties from the AssetFactory instance. These properties are then made available to the Asset component, but through some helper methods that associate a PID with the Asset instance.
>
> I'm using scr-1.6.2 BTW.
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 6:02 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> DS is certainly not ignoring the static reference policy.
>
> I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
>
> When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
>
> If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
>
> -----
> Is this what you are seeing? If not, how do you know something else is happening?
>
> -----
> This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
>
> Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
>
> thanks!
> david jencks
>
>
> On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>>
>> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>>
>> Thanks,
>> Dave
>>
>> -----Original Message-----
>> From: David Jencks [mailto:david_jencks@yahoo.com]
>> Sent: Tuesday, December 17, 2013 3:45 PM
>> To: users@felix.apache.org
>> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>>
>> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>>
>> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>>
>> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>>
>> thanks
>> david jencks
>>
>> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>>
>>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>>
>>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>>
>>> Thanks,
>>> Dave Humeniuk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: uses ComponentInstances as part of the Declarative Services
specification
Posted by "Humeniuk, David P" <Da...@udri.udayton.edu>.
In trying to get the latest SCR (1.8.0), I noticed the download page (http://felix.apache.org/downloads.cgi) is still pointing to 1.6.2.
-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Wednesday, December 18, 2013 2:33 AM
To: users@felix.apache.org
Subject: Re: uses ComponentInstances as part of the Declarative Services specification
I've studied the spec some more and I think that:
-- the component factory service should not be unregistered and reregistered if an optional static reference is removed. I base this on 112.5.5 where it says that the factory service does not bind to any of the references. It remains satisfied while the optional reference is removed, so there seems to be no reason to unregister it.
-- the component created from newInstance should be disposed of and not recreated. I base this on the end of 112.5.5 which says
Once a component configuration created by the Component Factory has been deactivated, that com- ponent configuration will not be reactivated or used again.
Removing an optional static reference causes the configuration to be deactivated, so it should not be reactivated and reused. So I think there's a bug in 1.6.2 here. Before I spend much time investigating would you be able to see if the recent 1.8 release has the same behavior?
I'm not 100% convinced that this is really the intent of the spec. Does anyone else have an idea?
However, with the current behavior, it occurs to me that you might be able to solve your problem by, rather than caching the object returned from ComponentInstance.getInstance, caching the ComponentInstance and retrieving the object each time you want to use it. Then if the object is replaced, you'll get the new one.
Thanks!
david jencks
On Dec 17, 2013, at 5:09 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> What I'm seeing is that the ComponentFactory service instance (referenced by what is called an AssetFactory, i.e., the ComponentFactory will create an Asset type) is not unregistered when the optional static reference goes away. I'm seeing only the component instance itself being recreated (i.e., the Asset). If the ComponentFactory was unregistered that would be good because then my service (the AssetDirectoryService) that keeps track of the instances would be notified as it has a reference to the AssetFactory. However, I'm not see any evidence of the AssetFactory being deactivated (due to its ComponentFactory service reference being unregistered). What I do see is the service provided by the Asset being unregistered and registered again. This makes it look like the component instance is re-created automatically.
>
> As far as configuration goes, I do have the AssetDirectoryService register a ManagedServiceFactory that has some base properties and it adds other properties from the AssetFactory instance. These properties are then made available to the Asset component, but through some helper methods that associate a PID with the Asset instance.
>
> I'm using scr-1.6.2 BTW.
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 6:02 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> DS is certainly not ignoring the static reference policy.
>
> I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
>
> When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
>
> If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
>
> -----
> Is this what you are seeing? If not, how do you know something else is happening?
>
> -----
> This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
>
> Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
>
> thanks!
> david jencks
>
>
> On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>>
>> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>>
>> Thanks,
>> Dave
>>
>> -----Original Message-----
>> From: David Jencks [mailto:david_jencks@yahoo.com]
>> Sent: Tuesday, December 17, 2013 3:45 PM
>> To: users@felix.apache.org
>> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>>
>> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>>
>> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>>
>> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>>
>> thanks
>> david jencks
>>
>> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>>
>>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>>
>>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>>
>>> Thanks,
>>> Dave Humeniuk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: uses ComponentInstances as part of the Declarative Services specification
Posted by David Jencks <da...@yahoo.com>.
I've studied the spec some more and I think that:
-- the component factory service should not be unregistered and reregistered if an optional static reference is removed. I base this on 112.5.5 where it says that the factory service does not bind to any of the references. It remains satisfied while the optional reference is removed, so there seems to be no reason to unregister it.
-- the component created from newInstance should be disposed of and not recreated. I base this on the end of 112.5.5 which says
Once a component configuration created by the Component Factory has been deactivated, that com- ponent configuration will not be reactivated or used again.
Removing an optional static reference causes the configuration to be deactivated, so it should not be reactivated and reused. So I think there's a bug in 1.6.2 here. Before I spend much time investigating would you be able to see if the recent 1.8 release has the same behavior?
I'm not 100% convinced that this is really the intent of the spec. Does anyone else have an idea?
However, with the current behavior, it occurs to me that you might be able to solve your problem by, rather than caching the object returned from ComponentInstance.getInstance, caching the ComponentInstance and retrieving the object each time you want to use it. Then if the object is replaced, you'll get the new one.
Thanks!
david jencks
On Dec 17, 2013, at 5:09 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> What I'm seeing is that the ComponentFactory service instance (referenced by what is called an AssetFactory, i.e., the ComponentFactory will create an Asset type) is not unregistered when the optional static reference goes away. I'm seeing only the component instance itself being recreated (i.e., the Asset). If the ComponentFactory was unregistered that would be good because then my service (the AssetDirectoryService) that keeps track of the instances would be notified as it has a reference to the AssetFactory. However, I'm not see any evidence of the AssetFactory being deactivated (due to its ComponentFactory service reference being unregistered). What I do see is the service provided by the Asset being unregistered and registered again. This makes it look like the component instance is re-created automatically.
>
> As far as configuration goes, I do have the AssetDirectoryService register a ManagedServiceFactory that has some base properties and it adds other properties from the AssetFactory instance. These properties are then made available to the Asset component, but through some helper methods that associate a PID with the Asset instance.
>
> I'm using scr-1.6.2 BTW.
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 6:02 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> DS is certainly not ignoring the static reference policy.
>
> I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
>
> When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
>
> If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
>
> -----
> Is this what you are seeing? If not, how do you know something else is happening?
>
> -----
> This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
>
> Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
>
> thanks!
> david jencks
>
>
> On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>>
>> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>>
>> Thanks,
>> Dave
>>
>> -----Original Message-----
>> From: David Jencks [mailto:david_jencks@yahoo.com]
>> Sent: Tuesday, December 17, 2013 3:45 PM
>> To: users@felix.apache.org
>> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>>
>> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>>
>> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>>
>> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>>
>> thanks
>> david jencks
>>
>> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>>
>>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>>
>>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>>
>>> Thanks,
>>> Dave Humeniuk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
RE: uses ComponentInstances as part of the Declarative Services
specification
Posted by "Humeniuk, David P" <Da...@udri.udayton.edu>.
What I'm seeing is that the ComponentFactory service instance (referenced by what is called an AssetFactory, i.e., the ComponentFactory will create an Asset type) is not unregistered when the optional static reference goes away. I'm seeing only the component instance itself being recreated (i.e., the Asset). If the ComponentFactory was unregistered that would be good because then my service (the AssetDirectoryService) that keeps track of the instances would be notified as it has a reference to the AssetFactory. However, I'm not see any evidence of the AssetFactory being deactivated (due to its ComponentFactory service reference being unregistered). What I do see is the service provided by the Asset being unregistered and registered again. This makes it look like the component instance is re-created automatically.
As far as configuration goes, I do have the AssetDirectoryService register a ManagedServiceFactory that has some base properties and it adds other properties from the AssetFactory instance. These properties are then made available to the Asset component, but through some helper methods that associate a PID with the Asset instance.
I'm using scr-1.6.2 BTW.
Thanks,
Dave
-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Tuesday, December 17, 2013 6:02 PM
To: users@felix.apache.org
Subject: Re: uses ComponentInstances as part of the Declarative Services specification
DS is certainly not ignoring the static reference policy.
I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
-----
Is this what you are seeing? If not, how do you know something else is happening?
-----
This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
thanks!
david jencks
On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>
> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 3:45 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>
> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>
> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>
> thanks
> david jencks
>
> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>
>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>
>> Thanks,
>> Dave Humeniuk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: uses ComponentInstances as part of the Declarative Services specification
Posted by David Jencks <da...@yahoo.com>.
DS is certainly not ignoring the static reference policy.
I'm slightly confused from your description of what is happening. Here's my understanding of what should be happening:
When you have a factory component, then a ComponentFactory service instance is registered for it whenever the references are satisfied. I think if you have an optional static reference the ComponentFactory service will be unregistered and reregistered.
If in addition the component exposes one or more service interfaces, then whenever you create an instance with component factory.newInstance(props) a service will be registered exposing the component instance. As soon as one of the references causes the instance to need to be deactivated, such as an optional static reference going away, then the service is unregistered and the instance deactivated and disposed of. If you want it back, you have to call newInstance again.
-----
Is this what you are seeing? If not, how do you know something else is happening?
-----
This is remarkably inconvenient since there's no notification from DS that the reference has disappeared and you need to call newInstance again. I'm planning to implement in felix ds a non-spec style of factory component where calling newInstance is pretty much equivalent to using config admin with a factory pid, so the component will be "existing" whether or not all the references are present at any particular time, and the instance will be created and dropped depending on the reference availability. Also you'll be able to modify the config of one of these.
Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid (pid2) configuration with the modified properties. The MSF would be registered under pid1, and your DS component use pid2.
thanks!
david jencks
On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
>
> I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, December 17, 2013 3:45 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>
> There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
>
> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
>
> Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
>
> thanks
> david jencks
>
> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
>
>> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>>
>> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>>
>> Thanks,
>> Dave Humeniuk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: uses ComponentInstances as part of the Declarative Services
specification
Posted by "Humeniuk, David P" <Da...@udri.udayton.edu>.
The component does provide a service and I see that it got registered again, that's what I was using to assume the instance was re-created. Perhaps that is why the component is re-created? The provided service is not for the needed interface for the consumer though so I would have to provide a different/another service.
I'm aware of using config admin and factory pids and I'm using that in a way with these components, but more like a wrapper as I need to add certain properties to all components of this type. Are you saying the life cycle is different for these and the DS runtime would ignore the static policy for the service reference?
Thanks,
Dave
-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Tuesday, December 17, 2013 3:45 PM
To: users@felix.apache.org
Subject: Re: uses ComponentInstances as part of the Declarative Services specification
There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
thanks
david jencks
On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>
> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>
> Thanks,
> Dave Humeniuk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: uses ComponentInstances as part of the Declarative Services specification
Posted by David Jencks <da...@yahoo.com>.
There is no external notification that the instance has been disposed of. Assuming your component has a disposed method, that will get called and you can notify users yourself. But I would definitely recommend using a Service instead.
I'm very surprised that an instance obtained from a ComponentFactory is getting recreate automatically when a static reference becomes unavailable. I would expect you'd have to create the new instance yourself. Are you sure this is what's happening?
Are you aware of how to use config admin with factory pids to create multiple instances of a component? This may not be documented all that well but that generally provides component life cycles that I find more useful.
thanks
david jencks
On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <Da...@udri.udayton.edu> wrote:
> We've been using ComponentFactory's and ComponentInstances in our software for a while when we have a component that we need multiple instances. However, I've noticed that if a component has an optional, static reference, the component will be disposed and activated automatically when the service referenced comes and goes (which is not too surprising based on the meaning of static) meaning the previous instance is no longer valid.
>
> The question is, if I have something that uses that instance, how is it supposed to know about the replaced instance. I'm guessing that the component instance object should not be used in this case and I should instead try have the component provide a service and use the service reference instead?? Is that what is expected or is there some way to be notified about an updated component instance?
>
> Thanks,
> Dave Humeniuk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org