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:[email protected]] Sent: Tuesday, December 17, 2013 6:02 PM To: [email protected] 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" <[email protected]> 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:[email protected]] > Sent: Tuesday, December 17, 2013 3:45 PM > To: [email protected] > 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" > <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
