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 >>> >>> >>> >>
OsgiProtoSupplier.java
Description: Binary data
OsgiProtoTracker.java
Description: Binary data
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
