Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Re: RCP Application doesn't shut down OSGi console

Thank you for the promptness.

The problem isn't yet solved, but here is an update on our situation:

osgi.noExit was undefined, as a precaution we set it to false in the ini
osgi.noShutdown is also set to false.

We are running the application with the following command:
java -cp . -jar org.eclipse.osgi_3.3.0.v20070530.jar -console

The applicationId is referenced in the INI file, and corresponds to the class through the plugin.xml

The Application class is as follows:

public class Application implements IApplication {

public Object start(IApplicationContext context) throws Exception {
		Display display = PlatformUI.createDisplay();
		try {
ApplicationWorkbenchAdvisor window = new ApplicationWorkbenchAdvisor();
			
int returnCode = PlatformUI.createAndRunWorkbench(display, window);

			if (returnCode == PlatformUI.RETURN_RESTART)
				return IApplication.EXIT_RESTART;
			else
				return IApplication.EXIT_OK;
		} finally {
			Thread.sleep(1000L);
			display.dispose();
		}
	}

	public void stop() {
		final IWorkbench workbench = PlatformUI.getWorkbench();
		if (workbench == null)
			return;
		final Display display = workbench.getDisplay();
		display.syncExec(new Runnable() {
			public void run() {
				if (!display.isDisposed())
					workbench.close();
			}
		});
	}
}

It worries me that I haven't encountered a "readAndDispatch() loop", I will look into this immediately and report back if finding this solves the problem.

Any further advice or requests for information would be helpful.
Thank you.

- Darren


On Thu, 30 Aug 2007 23:39:13 +0100
 "Alex Blewitt"  wrote:
It depends how you are launching it. If you've got 'osgi.noExit=true' then I'd expect to see that behaviour. Are you running with eclipse -application xxxx? If so, I'd expect that when your application returns from the run() method, it would shut down the framework. Do you know you are returning from that call? How are you determining that your application is shutting down; is it a case of having a window be closed? If so, is you readAndDispatch() loop taking care of
the fact that it has been closed?

You might want to find (with the console) by using 'getprop osgi.noExit' to find out what the value is. You could also do a 'ss' after you think you've closed your application; that would show which bundles were stopped (INSTALLED), and which were STOPPING. It may be that one of your stop() calls is blocking or there's some kind of deadlock, and since the bundles are still awaiting shutdown, the
framework can't stop either.

Alex.

On 30/08/2007, Volodymyr Babiy wrote:
Hello

We just have one small question to ask.

Current situation:
We are running independent bundles, which we have developed, inside of the Equinox framework. Our problem is that when we manually shut down our Application, the OSGi console does not automatically shut down. When we run the application from our EXE, the OSGi console is not visible,
but the JARs are still in use after the application is
manually closed. This problem becomes apparent when we try
to delete the JAR bundles when we try to uninstall our
Application. The Application uses the RCP platform, all
our bundles communicate through Declarative Services, and
all of our bundles are coded in Java.

Notes:

- When we run our application through Eclipse Plug-in
Development, the console DOES shut off naturally when we
close the Application.

Desired outcome:
We want a safe way to shut down the entire OSGi framework right after the user manually closes the Application when
it runs from the stand-alone EXE form.

So far, the only way we can turn OSGi off is to ensure
that the console is on, and to issue an 'exit' command
manually, but this is not desirable. We have tried
deactivating all bundles (including bundle #0) and the
console remained on. All literature seems to suggest that
the system should shut down automatically once the
Application has been closed, but we haven't been as
fortunate. We need help in understanding what we are
missing.

Any help, suggestions, or advice would be greatly
appreciated by our team.
We would like to thank you in advance for your attention.





			
	
		
	
	
		
	



Back to the top