Thanks! I actually saw that being called by ComponentServiceObjects while perusing the code.
Alain On Wed, Aug 22, 2018 at 11:52 AM Tim Ward <tim.w...@paremus.com> wrote: > Registering a prototype service is almost as easy as registering a > singleton service. Instead of registering a single object you register an > instance of PrototypeServiceFactory > <https://osgi.org/javadoc/r6/core/org/osgi/framework/PrototypeServiceFactory.html>. > This will get called by the framework to get and release instances as > needed. > > Tim > > On 22 Aug 2018, at 16:49, Alain Picard <pic...@castortech.com> wrote: > > Tim, > > This helps quite a bit and clarifies a few points for me. As someone who > is migrating from a pre-DS environment and dealing with lots of legacy, how > can prototype scoped services be used outside of DS? That would be > fantastic. Right now we have a good solution to use singleton services > outside of DS but not for "factory" type services. > > Thanks > Alain > > > On Wed, Aug 22, 2018 at 11:27 AM Tim Ward <tim.w...@paremus.com> wrote: > >> Hi Alain, >> >> A "Prototype scoped" service is one where the client(s) can request an >> arbitrary number of instances of the “same” service, whereas a >> ComponentFactory is a mechanism for the clients to request an arbitrary >> number of differently configured component instances. >> >> From the perspective of the component the key difference is that all of >> the instances of a prototype scoped component have the same component >> properties, and the instances created by the factory component have the >> combination of these component properties *plus* the properties passed to >> the factory. >> >> In some senses prototype scoped services are better because they: >> >> >> - Don’t require the service implementation to use DS (they may wish >> to use something else) >> - Will have satisfied references and configurations (component >> factories can be given configuration which invalidates the registration >> resulting in an error) >> >> >> The main reason that you would use a Component Factory rather than a >> prototype scoped service is if you genuinely want to have different >> specialised configurations for each instance, and it doesn’t make sense to >> use a managed service factory (i.e. the customised instances are only >> interesting to one client, or must not be shared for some reason). >> >> If your instances are identically configured (or can be, with an init >> later) then a ComponentServiceObjects getService() call should be all you >> need each time you need a new instance, followed by a call to >> ungetService() later when you’re done with it. >> >> Tim >> >> On 22 Aug 2018, at 12:06, Alain Picard <pic...@castortech.com> wrote: >> >> On the 2nd part of the question regarding >> ComponentFactory/ComponentInstance vs Prototype/ComponentServiceObjects. I >> get the feeling that CSO should be favored, but I saw an old post from >> Scott Lewis about configuration and that is a bit close to some of my use >> cases. >> >> I have cases where I have a Factory component that delivers instances and >> calls an init method to configure the component, or might sometimes return >> an existing matching one that is already cached (like per data connection >> instances). With ComponentFactory I can create a new instance, call init on >> the new instance and return the ComponentInstance. The caller can then call >> getInstance and call dispose when done. I struggle to find a correct/easy >> way to do this with CSO. Am I using the best approach or not? >> >> Thanks >> Alain >> >> >> On Wed, Aug 22, 2018 at 3:46 AM Tim Ward via osgi-dev < >> osgi-dev@mail.osgi.org> wrote: >> >>> >>> >>> 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… >>> >>> >>> 1. 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. >>> 2. 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 >>> 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
