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:[email protected]] Sent: Friday, December 27, 2013 7:51 PM To: [email protected] 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" <[email protected]> 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:[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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
