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
