As I tried to explain earlier (but insufficiently well) there are two parallel things that you need to do:
First, and most importantly, use factory configurations to get your “many configurations behaviour”. This is how you get a separate configuration associated with each service instance for a single DS component. Each factory configuration maps to a separately registered service. When you want the service with the given configuration you get it from the service registry. You can inject all of these services into some other component using a multiple cardinality reference. Second - to get the lifecycle you want you should register your configurable component with PROTOTYPE scope. This way a client can use ServiceObjects to get its own instance on demand. As you have seen, multiple requests to the same ServiceObjects will give you multiple instances with the same configuration. In the use case you have described you want to be injected with *all* of the Service Objects and to get one of each of them from each registered service. I hope this helps, Tim > On 21 Nov 2016, at 15:32, Scott Lewis <sle...@composent.com> wrote: > > On 11/21/2016 12:50 AM, Timothy Ward wrote: >> <stuff deleted> > > Any thoughts/comments about method for getting a distinct configuration > associated with every service instance? > >>>> This is fine for my use case WRT creating service instances on demand via >>>> the FooConsumer. However, I would like to be able to have a distinct/new >>>> configuration associated with each new FooImpl, rather than a single >>>> FooConfig instance assigned to all of them. Is this possible using the >>>> PROTOTYPE pattern, or is it necessary to use the ComponentFactory in the >>>> manner Tim describes to accomplish this: >>>> >>>> The way that this is done is to pass the configuration using the >>>> newInstance method. Effectively your pattern would be to register a >>>> ConfigurationListener or ManagedServiceFactory, passing the configuration >>>> Dictionary to the Component Factory for each Factory Configuration. > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
