Re: [osgi-dev] Deactivating a component manually

2019-09-23 Thread 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

2019-09-23 Thread 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.
> 
>

Re: [osgi-dev] Deactivating a component manually

2019-09-22 Thread Alain Picard via osgi-dev 
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. 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.

 Cheers,
 Alain



 Here's the case:
 @Component(service = ViewpointsViewModeTabViewModel.class, scope =
 ServiceScope.PROTOTYPE)
 public class ViewpointsViewModeTabViewModel extends
 ViewModeTabboxItemViewModel {
 ...
 @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
 private BaViewPointsViewModel baViewPointsViewModel;
 ...
 }

 and
 @Component(service = BaViewPointsViewModel.class,
 scope=ServiceScope.PROTOTYPE)
 @Init(superclass = true)
 public final class BaViewPointsViewModel extends
 ViewPointsViewModel
 implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
 ...
 @Activate
 private void activate(ComponentContext context, Map
 properties) {
   this.context = context;
   pid = (String)properties.get(ComponentConstants.COMPONENT_NAME);

log.trace("Activating {}/{}", getClass(),
 System.identityHashCode(this)); //$NON-NLS-1$
   initTabs();
 }
 @Deactivate
 private void deactivate() {
   log.trace("Deactivating {}/{}", getClass(),
 System.identityHashCode(this)); //$NON-NLS-1$
   super.zkDestroy();
   ungetServices();
   clearTabs();
 }

 @Override
 @Destroy
 public void zkDestroy() {
   log.trace("Destroying {}/{}", getClass(),
 System.identityHashCode(this)); //$NON-NLS-1$
   deactivate();
   context.disableComponent(pid);  //attempt to manually deactivate
 itself.
 }
 }


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

 pic...@castortech.com
 www.castortech.com
 ___
 OSGi Developer Mail List
 osgi-dev@mail.osgi.org
 https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>>
>>> --
>>> *Raymond Augé* 
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* 
>>>  (@Liferay)
>>> ___
>>> 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
>>

Re: [osgi-dev] Deactivating a component manually

2019-09-21 Thread Raymond Auge via osgi-dev 
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. 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.
>>>
>>> Cheers,
>>> Alain
>>>
>>>
>>>
>>> Here's the case:
>>> @Component(service = ViewpointsViewModeTabViewModel.class, scope =
>>> ServiceScope.PROTOTYPE)
>>> public class ViewpointsViewModeTabViewModel extends
>>> ViewModeTabboxItemViewModel {
>>> ...
>>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>>> private BaViewPointsViewModel baViewPointsViewModel;
>>> ...
>>> }
>>>
>>> and
>>> @Component(service = BaViewPointsViewModel.class,
>>> scope=ServiceScope.PROTOTYPE)
>>> @Init(superclass = true)
>>> public final class BaViewPointsViewModel extends
>>> ViewPointsViewModel
>>> implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
>>> ...
>>> @Activate
>>> private void activate(ComponentContext context, Map
>>> properties) {
>>>   this.context = context;
>>>   pid = (String)properties.get(ComponentConstants.COMPONENT_NAME);
>>>
>>>log.trace("Activating {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>>   initTabs();
>>> }
>>> @Deactivate
>>> private void deactivate() {
>>>   log.trace("Deactivating {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>>   super.zkDestroy();
>>>   ungetServices();
>>>   clearTabs();
>>> }
>>>
>>> @Override
>>> @Destroy
>>> public void zkDestroy() {
>>>   log.trace("Destroying {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>>   deactivate();
>>>   context.disableComponent(pid);  //attempt to manually deactivate
>>> itself.
>>> }
>>> }
>>>
>>>
>>> Alain Picard
>>> Chief Strategy Officer
>>> Castor Technologies Inc
>>> o:514-360-7208
>>> m:813-787-3424
>>>
>>> pic...@castortech.com
>>> www.castortech.com
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> ___
>> 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] Deactivating a component manually

2019-09-21 Thread Alain Picard via osgi-dev 
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. 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.
>>
>> Cheers,
>> Alain
>>
>>
>>
>> Here's the case:
>> @Component(service = ViewpointsViewModeTabViewModel.class, scope =
>> ServiceScope.PROTOTYPE)
>> public class ViewpointsViewModeTabViewModel extends
>> ViewModeTabboxItemViewModel {
>> ...
>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>> private BaViewPointsViewModel baViewPointsViewModel;
>> ...
>> }
>>
>> and
>> @Component(service = BaViewPointsViewModel.class,
>> scope=ServiceScope.PROTOTYPE)
>> @Init(superclass = true)
>> public final class BaViewPointsViewModel extends
>> ViewPointsViewModel
>> implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
>> ...
>> @Activate
>> private void activate(ComponentContext context, Map
>> properties) {
>>   this.context = context;
>>   pid = (String)properties.get(ComponentConstants.COMPONENT_NAME);
>>
>>log.trace("Activating {}/{}", getClass(),
>> System.identityHashCode(this)); //$NON-NLS-1$
>>   initTabs();
>> }
>> @Deactivate
>> private void deactivate() {
>>   log.trace("Deactivating {}/{}", getClass(),
>> System.identityHashCode(this)); //$NON-NLS-1$
>>   super.zkDestroy();
>>   ungetServices();
>>   clearTabs();
>> }
>>
>> @Override
>> @Destroy
>> public void zkDestroy() {
>>   log.trace("Destroying {}/{}", getClass(),
>> System.identityHashCode(this)); //$NON-NLS-1$
>>   deactivate();
>>   context.disableComponent(pid);  //attempt to manually deactivate itself.
>> }
>> }
>>
>>
>> Alain Picard
>> Chief Strategy Officer
>> Castor Technologies Inc
>> o:514-360-7208
>> m:813-787-3424
>>
>> pic...@castortech.com
>> www.castortech.com
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> ___
> 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] Deactivating a component manually

2019-09-21 Thread Raymond Auge via osgi-dev 
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. 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.
>
> Cheers,
> Alain
>
>
>
> Here's the case:
> @Component(service = ViewpointsViewModeTabViewModel.class, scope =
> ServiceScope.PROTOTYPE)
> public class ViewpointsViewModeTabViewModel extends
> ViewModeTabboxItemViewModel {
> ...
> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
> private BaViewPointsViewModel baViewPointsViewModel;
> ...
> }
>
> and
> @Component(service = BaViewPointsViewModel.class,
> scope=ServiceScope.PROTOTYPE)
> @Init(superclass = true)
> public final class BaViewPointsViewModel extends
> ViewPointsViewModel
> implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
> ...
> @Activate
> private void activate(ComponentContext context, Map
> properties) {
>   this.context = context;
>   pid = (String)properties.get(ComponentConstants.COMPONENT_NAME);
>
>log.trace("Activating {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
>   initTabs();
> }
> @Deactivate
> private void deactivate() {
>   log.trace("Deactivating {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
>   super.zkDestroy();
>   ungetServices();
>   clearTabs();
> }
>
> @Override
> @Destroy
> public void zkDestroy() {
>   log.trace("Destroying {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
>   deactivate();
>   context.disableComponent(pid);  //attempt to manually deactivate itself.
> }
> }
>
>
> Alain Picard
> Chief Strategy Officer
> Castor Technologies Inc
> o:514-360-7208
> m:813-787-3424
>
> pic...@castortech.com
> www.castortech.com
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Deactivating a component manually

2019-09-21 Thread Alain Picard via osgi-dev 
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.

Cheers,
Alain



Here's the case:
@Component(service = ViewpointsViewModeTabViewModel.class, scope =
ServiceScope.PROTOTYPE)
public class ViewpointsViewModeTabViewModel extends
ViewModeTabboxItemViewModel {
...
@Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
private BaViewPointsViewModel baViewPointsViewModel;
...
}

and
@Component(service = BaViewPointsViewModel.class,
scope=ServiceScope.PROTOTYPE)
@Init(superclass = true)
public final class BaViewPointsViewModel extends
ViewPointsViewModel
implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
...
@Activate
private void activate(ComponentContext context, Map
properties) {
  this.context = context;
  pid = (String)properties.get(ComponentConstants.COMPONENT_NAME);

   log.trace("Activating {}/{}", getClass(),
System.identityHashCode(this)); //$NON-NLS-1$
  initTabs();
}
@Deactivate
private void deactivate() {
  log.trace("Deactivating {}/{}", getClass(),
System.identityHashCode(this)); //$NON-NLS-1$
  super.zkDestroy();
  ungetServices();
  clearTabs();
}

@Override
@Destroy
public void zkDestroy() {
  log.trace("Destroying {}/{}", getClass(), System.identityHashCode(this));
//$NON-NLS-1$
  deactivate();
  context.disableComponent(pid);  //attempt to manually deactivate itself.
}
}


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

pic...@castortech.com
www.castortech.com
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev