Community
Participate
Working Groups
Equinox does contain two separate mechanism of dealing with problems. One is FrameworkLog and the second one is IStatus. Those facilities are not fully compatible, if something is logged from Equinox level we are not able to notify the user. It is necessary to unify those mechanisms, so org.eclipse.osgi should allow for listening to logs, and org.eclipse.equinox.common should introduce general statushandler (very simple and not specialized).
Created attachment 140600 [details] very initial work Feel free to comment
*** Bug 286924 has been marked as a duplicate of this bug. ***
Created attachment 182613 [details] A patch adding a basic status handling service to osgi
Created attachment 182614 [details] A compatibility layer IStatus must be removed from org.eclipse.osgi.common. That's why a separate jar/project is needed to allow easy patching of all products that use org.eclipse.osgi.common but not org.eclipse.osgi.
How does this relate to bug292135. I disagree with adding new listeners to existing Eclipse APIs. I would much prefer to investigate the use of the Extended Log Service implementation we have in Equinox. From the changes in the patch I do not understand the need to move this to the framework. The framework has no dependency on it. Why can this not stay in org.eclipse.equinox.common?
(In reply to comment #5) > How does this relate to bug292135. It tries to solve the same issue but in a different way (introducing a service which contains logging instead of adding new listeners to the framework log). > I disagree with adding new listeners to existing Eclipse APIs. I would much prefer to investigate the use of the Extended Log Service implementation we have in Equinox. > From the changes in the patch I do not understand the need to move this to the > framework. It will not work. Error handling is a core functionality and once you move it outside the org.eclipse.osgi, you will not be able to report to the user errors that happen in that plugin. For me it is a choice between hacking the frameworklog or adding a new service. > The framework has no dependency on it. Not yet. Next steps are: patching OSGi to use the statushandling service integrate existing mechanism (like UI StatusManager) with the service to achieve total consistency of status handling. > Why can this not stay in > org.eclipse.equinox.common? As I have said before, it is a must to use the service in the osgi.
As a design pattern, we should avoid methods that register/remove handlers. Instead we should use white board patterns where handlers are registered as OSGi services. (In reply to comment #6) > (In reply to comment #5) > > How does this relate to bug292135. > It tries to solve the same issue but in a different way (introducing a service > which contains logging instead of adding new listeners to the framework log). I really think we should take a look at the extended LogService we have in equinox. We can think about adding it to org.eclipse.osgi if needed. > > > I disagree with adding new listeners to existing Eclipse APIs. I would much prefer to investigate the use of the Extended Log Service implementation we have in Equinox. > > From the changes in the patch I do not understand the need to move this to the > > framework. > > It will not work. Error handling is a core functionality and once you move it > outside the org.eclipse.osgi, you will not be able to report to the user errors > that happen in that plugin. For me it is a choice between hacking the > frameworklog or adding a new service. Instead of adding another listener type to org.eclipse.osgi I would rather move to using the extended LogService.
I agree with comment 7. Today we already have *four* ways of logging in Eclipse (FrameworkLog, ILog, LogService, ExtendedLogService). There are numorous other logging APIs out there as well. None of them really integrates with any of the Eclipse APIs. Adding IStatus as well as another service to the game doesn't really simplify things. I did try to centralize logging of some of the APIs into a central system. There are a few issues to overcome. The most interesting problem to solve is the dynamic system of OSGi. A simple listener isn't enough because it might miss events sent when the listener isn't available yet. But some events are important enough so that they should be buffered/captured somewhere for later retrieval. If you look into the log, most of the messaged aren't relevant to end-users. They maybe interesting to webmasters but that's headless/runtime only not IDE. As far as I remember the request is about presenting the users with an error dialog if some bundles failed to resolve/couldn't be started. This kind of information should be captured and stored somewhere in the framework (perhaps simething like EnvironmentInfo). It is of interest to a lot clients. Everybody could acquire this info, convert it to an IStatus, a JMX bean or whatever. Thomas, in terms of centralizing logging into a single API, do you think a similar approach to how the console replacement is done in 3.7 should be implemented?
(In reply to comment #8) > Thomas, in terms of centralizing logging into a single API, do you think a > similar approach to how the console replacement is done in 3.7 should be > implemented? This is different from the console replacement IMO. For logging we want something that all levels can use and count on, including the core framework itself. This is the reason for the FrameworkLog we currently have. The framework could actually live and function without a console, but we have come to depend on some type of logging facility for framework errors. What I would like to do is unify on the (Extended)LogService down at the lowest framework core level so that we can feed everything through the LogService. This of coarse assumes the (Extended)LogService in Equinox gives us the necessary power to do what we need. For example, plugging in a reader that logs to commons logging or slf4j etc. I need to discuss this with Simon Kaegi, but I believe he already proved this could be done with the (Extended)LogService.
One logging API is certainly good idea, and I would like to extend it to cover also applications with UI, which are not limited to logging only, but allow some kind of interaction (troubleshooting). I believe that complete separation of problem reporting and handling is required. We need one place to report a problem regardless of who are we (that's why this needs to be a part of org.eclipse.osgi, so any plugin can report an error there, and it will be consistently handled), and configurable mechanism of handling those problems (including, but not limited to logging). Long time ago I have recorded a screencast to show what is the goal (sorry for the poor quality): http://www.cs.put.poznan.pl/kdaniel/resorces/statushandlingDecorators.htm
Not that we have released a fix to bug292135 what else is needed to close this bug. The latest discussion seems to center around changes to IStatus. I'm not really sure that is the best approach. The ExtendedLogService in the core framework now allows you to create your own named loggers and allows you to pass whatever context you want to the log listeners. You should be able to use this to build a layer on top for logging anything you need.
(In reply to comment #11) > Not that we have released a fix to bug292135 ... ^^^ NOW I meant to type "Now that we have released ..."
(In reply to comment #11) > The ExtendedLogService [...] allows you to pass [...] context [...] to the log listeners. First of all, thanks for the fix! > You should be able to use > this to build a layer on top for logging anything you need. This still is not so simple. You are asking me to write my own service which will utilize contexts passed together with log entries. I am fine with that, but that service will be available only in plugins dependent on UI. One still will not be able to write an error, and then show user error dialog if the ui is present. Not to mention processing it in any way, or giving hints like (Block user work, do not be intrusive, etc etc).
(In reply to comment #13) > (In reply to comment #11) > > The ExtendedLogService [...] allows you to pass [...] context [...] to the log listeners. > > First of all, thanks for the fix! > > > You should be able to use > > this to build a layer on top for logging anything you need. > > This still is not so simple. You are asking me to write my own service which > will utilize contexts passed together with log entries. I am fine with that, > but that service will be available only in plugins dependent on UI. One still > will not be able to write an error, and then show user error dialog if the ui > is present. Not to mention processing it in any way, or giving hints like > (Block user work, do not be intrusive, etc etc). Is this just a request to add information to IStatus then? Perhaps more codes or something? Either way I think you must use a different named logger (e.g. "org.eclipse.user.status.handling"). The LogListener (implemented by the UI) can handle the various status types (ERROR, WARNING, etc) how ever it wants, perhaps it could even be configurable.
(In reply to comment #14) > Is this just a request to add information to IStatus then? Perhaps more codes > or something? Either way I think you must use a different named logger (e.g. > "org.eclipse.user.status.handling"). This would be awesome, but at certain moment of time this idea was declined, because users are expected to create custom statuses (like CVSConnectionStatus) which should carry custom data. > The LogListener (implemented by the UI) > can handle the various status types (ERROR, WARNING, etc) how ever it wants, > perhaps it could even be configurable. What I want is to have continuous flow of status. It is reported somewhere, let's say CVSUpdate operation throws a CVSConnectionStatus. Then I want to plug some handler, which will f.e. check the ping to the server and add it to the status, so the user will see a message. This kind of mechanism is implemented in JDT (for resolving project issues). It can be implemented in any component, but the point is to have one central mechanism. And this require either the extension of IStatus either generic Map context passed together with status.
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.
