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
