Re: [osgi-dev] Deactivating a component manually

[Alain Picard via osgi-dev]

Tim,

This pretty much nails it I think. Here it seems that ZK has more granular
component disposition, but same approach mainly. I will have to see how
much refactoring is involved now :)

Alain

Alain Picard
Chief Strategy Officer
Castor Technologies Inc
o:514-360-7208
m:813-787-3424

pic...@castortech.com
www.castortech.com


On Mon, Sep 23, 2019 at 5:31 AM Tim Ward  wrote:

> Hi Alain,
>
> This sounds exactly like the problem that Open Security Controller had
> when using Vaadin. They wanted their various UI types to be DS components
> so that they could use various services to talk to the rest of the system.
> Obviously the UI types need to be prototype scope because each user session
> needs to have a different instance. The UI type instances then get
> “disposed” by the UI when the user navigates away or closes their browser.
> This leaves a lifecycle hole because the UI type instance then needs to be
> “released” from the OSGi Service Reference that created it.
>
> The way that they solved the problem was as follows:
>
>
>1. A singleton top-level DS component was created
>
> 
>  to
>be a factory for all User UI sessions. This forms the entry into the
>prototype lifecycle UI instances
>2. A “wrapper” was created to fit into the Vaadin UI
>
> .
>This allowed a DS component to wrap a ComponentServiceObjects
>
> 
>  into
>a UI factory type which could be passed to the UI framework. Each UI view
>can add lots of these
>3. When the wrapper creates an instance a “detach listener” is added
>
> which
>releases the service when the UI instance is disposed
>4. The UI framework disposes of instances, which releases them from
>the ComponentServiceObjects. If a high level component is disposed then all
>of the other instances it created are too
>
>
> The end result is that the prototype scope instances are automatically
> released when the UI disposes them. This will also run any necessary
> deactivation code in the DS component instance being released.
>
> Hopefully this makes sense to you, and might provide a route forward.
>
> All the best,
>
> Tim Ward
>
> On 22 Sep 2019, at 10:43, Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> No, we had this issue before we (just) upgraded to 2.1.14 and had a number
> of work around in our code to cover that.
>
> Here really the issue is that the trigger to "destroy" comes from outside
> and we need to inform SCR that the component is/should be deactivated.
>
> Alain
>
>
> On Sat, Sep 21, 2019 at 5:22 PM Raymond Auge via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> I'm wondering if you might be suffering from this Apache Felix SCR bug:
>> https://issues.apache.org/jira/plugins/servlet/mobile#issue/FELIX-5974
>>
>> - Ray
>>
>> On Sat, Sep 21, 2019, 11:53 Alain Picard via osgi-dev, <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Ray,
>>>
>>> The service being "destroyed" is BaViewPointsViewModel and you can see
>>> that ViewpointsViewModeTabViewModel has an instance of it. So I want to
>>> make sure that it is correctly released so that SCR can then deactivate
>>> ViewpointsViewModeTabViewModel and whatever else depended on
>>> ViewpointsViewModeTabViewModel and on and on.
>>>
>>> Alain
>>>
>>>
>>> On Sat, Sep 21, 2019 at 10:34 AM Raymond Auge via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
 Hey Alain,

 Just trying to understand the use case better, so a couple questions:

 Since your component is prototype scope, and if no one has any
 instances of it why bother disabling it, isn't it effectively only a fairly
 inert service reference at that point?
 Are you saying that when released as a prototype instance, it should
 never be used again, ever?
 Perhaps the service you described above could be a factory for
 instances of `ZkViewModel, BaItem, MasterDetailTopMenuListener` instead of
 being one itself.

 - Ray

 On Sat, Sep 21, 2019 at 5:05 AM Alain Picard via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

> I'm facing a case where the UI framework is sending a destroy request
> when a page is destroyed and I want to use that to also deactivate the
> component, so that its "host" can then automatically get deactivated and 
> so
> on so forth as needed.
>
> As shown below I tried to use disableComponent. 

Re: [osgi-dev] Deactivating a component manually

[Tim Ward via osgi-dev]

Hi Alain,

This sounds exactly like the problem that Open Security Controller had when 
using Vaadin. They wanted their various UI types to be DS components so that 
they could use various services to talk to the rest of the system. Obviously 
the UI types need to be prototype scope because each user session needs to have 
a different instance. The UI type instances then get “disposed” by the UI when 
the user navigates away or closes their browser. This leaves a lifecycle hole 
because the UI type instance then needs to be “released” from the OSGi Service 
Reference that created it.

The way that they solved the problem was as follows:

A singleton top-level DS component was created 

 to be a factory for all User UI sessions. This forms the entry into the 
prototype lifecycle UI instances
A “wrapper” was created to fit into the Vaadin UI 
.
 This allowed a DS component to wrap a ComponentServiceObjects 

 into a UI factory type which could be passed to the UI framework. Each UI view 
can add lots of these
When the wrapper creates an instance a “detach listener” is added  
which
 releases the service when the UI instance is disposed
The UI framework disposes of instances, which releases them from the 
ComponentServiceObjects. If a high level component is disposed then all of the 
other instances it created are too

The end result is that the prototype scope instances are automatically released 
when the UI disposes them. This will also run any necessary deactivation code 
in the DS component instance being released.

Hopefully this makes sense to you, and might provide a route forward.

All the best,

Tim Ward

> On 22 Sep 2019, at 10:43, Alain Picard via osgi-dev  
> wrote:
> 
> No, we had this issue before we (just) upgraded to 2.1.14 and had a number of 
> work around in our code to cover that. 
> 
> Here really the issue is that the trigger to "destroy" comes from outside and 
> we need to inform SCR that the component is/should be deactivated.
> 
> Alain
> 
> 
> On Sat, Sep 21, 2019 at 5:22 PM Raymond Auge via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> I'm wondering if you might be suffering from this Apache Felix SCR bug: 
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/FELIX-5974 
> 
> 
> - Ray
> 
> On Sat, Sep 21, 2019, 11:53 Alain Picard via osgi-dev, 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> Ray,
> 
> The service being "destroyed" is BaViewPointsViewModel and you can see that 
> ViewpointsViewModeTabViewModel has an instance of it. So I want to make sure 
> that it is correctly released so that SCR can then deactivate 
> ViewpointsViewModeTabViewModel and whatever else depended on 
> ViewpointsViewModeTabViewModel and on and on.
> 
> Alain
> 
> 
> On Sat, Sep 21, 2019 at 10:34 AM Raymond Auge via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> Hey Alain,
> 
> Just trying to understand the use case better, so a couple questions:
> 
> Since your component is prototype scope, and if no one has any instances of 
> it why bother disabling it, isn't it effectively only a fairly inert service 
> reference at that point?
> Are you saying that when released as a prototype instance, it should never be 
> used again, ever?
> Perhaps the service you described above could be a factory for instances of 
> `ZkViewModel, BaItem, MasterDetailTopMenuListener` instead of being one 
> itself.
> 
> - Ray
> 
> On Sat, Sep 21, 2019 at 5:05 AM Alain Picard via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> I'm facing a case where the UI framework is sending a destroy request when a 
> page is destroyed and I want to use that to also deactivate the component, so 
> that its "host" can then automatically get deactivated and so on so forth as 
> needed. 
> 
> As shown below I tried to use disableComponent. That results in some errors 
> as it runs under [SCR Component Actor] thread that is not session aware and 
> also looking at the stack trace it seems to be deactivating the full user 
> session, which is not what I'm expecting.
> 
> So am I deactivating correctly here, how can I make sure this runs in a 
> session aware thread (as I don't control here this separate thread 
> launch/run) and is there a utility to better understand service instance 
> dependencies that would allow tracking the impact of a deactivation.
> 
>