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 <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 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 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 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 <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 > <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 <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 > <osgi-dev@mail.osgi.org <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 > <osgi-dev@mail.osgi.org <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. > > 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 <mailto:pic...@castortech.com> > www.castortech.com > <http://www.castortech.com/>_______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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 <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev>_______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev>_______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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