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 OSGi Alliance [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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
