To add my 2cts. If you do not have specific requirements for ordering ... do not manually unregister. It is hard to know what services you actually registered and therefore not trivial to maintain consistency.
Most state oriented services should use Service Factory services and the clean up is perfectly ordered that way. I.e. with a Service Factory you know there are no more connections because they have all been unget. If you stop, the framework must unwind the gets/ungets so you can use the same clean up as for the case when all your users have gone.
Kind regards,
Peter Kriens
On 31 mrt 2008, at 18:14, BJ Hargrave wrote: It is up to you. If the framework removes them, they will be removed in a random order. If you have several listeners and registered services which should be shutdown in some orderly manner, you will need to shut them down yourself. --
I find below description in the OSGi R4 specification section '4.3.6 Activation': stop(BundleContext) – This method must undo all the actions of the BundleActivator.start(BundleContext) method. However, it is unnecessary to unregister services or Framework listeners, because they must be cleaned up by the Framework anyway. Recently I read a post introducing development best practices(it's ibm internal site), it says: - While the OSGi Framework will clean up services and service references, it is still good programming practice to clean up what you allocate.
- If you register services in the start() method, unregister the services in the stop() method.
- If you create (and open) a ServiceTracker in the start() method, close it in the stop() method.
- If you start threads or jobs in your start() method, make sure that the threads or jobs are terminated by your stop method.
Which practice I would choice when programming OSGi service under Equinox? Thanks Best Regards Zhu Meng Xin IBM Workplace Client Technology Tel: 86-10-82452244-52342 Fax: 86-10-82452887 NOTES: Meng Xin Zhu/China/IBM E-mail: zhumx@xxxxxxxxxx_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev
|