Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

Thanks Raymond

On Sun, Nov 25, 2018, 6:58 PM Raymond Auge  Please note that up to a couple of weeks ago there was a bug in Felix SCR
> managing indirect component prototype instances.
>
> https://issues.apache.org/jira/browse/FELIX-5974
>
> So you may want to make sure you have the latest.
>
> - Ray
>
> On Sun, Nov 25, 2018, 08:21 Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org wrote:
>
>> On Sun, Nov 25, 2018 at 7:50 AM Tim Ward  wrote:
>>
>>> If your DS component ‘X’ is injected with a Component Service Objects
>>> which it uses to get instances ‘A’, ‘B’ and ‘C' of a referenced service
>>> then those service instances will be released when either:
>>>
>>>
>>>- The component ‘X’ releases them by calling ungetService on the
>>>component service objects
>>>
>>> or
>>>
>>>- The component ‘X’ is deactivated (for whatever reason) at which
>>>point the Service Component Runtime will automatically release any
>>>remaining instances that haven’t been released by the component before 
>>> the
>>>end of any deactivate method.
>>>
>>>
>>> This is why the ComponentServiceObjects is a better choice than using a
>>> ServiceObjects directly, as the ServiceObjects won’t clean up after you.
>>>
>>> Can I interpret this and your previous comment as meaning that within a
>>> prototype scope component, a prototype required scope reference doesn't
>>> need to be "unget" manually and it is just the most outer invocation that
>>> should perform the “unget"
>>>
>>>
>>> In a limited way, yes. If you get many instances over the lifetime of
>>> your component ‘X’ then you should probably have a mechanism to unget them
>>> manually, otherwise the memory usage of your component will grow and grow
>>> over time (until it is deactivated). If you get two or three instances of
>>> the prototype service which you then hold for the life of the component ‘X’
>>> then feel free to let DS do all the work.
>>>
>> This is for a composing a UI view which itself has a defined lifespan,
>> but this prototype component creates a number of other prototype scoped
>> components and it would be much easier to such unget the view and not all
>> its parts.
>>
>> Small slant to this question, let's say that X has a reference to Factory
>> A (standard component) and that factory A returns a prototype scoped
>> instance, will ungetting X, release the instance returned by factory A?
>>
>> Alain
>>
>>
>>
>>> Tim
>>>
>>> On 25 Nov 2018, at 12:41, Alain Picard  wrote:
>>>
>>> Tim,
>>>
>>> Circling back on this. Re-reading section 112.3.6 it says "This means
>>> that if a component instance used a Component Service Objects object to
>>> obtain service objects, SCR must track those service objects so that when
>>> the service becomes unbound, SCR can unget any unreleased service objects".
>>>
>>> Can I interpret this and your previous comment as meaning that within a
>>> prototype scope component, a prototype required scope reference doesn't
>>> need to be "unget" manually and it is just the most outer invocation that
>>> should perform the "unget"
>>>
>>> Thanks
>>> Alain
>>>
>>> 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. 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:

Re: [osgi-dev] Disposing component instances

[Raymond Auge via osgi-dev]

Please note that up to a couple of weeks ago there was a bug in Felix SCR
managing indirect component prototype instances.

https://issues.apache.org/jira/browse/FELIX-5974

So you may want to make sure you have the latest.

- Ray

On Sun, Nov 25, 2018, 08:21 Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org wrote:

> On Sun, Nov 25, 2018 at 7:50 AM Tim Ward  wrote:
>
>> If your DS component ‘X’ is injected with a Component Service Objects
>> which it uses to get instances ‘A’, ‘B’ and ‘C' of a referenced service
>> then those service instances will be released when either:
>>
>>
>>- The component ‘X’ releases them by calling ungetService on the
>>component service objects
>>
>> or
>>
>>- The component ‘X’ is deactivated (for whatever reason) at which
>>point the Service Component Runtime will automatically release any
>>remaining instances that haven’t been released by the component before the
>>end of any deactivate method.
>>
>>
>> This is why the ComponentServiceObjects is a better choice than using a
>> ServiceObjects directly, as the ServiceObjects won’t clean up after you.
>>
>> Can I interpret this and your previous comment as meaning that within a
>> prototype scope component, a prototype required scope reference doesn't
>> need to be "unget" manually and it is just the most outer invocation that
>> should perform the “unget"
>>
>>
>> In a limited way, yes. If you get many instances over the lifetime of
>> your component ‘X’ then you should probably have a mechanism to unget them
>> manually, otherwise the memory usage of your component will grow and grow
>> over time (until it is deactivated). If you get two or three instances of
>> the prototype service which you then hold for the life of the component ‘X’
>> then feel free to let DS do all the work.
>>
> This is for a composing a UI view which itself has a defined lifespan, but
> this prototype component creates a number of other prototype scoped
> components and it would be much easier to such unget the view and not all
> its parts.
>
> Small slant to this question, let's say that X has a reference to Factory
> A (standard component) and that factory A returns a prototype scoped
> instance, will ungetting X, release the instance returned by factory A?
>
> Alain
>
>
>
>> Tim
>>
>> On 25 Nov 2018, at 12:41, Alain Picard  wrote:
>>
>> Tim,
>>
>> Circling back on this. Re-reading section 112.3.6 it says "This means
>> that if a component instance used a Component Service Objects object to
>> obtain service objects, SCR must track those service objects so that when
>> the service becomes unbound, SCR can unget any unreleased service objects".
>>
>> Can I interpret this and your previous comment as meaning that within a
>> prototype scope component, a prototype required scope reference doesn't
>> need to be "unget" manually and it is just the most outer invocation that
>> should perform the "unget"
>>
>> Thanks
>> Alain
>>
>> 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. 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:

Re: [osgi-dev] Disposing component instances

[Tim Ward via osgi-dev]

> Small slant to this question, let's say that X has a reference to Factory A 
> (standard component) and that factory A returns a prototype scoped instance, 
> will ungetting X, release the instance returned by factory A?

The simple answer is yes, the in depth answer is “not always” due to the 
specific terms you have used in your question. 

Assuming that you are the only person who got X then it will be deactivated 
when you unget, releasing the instance from factory A. If something else is 
keeping the instance of X alive (e.g. a second user of the Singleton component 
X) then the instance of Factory A will remain alive until X is deactivated.

I hope this makes sense,

Tim

Sent from my iPhone

> On 25 Nov 2018, at 13:20, Alain Picard  wrote:
> 
>> On Sun, Nov 25, 2018 at 7:50 AM Tim Ward  wrote:
>> If your DS component ‘X’ is injected with a Component Service Objects which 
>> it uses to get instances ‘A’, ‘B’ and ‘C' of a referenced service then those 
>> service instances will be released when either:
>> 
>> The component ‘X’ releases them by calling ungetService on the component 
>> service objects
>> or
>> The component ‘X’ is deactivated (for whatever reason) at which point the 
>> Service Component Runtime will automatically release any remaining instances 
>> that haven’t been released by the component before the end of any deactivate 
>> method.
>> 
>> This is why the ComponentServiceObjects is a better choice than using a 
>> ServiceObjects directly, as the ServiceObjects won’t clean up after you.
>> 
>>> Can I interpret this and your previous comment as meaning that within a 
>>> prototype scope component, a prototype required scope reference doesn't 
>>> need to be "unget" manually and it is just the most outer invocation that 
>>> should perform the “unget"
>> 
>> In a limited way, yes. If you get many instances over the lifetime of your 
>> component ‘X’ then you should probably have a mechanism to unget them 
>> manually, otherwise the memory usage of your component will grow and grow 
>> over time (until it is deactivated). If you get two or three instances of 
>> the prototype service which you then hold for the life of the component ‘X’ 
>> then feel free to let DS do all the work.
> This is for a composing a UI view which itself has a defined lifespan, but 
> this prototype component creates a number of other prototype scoped 
> components and it would be much easier to such unget the view and not all its 
> parts.
> 
> Small slant to this question, let's say that X has a reference to Factory A 
> (standard component) and that factory A returns a prototype scoped instance, 
> will ungetting X, release the instance returned by factory A?
> 
> Alain
> 
>  
>> Tim
>> 
>>> On 25 Nov 2018, at 12:41, Alain Picard  wrote:
>>> 
>>> Tim,
>>> 
>>> Circling back on this. Re-reading section 112.3.6 it says "This means that 
>>> if a component instance used a Component Service Objects object to obtain 
>>> service objects, SCR must track those service objects so that when the 
>>> service becomes unbound, SCR can unget any unreleased service objects".
>>> 
>>> Can I interpret this and your previous comment as meaning that within a 
>>> prototype scope component, a prototype required scope reference doesn't 
>>> need to be "unget" manually and it is just the most outer invocation that 
>>> should perform the "unget"
>>> 
>>> Thanks
>>> Alain
>>> 
 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. 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 

Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

On Sun, Nov 25, 2018 at 7:50 AM Tim Ward  wrote:

> If your DS component ‘X’ is injected with a Component Service Objects
> which it uses to get instances ‘A’, ‘B’ and ‘C' of a referenced service
> then those service instances will be released when either:
>
>
>- The component ‘X’ releases them by calling ungetService on the
>component service objects
>
> or
>
>- The component ‘X’ is deactivated (for whatever reason) at which
>point the Service Component Runtime will automatically release any
>remaining instances that haven’t been released by the component before the
>end of any deactivate method.
>
>
> This is why the ComponentServiceObjects is a better choice than using a
> ServiceObjects directly, as the ServiceObjects won’t clean up after you.
>
> Can I interpret this and your previous comment as meaning that within a
> prototype scope component, a prototype required scope reference doesn't
> need to be "unget" manually and it is just the most outer invocation that
> should perform the “unget"
>
>
> In a limited way, yes. If you get many instances over the lifetime of your
> component ‘X’ then you should probably have a mechanism to unget them
> manually, otherwise the memory usage of your component will grow and grow
> over time (until it is deactivated). If you get two or three instances of
> the prototype service which you then hold for the life of the component ‘X’
> then feel free to let DS do all the work.
>
This is for a composing a UI view which itself has a defined lifespan, but
this prototype component creates a number of other prototype scoped
components and it would be much easier to such unget the view and not all
its parts.

Small slant to this question, let's say that X has a reference to Factory A
(standard component) and that factory A returns a prototype scoped
instance, will ungetting X, release the instance returned by factory A?

Alain



> Tim
>
> On 25 Nov 2018, at 12:41, Alain Picard  wrote:
>
> Tim,
>
> Circling back on this. Re-reading section 112.3.6 it says "This means that
> if a component instance used a Component Service Objects object to obtain
> service objects, SCR must track those service objects so that when the
> service becomes unbound, SCR can unget any unreleased service objects".
>
> Can I interpret this and your previous comment as meaning that within a
> prototype scope component, a prototype required scope reference doesn't
> need to be "unget" manually and it is just the most outer invocation that
> should perform the "unget"
>
> Thanks
> Alain
>
> 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. 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:

Re: [osgi-dev] Disposing component instances

[Tim Ward via osgi-dev]

If your DS component ‘X’ is injected with a Component Service Objects which it 
uses to get instances ‘A’, ‘B’ and ‘C' of a referenced service then those 
service instances will be released when either:

The component ‘X’ releases them by calling ungetService on the component 
service objects
or
The component ‘X’ is deactivated (for whatever reason) at which point the 
Service Component Runtime will automatically release any remaining instances 
that haven’t been released by the component before the end of any deactivate 
method.

This is why the ComponentServiceObjects is a better choice than using a 
ServiceObjects directly, as the ServiceObjects won’t clean up after you.

> Can I interpret this and your previous comment as meaning that within a 
> prototype scope component, a prototype required scope reference doesn't need 
> to be "unget" manually and it is just the most outer invocation that should 
> perform the “unget"

In a limited way, yes. If you get many instances over the lifetime of your 
component ‘X’ then you should probably have a mechanism to unget them manually, 
otherwise the memory usage of your component will grow and grow over time 
(until it is deactivated). If you get two or three instances of the prototype 
service which you then hold for the life of the component ‘X’ then feel free to 
let DS do all the work.

Tim

> On 25 Nov 2018, at 12:41, Alain Picard  wrote:
> 
> Tim,
> 
> Circling back on this. Re-reading section 112.3.6 it says "This means that if 
> a component instance used a Component Service Objects object to obtain 
> service objects, SCR must track those service objects so that when the 
> service becomes unbound, SCR can unget any unreleased service objects".
> 
> Can I interpret this and your previous comment as meaning that within a 
> prototype scope component, a prototype required scope reference doesn't need 
> to be "unget" manually and it is just the most outer invocation that should 
> perform the "unget"
> 
> Thanks
> Alain
> 
> 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. 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
>>> 

Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

Tim,

Circling back on this. Re-reading section 112.3.6 it says "This means that
if a component instance used a Component Service Objects object to obtain
service objects, SCR must track those service objects so that when the
service becomes unbound, SCR can unget any unreleased service objects".

Can I interpret this and your previous comment as meaning that within a
prototype scope component, a prototype required scope reference doesn't
need to be "unget" manually and it is just the most outer invocation that
should perform the "unget"

Thanks
Alain

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. 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
> 

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] Disposing component instances

[Alain Picard via osgi-dev]

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 the system is supposed to clean itself up.
>>> What am I missing.
>>>
>>> What am I missing?
>>>
>>> Apart from a question mark.. that is.
>>>
>>>
>>> Hi Paul,
>>>
>>> You are correct in your interpretation of the specification, however…
>>>
>>>
>>>1. This only happens if you use ComponentServiceObjects, not
>>>ServiceObjects (which is why this type was added to the DS spec). If you
>>>use ServiceObjects directly then SCR cannot reference count them and 
>>> cannot
>>>help you.
>>>2. The “leaked” 

Re: [osgi-dev] Disposing component instances

[Tim Ward via osgi-dev]

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 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> 
>>> On 21 Aug 2018, at 20:53, Paul F Fraser via osgi-dev 
>>> mailto: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 the system is supposed to clean itself 
 up.
 What am I missing.
>>> What am I missing?
>>> 
>>> Apart from a question mark.. that is.
>> 
>> Hi Paul,
>> 
>> You are correct in your interpretation of the specification, however…
>> 
>> This only happens if you use ComponentServiceObjects, not ServiceObjects 
>> (which is why this type was added to the DS spec). If you use ServiceObjects 
>> directly then SCR cannot 

Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

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 the system is supposed to clean itself up.
>> What am I missing.
>>
>> What am I missing?
>>
>> Apart from a question mark.. that is.
>>
>>
>> Hi Paul,
>>
>> You are correct in your interpretation of the specification, however…
>>
>>
>>1. This only happens if you use ComponentServiceObjects, not
>>ServiceObjects (which is why this type was added to the DS spec). If you
>>use ServiceObjects directly then SCR cannot reference count them and 
>> cannot
>>help you.
>>2. The “leaked” instances are only cleaned up when your component is
>>disposed by SCR (for example if it becomes unsatisfied).
>>
>>
>> In this case we *are* using ComponentServiceObjects (good) but we need to
>> dispose of the referenced instance when the UI view is closed.
>>
>> If we left it up to SCR to clean up, and our component wasn’t
>> deactivated/disposed between UI sessions then we would have a memory leak.
>> In general when you use ComponentServiceObjects you should think about the
>> lifecycle of the objects you create, and how they are going to be released.
>> In this case the component may get an arbitrarily large (and increasing)
>> number of instances over time, so it must 

Re: [osgi-dev] Disposing component instances

[Tim Ward via osgi-dev]

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  > wrote:
> 
> 
>> On 21 Aug 2018, at 20:53, Paul F Fraser via osgi-dev > > 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 the system is supposed to clean itself up.
>>> What am I missing.
>> What am I missing?
>> 
>> Apart from a question mark.. that is.
> 
> Hi Paul,
> 
> You are correct in your interpretation of the specification, however…
> 
> This only happens if you use ComponentServiceObjects, not ServiceObjects 
> (which is why this type was added to the DS spec). If you use ServiceObjects 
> directly then SCR cannot reference count them and cannot help you.
> The “leaked” instances are only cleaned up when your component is disposed by 
> SCR (for example if it becomes unsatisfied).
> 
> In this case we *are* using ComponentServiceObjects (good) but we need to 
> dispose of the referenced instance when the UI view is closed.
> 
> If we left it up to SCR to clean up, and our component wasn’t 
> deactivated/disposed between UI sessions then we would have a memory leak. In 
> general when you use ComponentServiceObjects you should think about the 
> lifecycle of the objects you create, and how they are going to be released. 
> In this case the component may get an arbitrarily large (and increasing) 
> number of instances over time, so it must also dispose of them. If the 
> example just grabbed 2 (or 5, or 10) instances at activation and used them 
> until deactivation then it would not be necessary to release them (SCR would 
> do it for us).
> 
> I hope that this makes sense,
> 
> Tim
> 
> 
>>> 
>>> Paul Fraser
>>> 

Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

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 the system is supposed to clean itself up.
> What am I missing.
>
> What am I missing?
>
> Apart from a question mark.. that is.
>
>
> Hi Paul,
>
> You are correct in your interpretation of the specification, however…
>
>
>1. This only happens if you use ComponentServiceObjects, not
>ServiceObjects (which is why this type was added to the DS spec). If you
>use ServiceObjects directly then SCR cannot reference count them and cannot
>help you.
>2. The “leaked” instances are only cleaned up when your component is
>disposed by SCR (for example if it becomes unsatisfied).
>
>
> In this case we *are* using ComponentServiceObjects (good) but we need to
> dispose of the referenced instance when the UI view is closed.
>
> If we left it up to SCR to clean up, and our component wasn’t
> deactivated/disposed between UI sessions then we would have a memory leak.
> In general when you use ComponentServiceObjects you should think about the
> lifecycle of the objects you create, and how they are going to be released.
> In this case the component may get an arbitrarily large (and increasing)
> number of instances over time, so it must also dispose of them. If the
> example just grabbed 2 (or 5, or 10) instances at activation and used them
> until deactivation then it would not be necessary to release them (SCR
> would do it for us).
>
> I hope that this makes sense,
>
> Tim
>
>
>
> Paul Fraser
> ___
> 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

Re: [osgi-dev] Disposing component instances

[Tim Ward via osgi-dev]

> On 21 Aug 2018, at 20:53, Paul F Fraser via osgi-dev  
> 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 the system is supposed to clean itself up.
>> What am I missing.
> What am I missing?
> 
> Apart from a question mark.. that is.

Hi Paul,

You are correct in your interpretation of the specification, however…

This only happens if you use ComponentServiceObjects, not ServiceObjects (which 
is why this type was added to the DS spec). If you use ServiceObjects directly 
then SCR cannot reference count them and cannot help you.
The “leaked” instances are only cleaned up when your component is disposed by 
SCR (for example if it becomes unsatisfied).

In this case we *are* using ComponentServiceObjects (good) but we need to 
dispose of the referenced instance when the UI view is closed.

If we left it up to SCR to clean up, and our component wasn’t 
deactivated/disposed between UI sessions then we would have a memory leak. In 
general when you use ComponentServiceObjects you should think about the 
lifecycle of the objects you create, and how they are going to be released. In 
this case the component may get an arbitrarily large (and increasing) number of 
instances over time, so it must also dispose of them. If the example just 
grabbed 2 (or 5, or 10) instances at activation and used them until 
deactivation then it would not be necessary to release them (SCR would do it 
for us).

I hope that this makes sense,

Tim


>> 
>> Paul Fraser
>> ___
>> 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

Re: [osgi-dev] Disposing component instances

[Paul F Fraser via osgi-dev]

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 the system is supposed to clean itself up.

What am I missing.

What am I missing?

Apart from a question mark.. that is.


Paul Fraser
___
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

Re: [osgi-dev] Disposing component instances

[Paul F Fraser via osgi-dev]

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 the system is supposed to clean itself up.

What am I missing.

Paul Fraser
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

Tim,

I didn't know anything about OSC, so hadn't looked but we use ZK which is
quite similar to Vaadin, so the use case is pretty similar and this
provides a nice point of reference.

Thanks
Alain


On Tue, Aug 21, 2018 at 8:00 AM Tim Ward  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
>
> On 21 Aug 2018, at 09:56, Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> When using factory components, you get a ComponentInstance and you should
> dispose once done. For services with prototype scope, you get
> ComponentServiceObjects from which you need to ungetService after use.
>
> I have some cases where I am creating some UI Widgets and where I don't
> have a well defined lifecycle that my class controls. It is expected to
> hand over a widget and the widget will be "disposed" when necessary. The
> widget can add actions when it is "disposed" or a listener can be added to
> watch for such events with the UI framework.
>
> What is the best way to handle those and is either factory component or
> CSO better that the other, in this case and others? I was thinking that I
> might implement a factory for managed widgets that keeps a map of provided
> widgets and registers for events of disposed widgets and cleans up at that
> time, but feels like an added moving part.
>
> 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

Re: [osgi-dev] Disposing component instances

[Tim Ward via osgi-dev]

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

> On 21 Aug 2018, at 09:56, Alain Picard via osgi-dev  
> wrote:
> 
> When using factory components, you get a ComponentInstance and you should 
> dispose once done. For services with prototype scope, you get 
> ComponentServiceObjects from which you need to ungetService after use.
> 
> I have some cases where I am creating some UI Widgets and where I don't have 
> a well defined lifecycle that my class controls. It is expected to hand over 
> a widget and the widget will be "disposed" when necessary. The widget can add 
> actions when it is "disposed" or a listener can be added to watch for such 
> events with the UI framework.
> 
> What is the best way to handle those and is either factory component or CSO 
> better that the other, in this case and others? I was thinking that I might 
> implement a factory for managed widgets that keeps a map of provided widgets 
> and registers for events of disposed widgets and cleans up at that time, but 
> feels like an added moving part.
> 
> 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

[osgi-dev] Disposing component instances

[Alain Picard via osgi-dev]

When using factory components, you get a ComponentInstance and you should
dispose once done. For services with prototype scope, you get
ComponentServiceObjects from which you need to ungetService after use.

I have some cases where I am creating some UI Widgets and where I don't
have a well defined lifecycle that my class controls. It is expected to
hand over a widget and the widget will be "disposed" when necessary. The
widget can add actions when it is "disposed" or a listener can be added to
watch for such events with the UI framework.

What is the best way to handle those and is either factory component or CSO
better that the other, in this case and others? I was thinking that I might
implement a factory for managed widgets that keeps a map of provided
widgets and registers for events of disposed widgets and cleans up at that
time, but feels like an added moving part.

Alain
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev