I don’t think I understand your question….. configuration-policy and scope are independent or orthogonal. One way to see this is to note that configuration-policy applies whether or not the component exposes a service, whereas scope only applies when the component exposes a service.
You never want to use configuration-policy OPTIONAL with a factory pid :-). So, starting with the assumption that you are using a factoryPid, each configuration will result in one “component”. Each configuration using the factoryPid will have a unique pid. Now: if the scope is - SINGLETON then every lookup of a component using the same pid will get the same object instance. - BUNDLE then every lookup of a component using the same pid from the same bundle will get the same object instance, but lookups from different bundles will get different instances, all configured the same (using the unique configuration with the pid) - PROTOTYPE then every lookup of a component using the same pid from the ServiceObjects interface will get a different instance, all configured using the unique configuration with the pid. If the client is a DS component, you can control wether the reference is looked up using the ServiceReference or ServiceObjects by specifying the ReferenceScope as BUNDLE or PROTOTYPE respectively. (or inject the ComponentServcieObjects) So, lets say you magically know the pids of all the configurations you’ve created with your factory pid, and they are pid_1, pid_2, etc. Typically you’d configure the client with a configuration including a target filter for the reference so it gets the one you want, e.g. MyReference.target=(service.pid=pid_42) If this client has prototype scope, and the reference has prototype scope, and the target service has prototype scope, then each instance of the client configured with this target filter will get a unique copy of the referred-to service. I don’t really understand your description of what you want. If you want even more copies of the referred-to-service, each configured differently on a “ ookup", maybe you are looking for a ComponentFactory? Then the client can supply the configuration for the referred-to service itself. However spec ComponentFactories have a peculiar and IMO useless lifecycle, so felix ds implements an extended lifecycle that better matches regular components. Hope this helps…. david jencks > On Apr 8, 2016, at 12:57 AM, Jens Offenbach <[email protected]> wrote: > > Hallo, > I am making intensive use of the DS pattern that allows us to couple a single > configuration to a single component instance using a Managed Service Factory > PID. Is it possible to combine this pattern e.g. with the prototype scope? Is > there a way to achieve that for every service lookup a new component instance > is created (prototype scope) and force at the same time that this component > requires an individual configuration? > > Does the "multiple component instances" pattern only require that someone > uses a Managed Service Factory PID in combination with > "ConfigurationPolicy.REQUIRE" instead of single a Managed Service PID? > > To make it more clear: > When I use this annotation fragment "configurationPolicy = > ConfigurationPolicy.REQUIRE" and use a Managed Service Factory PID, does this > ensure that a component instance must always have an individual configuration > or are there any interdependencies to other attributes, like "scope"? > > When I use "ServiceScope.PROTOTYPE" and "ConfigurationPolicy.REQUIRE", but > use a PID instead of a Managed Service Factory PID, does this mean, that we > have multiple component instances, all using the same configuration? > > Thanks a lot for your help! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
