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<ViewpointTabboxItemViewModel>
>>>> implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
>>>> ...
>>>> @Activate
>>>> private void activate(ComponentContext context, Map<String, Object>
>>>> 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é* <http://www.liferay.com/web/raymond.auge/profile>
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>  (@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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to