Yes I was thinking sort of along the same lines - let the client keep holding on to an "api" object which in turn references the actual object from the impl bundle. It introduces a need to keep track of all created api objects so we can purge their impl refs as soon as the impl bundle goes away. But this hinders GC of objects no longer referenced by the client. Hm, I guess weak refs could help out here. Or explicit release of created objects. Best regards Mike BJ Hargrave wrote:
I imagine you could write your own custom tracker which had methods to create objects using the tracked factory service. Since this class creates the object, it will know when to dispose of them. This issue is how the users of this class know the object was discarded. So you may to to hand out a guarded object which will return the created object if still valid or will attempt to create a new one if previously disposed. There is the risk that a request for the object from the guard will occur in the interregnum when the factory is unavailable. I suppose the guard could block briefly and then try again. But this only works if the code never holds the real object for any length of time and only hold the guard over the long term. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the <http://www.osgi.org/> OSGi Alliance <mailto:[email protected]> [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mike Wilson <[email protected]> To: "'OSGi Developer Mail List'" <[email protected]> Date: 2014/09/30 17:13 Subject: Re: [osgi-dev] cleanup when factory bundles are updated Sent by: [email protected] _____ Thanks BJ, Potentially we would have a fair amount of factory services, created by different people, that all would need to do this. Do you see any parts of this logic that could be extracted into a reusable entity to aid developers doing the right thing? Interesting suggestion with prototype scope services as factories. It will be some time before we are on an R6 implementation, and we would have to rethink our patterns a little to remove creation arguments and add explicit cleanup, but I will definitely keep it in mind for the future. It is nice to see the OSGi framework allowing us manage objects in more flexible ways. Best regards Mike BJ Hargrave wrote: If the factory is a service, then bundle's using the service to create objects will need to track the service and destroy/discard all old objects when the service is unregistered. So if the factory service provider bundle is restarted, no other bundles need to restart, they just need to track the factory service. You could also look at prototype scope services introduced in Core R6 as an alternative to factories (unless you need to parameterize the object creation). -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the <http://www.osgi.org/> OSGi Alliance <mailto:[email protected]> [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mike Wilson <[email protected]> To: "'OSGi Developer Mail List'" <[email protected]> Date: 2014/09/30 13:07 Subject: [osgi-dev] cleanup when factory bundles are updated Sent by: [email protected] _____ Another question about best practices :-) Assuming you have bundles that provide factories allowing other bundles to instantiate objects with behaviour. Typically this would mean instantiating an "Impl" class belonging to the factory classloader and might also relate to resources like network connections. Also assume that factories are exposed as services with separate api and impl bundles. What alternatives and best practices are there to handle this correctly when updating the factory impl bundle (not the api) and needing to replace the previously generated objects (belonging to the old classloader) that were returned to clients? And, more specifically: What alternatives minimize the number of bundles that need to restart? (as opposed to restarting the whole dependency graph) What alternatives work well with Blueprint? (as BP tends to hide service restarts behind its proxies) Thanks Mike Wilson _______________________________________________ OSGi Developer Mail List [email protected] <https://mail.osgi.org/mailman/listinfo/osgi-dev> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] <https://mail.osgi.org/mailman/listinfo/osgi-dev> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
