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:[email protected]] Sent: Wednesday, December 18, 2013 2:33 AM To: [email protected] 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" <[email protected]> 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:[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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
