Community
Participate
Working Groups
StatusManager is part of the UI and can not be used in headless applications. The API only uses non UI classes and interfaces. But the class is defined in eclipse.ui.workbench. This prevents us from using it in headless applications. Is there a reason why it ended up in platform UI? I think it should be part of Platform Runtime! ==> now, we have to implement our own status manager that can be used for headless applications :-(
We should consider moving the facility to the Platform Runtime.
How this can be achieved (API)?
In Riena (http://www.eclipse.org/riena/) we have something similar called ExceptionHandlerManager that is responsible for handling exceptions. The exception handler manager (service) asks registered exception handlers (extension point) to handle the exception (using the chain of command pattern). The exception handler manager will be called from execution roots to handle uncaught exceptions. We use this mechanism on both client and server side and it is independent of UI. However, a specific handler can contain UI code. We should explore if there is a possibility for joining.
Stefan, could you please point me which classes (and projects) I should look at?
Christopher, sure, start with the SimpleExceptionHandlerManager in bundle org.eclipse.riena.core. This is a service implementation that is used here: - ApplicationAdvisor in bundle org.eclipse.riena.navigation.ui.swt This covers uncaught errors in the UI - StartupsSafeRunnable in bundle org.eclipse.riena.core This covers uncaught errors for bundles that get started eagerly - RienaHessianDispatcherServlet in bundle org.eclipse.riena.communication.publisher.hessian This covers uncaught errors on the sever side The exception handler manager uses instances of IExceptionHandler (bundle org.eclipse.riana.core) to handle the uncaught exceptions. hth Stefan
Created attachment 126556 [details] some work in progress (even does not compile)
Created attachment 126557 [details] mylyn/context/zip
Next time when you move a bug to yourself, please at least add me to the cc list, please. Looking at the patch, your idea is quite different from what I think is the right fix for this issue. You can be right though. Could you explain what is your plan for the bug? Some thoughts on the bug: 1) We should consider creating a separate core status handlers plug-in. This plug-in could provide the status handler ext. point and the mechanism to manage it. core.runtime could have an optional dependency to it. This is the purpose of bug 282157. 2) IMO, this bug is a duplicate of bug 282157. This bug could perhaps be used to re-implement the status handler mechanism in the ui plug-in to use the one implemented in the core. 3) John A. should be added here.
Sorry for this assignement change. My plan of work currently is limited to opening bug 282157. Below is my vision: In this bug I'd like to introduce OSGI-integrated logging service, which could be later adopter by other products. I know it looks like duplicate, but it is not. Subsequent work needs to be done: 1. Further integration of ui.StatusManager and Equinox StatusHandler with separation of "reporting" and "handling" facilities. 1a. Progress needs new solution of error handling to solve bug 279748 (jobs are not kept after the dialog is shown) and correctly resolve double error reporting (one issue is logged from core.jobs, another one, wrapped in different class[2] is reported by ProgressUI). 2. Currently we have 3 classes that act for the same thing: IStatus, StatusAdapter, FrameworkLogEntry. They need to be unified into one item (IExtendedStatus) which would be flexible enough to serve all purposes. This work is partially done in 282157. 3. Removing RuntimeLog. In bug 282157 it is deprecated, but actually it needs to be fully removed at the end of 3.6 cycle. This should be easy, because we will have Equinox StatusHandler at this point. 4. IExtendedStatus derived from IStatus will allow for (finally!) hijacking jface ErrorDialog.openError. One consistency issue less. 5. StatusAdapter should be deprecated (to avoid containerism containerism) and IStatus should be discouraged (and recommend IExtendedStatus). Full compatibility with IStatus-based JFace can be achieved (no need to wrap in StatusAdapter). 6. Deprecating StatusManager if possible. I believe that those 5 issues allows for proper use of StatusHandling in OSGI apps.
One more reason for the refactoring can be found at bug 173272, comment 5.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
It was reported long ago but I think it is still actual. Do we have a clear vision about error reporting best practices at the moment?
