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. > That's what I'm doing. If you’re trying to programmatically write a prototype scoped service that > has service dependencies then stop and use DS instead. > Wouldn't want to dare trying and really not sure what would be the benefit. It's really the other way around that is really needed. > 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 > Thanks again. Alain > > 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
