Thanks Raymond On Sun, Nov 25, 2018, 6:58 PM Raymond Auge <raymond.a...@liferay.com wrote:
> 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
