> On 21 Aug 2018, at 20:53, Paul F Fraser via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > On 22/08/2018 5:40 AM, Paul F Fraser via osgi-dev wrote: >> On 21/08/2018 10:00 PM, Tim Ward via osgi-dev wrote: >>> Have you looked at what the OSC project does? It uses Vaadin, and uses the >>> ViewProvider interface to provide view instances. These automatically have >>> a detach listener added on creation so that they get correctly disposed >>> when their parent container is closed. >>> >>> See >>> https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L60-L67 >>> for details. >>> >>> Tim >> >> Hi Tim, >> The R7 Spec 112.3.6 states that "SCR must unget any unreleased service >> objects" and it sounds to me that the system is supposed to clean itself up. >> What am I missing. > What am I missing? > > Apart from a question mark.. that is.
Hi Paul, You are correct in your interpretation of the specification, however… This only happens if you use ComponentServiceObjects, not ServiceObjects (which is why this type was added to the DS spec). If you use ServiceObjects directly then SCR cannot reference count them and cannot help you. The “leaked” instances are only cleaned up when your component is disposed by SCR (for example if it becomes unsatisfied). In this case we *are* using ComponentServiceObjects (good) but we need to dispose of the referenced instance when the UI view is closed. If we left it up to SCR to clean up, and our component wasn’t deactivated/disposed between UI sessions then we would have a memory leak. In general when you use ComponentServiceObjects you should think about the lifecycle of the objects you create, and how they are going to be released. In this case the component may get an arbitrarily large (and increasing) number of instances over time, so it must also dispose of them. If the example just grabbed 2 (or 5, or 10) instances at activation and used them until deactivation then it would not be necessary to release them (SCR would do it for us). I hope that this makes sense, Tim >> >> Paul Fraser >> _______________________________________________ >> 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
