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
