Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

On Thu, Aug 23, 2018 at 9:20 AM Tim Ward  wrote:

> If you’re using Declarative Services to consume these other dynamic
> references then there is no need to worry.
>
That's what I'm doing.

If you’re trying to programmatically write a prototype scoped service that
> has service dependencies then stop and use DS instead.
>
Wouldn't want to dare trying and really not sure what would be the benefit.
It's really the other way around that is really needed.


> Trying to correctly manage the “unget” chains that need to occur when one
> service in a dependency tree is unregistered is just too hard to be
> worthwhile. Tools like the ServiceTracker can make it tractable, but it
> still leaves you writing huge quantities of messy lifecycle code that’s a
> nightmare to debug.
>
> Also, you are correct that you must not keep using a service instance when
> the service has been unregistered. It is your job to discard that reference
> :).
>
> Tim
>

Thanks again.
Alain

>
> On 23 Aug 2018, at 13:31, Alain Picard  wrote:
>
> Just a small note, I should have stated that my worry is about the unget
> timing. I obviously have a reference to the object and this won't disappear
> by itself, but if that service has other dynamic references that go away
> and I keep using the service, I might be in trouble. But I guess the
> template that I used already had a bit that issue with the supplier (which
> we seldom use).
>
> Alain
>
> On Thu, Aug 23, 2018 at 7:43 AM Alain Picard 
> wrote:
>
>> Tim,
>>
>> Based on your referenced javadoc, some more googling, I used and adapted
>> from our own current tracker and supplier to create some Prototype
>> versions. Tests are showing correct results, but this is not directly using
>> the PrototypeServiceFactory, so I would appreciate a very quick
>> confirmation that I'm not missing anything.
>>
>> Thanks
>>
>> Alain
>>
>>
>> On Wed, Aug 22, 2018 at 11:54 AM Alain Picard 
>> wrote:
>>
>>> Thanks! I actually saw that being called by ComponentServiceObjects
>>> while perusing the code.
>>>
>>> Alain
>>>
>>>
>>> On Wed, Aug 22, 2018 at 11:52 AM Tim Ward  wrote:
>>>
 Registering a prototype service is almost as easy as registering a
 singleton service. Instead of registering a single object you register an
 instance of PrototypeServiceFactory
 .
 This will get called by the framework to get and release instances as
 needed.

 Tim

 On 22 Aug 2018, at 16:49, Alain Picard  wrote:

 Tim,

 This helps quite a bit and clarifies a few points for me. As someone
 who is migrating from a pre-DS environment and dealing with lots of legacy,
 how can prototype scoped services be used outside of DS? That would be
 fantastic. Right now we have a good solution to use singleton services
 outside of DS but not for "factory" type services.

 Thanks
 Alain


 On Wed, Aug 22, 2018 at 11:27 AM Tim Ward  wrote:

> Hi Alain,
>
> A "Prototype scoped" service is one where the client(s) can request an
> arbitrary number of instances of the “same” service, whereas a
> ComponentFactory is a mechanism for the clients to request an arbitrary
> number of differently configured component instances.
>
> From the perspective of the component the key difference is that all
> of the instances of a prototype scoped component have the same component
> properties, and the instances created by the factory component have the
> combination of these component properties *plus* the properties passed to
> the factory.
>
> In some senses prototype scoped services are better because they:
>
>
>- Don’t require the service implementation to use DS (they may
>wish to use something else)
>- Will have satisfied references and configurations (component
>factories can be given configuration which invalidates the registration
>resulting in an error)
>
>
> The main reason that you would use a Component Factory rather than a
> prototype scoped service is if you genuinely want to have different
> specialised configurations for each instance, and it doesn’t make sense to
> use a managed service factory (i.e. the customised instances are only
> interesting to one client, or must not be shared for some reason).
>
> If your instances are identically configured (or can be, with an init
> later) then a ComponentServiceObjects getService() call should be all you
> need each time you need a new instance, followed by a call to
> ungetService() later when you’re done with it.
>
> Tim
>
> On 22 Aug 2018, at 12:06, Alain Picard  wrote:
>
> On the 2nd part of the question regarding
> ComponentFactory/ComponentInstance vs Prototype/ComponentServiceObjects. I
> get the feeling that CSO should be favored, 

Re: [osgi-dev] Disposing component instances

[Tim Ward via osgi-dev]

If you’re using Declarative Services to consume these other dynamic references 
then there is no need to worry. If you’re trying to programmatically write a 
prototype scoped service that has service dependencies then stop and use DS 
instead. Trying to correctly manage the “unget” chains that need to occur when 
one service in a dependency tree is unregistered is just too hard to be 
worthwhile. Tools like the ServiceTracker can make it tractable, but it still 
leaves you writing huge quantities of messy lifecycle code that’s a nightmare 
to debug.

Also, you are correct that you must not keep using a service instance when the 
service has been unregistered. It is your job to discard that reference :).

Tim

> On 23 Aug 2018, at 13:31, Alain Picard  wrote:
> 
> Just a small note, I should have stated that my worry is about the unget 
> timing. I obviously have a reference to the object and this won't disappear 
> by itself, but if that service has other dynamic references that go away and 
> I keep using the service, I might be in trouble. But I guess the template 
> that I used already had a bit that issue with the supplier (which we seldom 
> use).
> 
> Alain
> 
> On Thu, Aug 23, 2018 at 7:43 AM Alain Picard  > wrote:
> Tim,
> 
> Based on your referenced javadoc, some more googling, I used and adapted from 
> our own current tracker and supplier to create some Prototype versions. Tests 
> are showing correct results, but this is not directly using the 
> PrototypeServiceFactory, so I would appreciate a very quick confirmation that 
> I'm not missing anything.
> 
> Thanks
> 
> Alain
> 
> 
> On Wed, Aug 22, 2018 at 11:54 AM Alain Picard  > wrote:
> Thanks! I actually saw that being called by ComponentServiceObjects while 
> perusing the code.
> 
> Alain
> 
> 
> On Wed, Aug 22, 2018 at 11:52 AM Tim Ward  > wrote:
> Registering a prototype service is almost as easy as registering a singleton 
> service. Instead of registering a single object you register an instance of 
> PrototypeServiceFactory 
> .
>  This will get called by the framework to get and release instances as needed.
> 
> Tim
> 
>> On 22 Aug 2018, at 16:49, Alain Picard > > wrote:
>> 
>> Tim,
>> 
>> This helps quite a bit and clarifies a few points for me. As someone who is 
>> migrating from a pre-DS environment and dealing with lots of legacy, how can 
>> prototype scoped services be used outside of DS? That would be fantastic. 
>> Right now we have a good solution to use singleton services outside of DS 
>> but not for "factory" type services.
>> 
>> Thanks
>> Alain
>> 
>> 
>> On Wed, Aug 22, 2018 at 11:27 AM Tim Ward > > wrote:
>> Hi Alain,
>> 
>> A "Prototype scoped" service is one where the client(s) can request an 
>> arbitrary number of instances of the “same” service, whereas a 
>> ComponentFactory is a mechanism for the clients to request an arbitrary 
>> number of differently configured component instances.
>> 
>> From the perspective of the component the key difference is that all of the 
>> instances of a prototype scoped component have the same component 
>> properties, and the instances created by the factory component have the 
>> combination of these component properties *plus* the properties passed to 
>> the factory.
>> 
>> In some senses prototype scoped services are better because they:
>> 
>> Don’t require the service implementation to use DS (they may wish to use 
>> something else)
>> Will have satisfied references and configurations (component factories can 
>> be given configuration which invalidates the registration resulting in an 
>> error)
>> 
>> The main reason that you would use a Component Factory rather than a 
>> prototype scoped service is if you genuinely want to have different 
>> specialised configurations for each instance, and it doesn’t make sense to 
>> use a managed service factory (i.e. the customised instances are only 
>> interesting to one client, or must not be shared for some reason).
>> 
>> If your instances are identically configured (or can be, with an init later) 
>> then a ComponentServiceObjects getService() call should be all you need each 
>> time you need a new instance, followed by a call to ungetService() later 
>> when you’re done with it.
>> 
>> Tim
>> 
>>> On 22 Aug 2018, at 12:06, Alain Picard >> > wrote:
>>> 
>>> On the 2nd part of the question regarding 
>>> ComponentFactory/ComponentInstance vs Prototype/ComponentServiceObjects. I 
>>> get the feeling that CSO should be favored, but I saw an old post from 
>>> Scott Lewis about configuration and that is a bit close to some of my use 
>>> cases.
>>> 
>>> I have cases where I have a Factory component that delivers instances and 
>>> calls an init method to configure the 

Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

Just a small note, I should have stated that my worry is about the unget
timing. I obviously have a reference to the object and this won't disappear
by itself, but if that service has other dynamic references that go away
and I keep using the service, I might be in trouble. But I guess the
template that I used already had a bit that issue with the supplier (which
we seldom use).

Alain

On Thu, Aug 23, 2018 at 7:43 AM Alain Picard  wrote:

> Tim,
>
> Based on your referenced javadoc, some more googling, I used and adapted
> from our own current tracker and supplier to create some Prototype
> versions. Tests are showing correct results, but this is not directly using
> the PrototypeServiceFactory, so I would appreciate a very quick
> confirmation that I'm not missing anything.
>
> Thanks
>
> Alain
>
>
> On Wed, Aug 22, 2018 at 11:54 AM Alain Picard 
> wrote:
>
>> Thanks! I actually saw that being called by ComponentServiceObjects while
>> perusing the code.
>>
>> Alain
>>
>>
>> On Wed, Aug 22, 2018 at 11:52 AM Tim Ward  wrote:
>>
>>> Registering a prototype service is almost as easy as registering a
>>> singleton service. Instead of registering a single object you register an
>>> instance of PrototypeServiceFactory
>>> .
>>> This will get called by the framework to get and release instances as
>>> needed.
>>>
>>> Tim
>>>
>>> On 22 Aug 2018, at 16:49, Alain Picard  wrote:
>>>
>>> Tim,
>>>
>>> This helps quite a bit and clarifies a few points for me. As someone who
>>> is migrating from a pre-DS environment and dealing with lots of legacy, how
>>> can prototype scoped services be used outside of DS? That would be
>>> fantastic. Right now we have a good solution to use singleton services
>>> outside of DS but not for "factory" type services.
>>>
>>> Thanks
>>> Alain
>>>
>>>
>>> On Wed, Aug 22, 2018 at 11:27 AM Tim Ward  wrote:
>>>
 Hi Alain,

 A "Prototype scoped" service is one where the client(s) can request an
 arbitrary number of instances of the “same” service, whereas a
 ComponentFactory is a mechanism for the clients to request an arbitrary
 number of differently configured component instances.

 From the perspective of the component the key difference is that all of
 the instances of a prototype scoped component have the same component
 properties, and the instances created by the factory component have the
 combination of these component properties *plus* the properties passed to
 the factory.

 In some senses prototype scoped services are better because they:


- Don’t require the service implementation to use DS (they may wish
to use something else)
- Will have satisfied references and configurations (component
factories can be given configuration which invalidates the registration
resulting in an error)


 The main reason that you would use a Component Factory rather than a
 prototype scoped service is if you genuinely want to have different
 specialised configurations for each instance, and it doesn’t make sense to
 use a managed service factory (i.e. the customised instances are only
 interesting to one client, or must not be shared for some reason).

 If your instances are identically configured (or can be, with an init
 later) then a ComponentServiceObjects getService() call should be all you
 need each time you need a new instance, followed by a call to
 ungetService() later when you’re done with it.

 Tim

 On 22 Aug 2018, at 12:06, Alain Picard  wrote:

 On the 2nd part of the question regarding
 ComponentFactory/ComponentInstance vs Prototype/ComponentServiceObjects. I
 get the feeling that CSO should be favored, but I saw an old post from
 Scott Lewis about configuration and that is a bit close to some of my use
 cases.

 I have cases where I have a Factory component that delivers instances
 and calls an init method to configure the component, or might sometimes
 return an existing matching one that is already cached (like per data
 connection instances). With ComponentFactory I can create a new instance,
 call init on the new instance and return the ComponentInstance. The caller
 can then call getInstance and call dispose when done. I struggle to find a
 correct/easy way to do this with CSO. Am I using the best approach or not?

 Thanks
 Alain


 On Wed, Aug 22, 2018 at 3:46 AM Tim Ward via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

>
>
> On 21 Aug 2018, at 20:53, Paul F Fraser via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> On 22/08/2018 5:40 AM, Paul F Fraser via osgi-dev wrote:
>
> On 21/08/2018 10:00 PM, Tim Ward via osgi-dev wrote:
>
> Have you looked at what the OSC project does? It uses Vaadin, and uses

Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

Tim,

Based on your referenced javadoc, some more googling, I used and adapted
from our own current tracker and supplier to create some Prototype
versions. Tests are showing correct results, but this is not directly using
the PrototypeServiceFactory, so I would appreciate a very quick
confirmation that I'm not missing anything.

Thanks

Alain


On Wed, Aug 22, 2018 at 11:54 AM Alain Picard  wrote:

> Thanks! I actually saw that being called by ComponentServiceObjects while
> perusing the code.
>
> Alain
>
>
> On Wed, Aug 22, 2018 at 11:52 AM Tim Ward  wrote:
>
>> Registering a prototype service is almost as easy as registering a
>> singleton service. Instead of registering a single object you register an
>> instance of PrototypeServiceFactory
>> .
>> This will get called by the framework to get and release instances as
>> needed.
>>
>> Tim
>>
>> On 22 Aug 2018, at 16:49, Alain Picard  wrote:
>>
>> Tim,
>>
>> This helps quite a bit and clarifies a few points for me. As someone who
>> is migrating from a pre-DS environment and dealing with lots of legacy, how
>> can prototype scoped services be used outside of DS? That would be
>> fantastic. Right now we have a good solution to use singleton services
>> outside of DS but not for "factory" type services.
>>
>> Thanks
>> Alain
>>
>>
>> On Wed, Aug 22, 2018 at 11:27 AM Tim Ward  wrote:
>>
>>> Hi Alain,
>>>
>>> A "Prototype scoped" service is one where the client(s) can request an
>>> arbitrary number of instances of the “same” service, whereas a
>>> ComponentFactory is a mechanism for the clients to request an arbitrary
>>> number of differently configured component instances.
>>>
>>> From the perspective of the component the key difference is that all of
>>> the instances of a prototype scoped component have the same component
>>> properties, and the instances created by the factory component have the
>>> combination of these component properties *plus* the properties passed to
>>> the factory.
>>>
>>> In some senses prototype scoped services are better because they:
>>>
>>>
>>>- Don’t require the service implementation to use DS (they may wish
>>>to use something else)
>>>- Will have satisfied references and configurations (component
>>>factories can be given configuration which invalidates the registration
>>>resulting in an error)
>>>
>>>
>>> The main reason that you would use a Component Factory rather than a
>>> prototype scoped service is if you genuinely want to have different
>>> specialised configurations for each instance, and it doesn’t make sense to
>>> use a managed service factory (i.e. the customised instances are only
>>> interesting to one client, or must not be shared for some reason).
>>>
>>> If your instances are identically configured (or can be, with an init
>>> later) then a ComponentServiceObjects getService() call should be all you
>>> need each time you need a new instance, followed by a call to
>>> ungetService() later when you’re done with it.
>>>
>>> Tim
>>>
>>> On 22 Aug 2018, at 12:06, Alain Picard  wrote:
>>>
>>> On the 2nd part of the question regarding
>>> ComponentFactory/ComponentInstance vs Prototype/ComponentServiceObjects. I
>>> get the feeling that CSO should be favored, but I saw an old post from
>>> Scott Lewis about configuration and that is a bit close to some of my use
>>> cases.
>>>
>>> I have cases where I have a Factory component that delivers instances
>>> and calls an init method to configure the component, or might sometimes
>>> return an existing matching one that is already cached (like per data
>>> connection instances). With ComponentFactory I can create a new instance,
>>> call init on the new instance and return the ComponentInstance. The caller
>>> can then call getInstance and call dispose when done. I struggle to find a
>>> correct/easy way to do this with CSO. Am I using the best approach or not?
>>>
>>> Thanks
>>> Alain
>>>
>>>
>>> On Wed, Aug 22, 2018 at 3:46 AM Tim Ward via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>


 On 21 Aug 2018, at 20:53, Paul F Fraser via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

 On 22/08/2018 5:40 AM, Paul F Fraser via osgi-dev wrote:

 On 21/08/2018 10:00 PM, Tim Ward via osgi-dev wrote:

 Have you looked at what the OSC project does? It uses Vaadin, and uses
 the ViewProvider interface to provide view instances. These automatically
 have a detach listener added on creation so that they get correctly
 disposed when their parent container is closed.

 See
 https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L60-L67
  for
 details.

 Tim


 Hi Tim,
 The R7 Spec 112.3.6 states that "SCR must unget any unreleased service
 objects" and it sounds to me that 

Re: [osgi-dev] Retrieving service configuration implementation in reference method

[Tim Ward via osgi-dev]

The properties visible in the Map (or ServiceReference) are the service 
properties. There is some overlap with configuration (services that are 
configurable are encouraged to publish configuration properties as service 
properties) but they are separate, and can be different.

The only way that something becomes a service property is if it is deliberately 
registered as such or, for a few specific properties such as service.id and 
service.scope, added automatically by the framework. 

The class name of the implementation would only be added as a service property 
if done so deliberately, and this is typically discouraged (it leaks internal 
implementation detail and forces your internal naming to become API). If you 
*really* care about the details of a service (and in general you shouldn’t) 
then you should mark it with a service property that you can recognise. Ideally 
one that is separate from the other implementation details of the service.

Best Regards,

Tim

> On 22 Aug 2018, at 16:53, Alain Picard via osgi-dev  
> wrote:
> 
> In a reference method, i can get the property configuration of the service 
> along with the ComponentFactory and some other optional arguments. Can any of 
> those give me a way to retrieve the implementation from the configuration 
> (i.e. the class name of the implementation) ?
> 
> Thanks
> Alain
> 
> ___
> 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