Community
Participate
Working Groups
The current eclipse application container expects an application to execute in a single thread and block on the thread until it has finished and has returned an application result from IApplication.start(...). The IApplication.start(...) method is expected to block on the current thread until the application has finished and it returns an exit result. There are cases where this is not desired. Imagine an application that wants to share the SWT Display which is running the UI event loop on the main thread. Such an application has no use for blocking on the current thread to run the UI event loop itself. It would be nice if such an application could return from IApplication.start(...) and deliver the exit result later asynchronously. This way the IApplication.start(...) method could hook into the Display running on the main thread and then return immediately and not waste an extra thread blocking. Later when the application has exited it could deliver the exit result to the application container to indicate that the application has finished.
Created attachment 160621 [details] patch + tests Here is a patch that adds the following API to IApplicationContext: /** * Exit object that indicates the application result will be delivered asynchronously. * This object must be returned by the method {@link IApplication#start(IApplicationContext)} * for applications which deliver a result asynchronously with the method * {@link IApplicationContext#setResult(Object)}. * @since 1.3 */ public static final Object EXIT_ASYNC_RESULT = new Object(); /** * Sets the result of the application asynchronously. This method can only be used * after the application's {@link IApplication#start(IApplicationContext) start} * method has returned the value of {@link IApplicationContext#EXIT_ASYNC_RESULT}. * @since 1.3 * @throws IllegalStateException if {@link IApplicationContext#EXIT_ASYNC_RESULT} was * not returned by the application's {@link IApplication#start(IApplicationContext) start} * method or if the result has already been set for this application context. */ public void setResult(Object result);
Created attachment 160695 [details] patch + tests More javadoc updates to IApplication.start(...)
Created attachment 160711 [details] update patch + tests There is a concern with the previous API for IApplicationContext.setResult(...) because it could allow any random code to set the result of an application context. We should really only allow the IApplication instance to set the result of an application context. This patch adds an additional parameter for passing the IApplication instance when setting the result. This instance must be the same instance of IApplication that is associated with the application context; otherwise an IllegalArgumentException is thrown. This provides an implicit token (the application instance) that must be used to allow a caller to set the result. Application instances are not typically shared outside of the context of the IApplication implementation. This will provide us with a level of protection by preventing unwanted calls to setResult.
I released this patch to head.
I am seeing an unfortunate change in behavior of eclipsec.exe exit codes, I think I tracked it down to this change. Prior to this (specifically with org.eclipse.equinox.app_1.3.0.v20100108) an application throwing an exception resulted with e.g. eclipsec.exe exiting with exit code 13. (Looks like this is a standard behavior of EclipseStarter#run, in case 'eclipse.exitcode' is left null.) Now the exit code is 0. Specific use case is running of an org.eclipse.ant.core.antRunner with ant script that fails (exception thrown by one of the tasks) - it used to be possible to detect the failure based on the non-zero exit code. It seems to be related to that prior to this fix EclipseAppHandle#run was not setting the eclipse.exitcode in case of exception - Activator#setProperty was after the 'finally' block. Now it is in the 'finally' block, via setInternalResult. And the logic there appears to translate null into 0, vs EclipseStarter#run null -> 13. Observed on Windows 7 64 bit, Eclipse 3.6.
(In reply to comment #5) > I am seeing an unfortunate change in behavior of eclipsec.exe exit codes, I > think I tracked it down to this change. I suggest you open a new bug to track this issue.
(In reply to comment #6) > (In reply to comment #5) > > I am seeing an unfortunate change in behavior of eclipsec.exe exit codes, I > > think I tracked it down to this change. > > I suggest you open a new bug to track this issue. Done, bug 321386.
