[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Declarative Services with RCP Plug-in Extensions
- From: "Darren Janeczek" <dc_janeczek@xxxxxxxxxxxxx>
- Date: Mon, 17 Dec 2007 11:23:41 -0500
- Delivered-to: firstname.lastname@example.org
Thanks for your help Thomas, your clue about our config.ini not requiring all of those bundle-startups led me on the path to the solution. It turns out that we were using the OSGi launcher and not the Equinox/Eclipse launcher and that's why we needed to explicitly start all of those bundles in order to start our RCP Application. Now that we're using org.eclipse.equinox.launcher, the Application is shutting down just fine and our configurations are much cleaner.
Only now that I looking back at your email again, do I see that you mention that we should be using org.eclipse.equinox.launcher.
> Which DS implementation are you using? The latest version of DS on
> the Equinox download page should fix the thread safety issues. The
l> atest DS implementation is provided by Prosyst and has many
> improvements over our old Equinox implementation of DS.
Is it best to use the latest 1.0.0 version, or the latest 0.1.0 version?
>>> Thomas Watson <tjwatson@xxxxxxxxxx> 11/28/07 11:20 AM >>>
equinox-dev-bounces@xxxxxxxxxxx wrote on 11/27/2007 06:19:11 PM:
> 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.
> 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?
> Is it remotely possible that the org.eclipse.equinox.ds resolver's
> ConcurrentModificationException during the startup of an OSGi
> framework could have anything to do with preventing the entire OSGi
> framework from shutting down automatically after the RCP Applicationis
Which DS implementation are you using? The latest version of DS on
the Equinox download page should fix the thread safety issues. The
latest DS implementation is provided by Prosyst and has many
improvements over our old Equinox implementation of DS.
> 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?
By default the framework should be shutdown by EclipseStarter once
your application has ended. This should cause all your bundles
to be stopped automatically. I suspect you are having issues with
non-daemon threads still being active. When shutting down we
never call System.exit, we assume that all non-daemon threads
will be stopped by the shutdown process. This is what Alex was
describing in his response.
If you use the launcher org.eclipse.equinox.launcher it does
actually exit with System.exit as long as you don't use -noexit
option. See the quick start guide for instructions on using
the launcher. http://www.eclipse.org/equinox/documents/quickstart.php
> About our configuration:
> The framework is started up with the following command:
> java -cp . -jar org.eclipse.osgi_3.3.0.v20070530.jar -console
> config.ini is as follows
> osgi.bundles= \
> org.eclipse.osgi.services@4:start, \
> org.eclipse.osgi_3.2.0.jar@start, \
> org.eclipse.update.configurator@3:start, \
> org.eclipse.core.runtime@4:start, \
> org.eclipse.core.runtime.compatibility.auth@4:start, \
> org.eclipse.core.commands@4:start, \
> org.eclipse.core.contenttype@4:start, \
> org.eclipse.core.jobs@4:start, \
> org.eclipse.core.expressions@4:start, \
> org.eclipse.core.databinding@4:start, \
> org.eclipse.equinox.registry@4:start, \
> org.eclipse.equinox.preferences@4:start, \
> org.eclipse.equinox.event@4:start, \
> org.eclipse.equinox.app@4:start, \
> org.eclipse.equinox.log@4:start, \
> org.eclipse.equinox.common@2:start, \
> org.eclipse.equinox.ds@4:start, \
> org.eclipse.swt@5:start, \
> org.eclipse.swt.win32.win32.x86, \
> org.eclipse.jface@4:start, \
> org.eclipse.jface.text@4:start, \
> org.eclipse.jface.databinding@4:start, \
> org.eclipse.text@4:start, \
> org.eclipse.ui.workbench@4:start, \
> org.eclipse.ui@4:start, \
> org.eclipse.help@4:start, \
> org.eclipse.rcp@4:start, \
> com.ibm.icu@3:start, \
> [All of our bundles follow at run level 4]
You should not have to start every bundle here. You
should only have to start equinox.common, core.runtime
and update.configurator and any bundles which need to be
activated because they publish OSGi services (this includes
DS, event, log etc.). Something like this should work:
[All of your bundles that publish OSGi services]
In this case update.configurator should ensure all your
other bundles get installed before core.runtime is started.