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
