That looks reasonable - you probably want to set a pid too, and to add a
configuration policy of REQUIRED.
Note that the consumer will have to use ServiceObjects to get the right
lifecycle.
Sent from my iPhone
> On 19 Nov 2016, at 21:25, Scott Lewis <sle...@composent.com> wrote:
>
>> On 11/19/2016 11:42 AM, Tim Ward wrote:
>> The multiton pattern simply creates (and potentially registers a a service)
>> a separate component for each factory configuration.
>>
>> If these components are services then they can then be scoped -
>
> Yes, the components are all services.
>
>> if you make the component prototype scoped then you can use a ServiceObjects
>> to create a new instance of the given component for the given configuration
>> on demand.
>
> If I'm understanding you correctly for the OSGi multiton, with DS 1.3 I would
> use something like this
>
> @Designate(factory=true) // ConfigurationFactory
> @Component(scope = ServiceScope.PROTOTYPE) // PrototypeScope
> class ServiceImpl implements Service {
> ...
>
> Yes?
>
> Scott
>
>
>> I think this is the behaviour that you want...
>>
>> Tim
>>
>> Sent from my iPhone
>>
>>> On 19 Nov 2016, at 19:19, Scott Lewis <sle...@composent.com> wrote:
>>>
>>> On 11/19/2016 10:42 AM, Timothy Ward wrote:
>>>>> Question: If I use a component factory as suggested above to create a
>>>>> component instance, is there a straightforward way to associate every
>>>>> newInstance with a separate/new configuration?
>>>> 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.
>>>>
>>>> The thing is - this is almost exactly the multiton pattern, so I can’t
>>>> quite work out why setting the DS service scope to prototype isn’t enough
>>>> for what you want to achieve… I guess I’m just not close enough to the
>>>> detail.
>>> Is there a description and/or example of the multiton pattern usage
>>> somewhere? It was my understanding (from BJ's comment) that prototype
>>> scoped instances shared the same component properties (rather than having
>>> separate properties as per component factory newInstance(props)).
>>>
>>> This use case would like to a) have distinct service properties for every
>>> instance created (i.e. newInstance); b) also be able to configure each
>>> service instance dynamically via config admin.
>>>
>>> Scott
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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
