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 > <mailto: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 >> <mailto: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 <mailto:osgi-dev@mail.osgi.org>> wrote: >> >> >>> On 21 Aug 2018, at 20:53, Paul F Fraser via osgi-dev >>> <osgi-dev@mail.osgi.org <mailto: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 >>>>> >>>>> <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 <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
