> 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?
The simple answer is yes, the in depth answer is “not always” due to the specific terms you have used in your question. Assuming that you are the only person who got X then it will be deactivated when you unget, releasing the instance from factory A. If something else is keeping the instance of X alive (e.g. a second user of the Singleton component X) then the instance of Factory A will remain alive until X is deactivated. I hope this makes sense, Tim Sent from my iPhone > On 25 Nov 2018, at 13:20, Alain Picard <pic...@castortech.com> 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. 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… >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>>>> 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
