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 <tim.w...@paremus.com> 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 > > <https://github.com/opensecuritycontroller/osc-core/blob/master/osc-ui/src/main/java/org/osc/core/broker/view/MainUIProvider.java#L42> > 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 > > <https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L37>. > This allowed a DS component to wrap a ComponentServiceObjects > > <https://github.com/opensecuritycontroller/osc-core/blob/master/osc-ui/src/main/java/org/osc/core/broker/view/MainUI.java#L195> > 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 > > <https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L63>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. 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 > > >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
