Please note that up to a couple of weeks ago there was a bug in Felix SCR managing indirect component prototype instances.
https://issues.apache.org/jira/browse/FELIX-5974 So you may want to make sure you have the latest. - Ray On Sun, Nov 25, 2018, 08:21 Alain Picard via osgi-dev < osgi-dev@mail.osgi.org wrote: > On Sun, Nov 25, 2018 at 7:50 AM Tim Ward <tim.w...@paremus.com> wrote: > >> If your DS component ‘X’ is injected with a Component Service Objects >> which it uses to get instances ‘A’, ‘B’ and ‘C' of a referenced service >> then those service instances will be released when either: >> >> >> - The component ‘X’ releases them by calling ungetService on the >> component service objects >> >> or >> >> - The component ‘X’ is deactivated (for whatever reason) at which >> point the Service Component Runtime will automatically release any >> remaining instances that haven’t been released by the component before the >> end of any deactivate method. >> >> >> This is why the ComponentServiceObjects is a better choice than using a >> ServiceObjects directly, as the ServiceObjects won’t clean up after you. >> >> Can I interpret this and your previous comment as meaning that within a >> prototype scope component, a prototype required scope reference doesn't >> need to be "unget" manually and it is just the most outer invocation that >> should perform the “unget" >> >> >> In a limited way, yes. If you get many instances over the lifetime of >> your component ‘X’ then you should probably have a mechanism to unget them >> manually, otherwise the memory usage of your component will grow and grow >> over time (until it is deactivated). If you get two or three instances of >> the prototype service which you then hold for the life of the component ‘X’ >> then feel free to let DS do all the work. >> > This is for a composing a UI view which itself has a defined lifespan, but > this prototype component creates a number of other prototype scoped > components and it would be much easier to such unget the view and not all > its parts. > > Small slant to this question, let's say that X has a reference to Factory > A (standard component) and that factory A returns a prototype scoped > instance, will ungetting X, release the instance returned by factory A? > > Alain > > > >> Tim >> >> On 25 Nov 2018, at 12:41, Alain Picard <pic...@castortech.com> wrote: >> >> Tim, >> >> Circling back on this. Re-reading section 112.3.6 it says "This means >> that if a component instance used a Component Service Objects object to >> obtain service objects, SCR must track those service objects so that when >> the service becomes unbound, SCR can unget any unreleased service objects". >> >> Can I interpret this and your previous comment as meaning that within a >> prototype scope component, a prototype required scope reference doesn't >> need to be "unget" manually and it is just the most outer invocation that >> should perform the "unget" >> >> Thanks >> Alain >> >> On Thu, Aug 23, 2018 at 9:20 AM Tim Ward <tim.w...@paremus.com> wrote: >> >>> If you’re using Declarative Services to consume these other dynamic >>> references then there is no need to worry. If you’re trying to >>> programmatically write a prototype scoped service that has service >>> dependencies then stop and use DS instead. Trying to correctly manage the >>> “unget” chains that need to occur when one service in a dependency tree is >>> unregistered is just too hard to be worthwhile. Tools like the >>> ServiceTracker can make it tractable, but it still leaves you writing huge >>> quantities of messy lifecycle code that’s a nightmare to debug. >>> >>> Also, you are correct that you must not keep using a service instance >>> when the service has been unregistered. It is your job to discard that >>> reference :). >>> >>> Tim >>> >>> On 23 Aug 2018, at 13:31, Alain Picard <pic...@castortech.com> wrote: >>> >>> Just a small note, I should have stated that my worry is about the unget >>> timing. I obviously have a reference to the object and this won't disappear >>> by itself, but if that service has other dynamic references that go away >>> and I keep using the service, I might be in trouble. But I guess the >>> template that I used already had a bit that issue with the supplier (which >>> we seldom use). >>> >>> Alain >>> >>> On Thu, Aug 23, 2018 at 7:43 AM Alain Picard <pic...@castortech.com> >>> wrote: >>> >>>> Tim, >>>> >>>> Based on your referenced javadoc, some more googling, I used and >>>> adapted from our own current tracker and supplier to create some Prototype >>>> versions. Tests are showing correct results, but this is not directly using >>>> the PrototypeServiceFactory, so I would appreciate a very quick >>>> confirmation that I'm not missing anything. >>>> >>>> Thanks >>>> >>>> Alain >>>> >>>> >>>> On Wed, Aug 22, 2018 at 11:54 AM Alain Picard <pic...@castortech.com> >>>> wrote: >>>> >>>>> 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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
