On Nov 28, 2007 12:19 AM, Darren Janeczek <dc_janeczek@xxxxxxxxxxxxx
I need some tips in narrowing down the cause of a problem We've been having in our RCP/OSGi application.
Our project is using Declarative Services to manage several bundles of services, and Eclipse Plug-in Extensions for various RCP components.
Everything seems to be running ok, but I'm having trouble with one thing: getting the OSGi framework and all of the bundles to shut down when the user closes the RCP Application window.
Do any of your bundles start threads? If so, make sure that they are set with thread.setDaemon(true), as otherwise they'll be an active thread which is keeping the VM active. I don't know what the DS services do with any threads that they create, but I'd think that would be standard behaviour.
First, a few questions:
I read articles like
http://www.eclipsezone.com/articles/extensions-vs-services/ and start to worry if our use of both DS and RCP plug-ins is somehow fundamentally problematic. There is a lot of functional overlap, but do these two approaches ever conflict? Is there a standard way to get them to work together to close down when the application is done?
I don't think these approaches conflict; after all, any Eclipse-based RCP has the ability to use OSGi services (and yes, shutdown cleanly when done). In any case, the registry is just another bundle.
Eclipse automatically seems to understand that we want the framework to shut down when the application closes, but when we take our jars out into the real world, the framework doesn't stop. I suppose this is understandable, since we tell OSGi to start the applications and to start the bundles and services. How do we tell OSGi that they are linked, and must be shut down when the Application closes?
You could put a call to OSGi's shutdown() method, but I don't believe that you need to do that. You could also iterate through all running bundles and call 'stop' if you wanted to during shutdown, but I don't think either are necessary.
You might want to check that the -noexit isn't being passed somewhere, which would of course prevent that from happening :-)
NB for debugging, you can view the console by a networked port (e.g. -console 1234) although you probably wouldn't want to use that in production use. But you might be able to use it to find out which bundles are still active.