Community
Participate
Working Groups
Yesterday I have been involved in some fun p2 debugging sessions, and felt first hand the awkwardness of our debug / logging story. The bottom line is that our .options file story just does not cut it. It may have been a good story 10 years ago but now it is an encumbrance. - It is a file that nobody knows about or knows how to enable, it relies on keys that are specific to each part of the system and it does not compose very well. - The debug info is directly written out on the sysout (not the best place) - Can't change the debugging level at runtime (or at least not easily) What I'm proposing is to change our debug logging to use slf4j. This pretty much gets us out of the business of logging, and leave the final decision to the integrator on which logging backend to use (log4j, logback, ...), and only add 37k footprint (slf4j-api.jar). For the p2 being shipped in the SDK, we could decide to include the logback bundle to make it easy for ppl to use.
Are you talking about logging or tracing? I don't think that we should opt out of the Eclipse logging strategy unilaterally in p2. For better or worse there are quite a number of folks who have built up infrastructure that understands that log data. The trace information managed by the debug options could be put out to slf4j (whatever) certainly. Can you give some concrete examples of what some current debug option use would look like if we moved to slf4j?
slf4j is a good logging client api so I wouldn't want to discourage that however the challenge with slf4j is that it binds itself to exactly one-backend -- tough in an environment like Eclipse. For the eclipse platform case, which is probably going to be fairly important for usage, if someone were to write an slf4j binding to the "extended" log service (in the framework bundle) that would be useful because then we could still have all of the logging from the various client logging apis go to one place. To do integration for the back-end you would have to write a LogListener for the appropriate backend but that's a small job to do.
(In reply to comment #1) > Are you talking about logging or tracing? I meant tracing. For example the code in DebugHelper. I would also channel the eclipse logs into this to have one consistent way of viewing things, but this would be in addition to the .log file.
(In reply to comment #2) > slf4j is a good logging client api so I wouldn't want to discourage that > however the challenge with slf4j is that it binds itself to exactly one-backend > -- tough in an environment like Eclipse. The backend is left to the choice of the final integrator / user. We have to remember that this is not an integration point to build upon but a final destination for the log data. For example, as a user in some case I'm interested in logging in log4j, in others in logback on the filesystem, in a common logging system for my company... As the user of the application, this is really my choice, much like I pick the size of my font. > For the eclipse platform case, which > is probably going to be fairly important for usage, if someone were to write an > slf4j binding to the "extended" log service (in the framework bundle) that > would be useful because then we could still have all of the logging from the > various client logging apis go to one place. To do integration for the back-end > you would have to write a LogListener for the appropriate backend but that's a > small job to do. In m2e we have explored several things including something that bridged eclipse to slf4j. I'm happy to point you at the code if you think this is useful
Did you look at the extended log service at all in your investigations? It would be interesting to know if it meets your needs and if not, why not.
FWIW, we also use SLF4J for logging. However, we rely on the DebugOptions to enable/disable tracing. It's usually better to have this separation than the default one-logger-per-class hierarchy. As for logging, we also have a framework hook which routes all Eclipse logging into SLF4J. :) From my personal experience, the SLF4J API feels more comfortable to work with. It's convenient to use and has neat features like delayed string substitution, MDC/NDC. Given the nature of pluggable backends in combination with the already existing Logback backend and its plenty of appenders, routers, filters, etc, the extended log service also falls behind in terms of possibilities.
I think it makes a lot of sense to use SLF4J as client logging api in p2 especially given some day it might be interesting to run at least some of the p2 code outside of OSGi (or god forbid Equinox). Probably the only place it makes sense to make "direct" use of the ExtendedLogService is in the framework bundle or perhaps some of the other relatively low-level equinox specific and OSGi service implementations. The idea was to create bindings to it as opposed to using it directly as a client api and in particular SLF4J and Commons Logging were the bindings cared about. FWIW there was an ExtendedLogService binding for SLF4J written that I thought was in the incubator but I can't seem to find it now; if there's interest I'll look for it but also could probably recreate it pretty easily. The binding worked well and we had supported everything in the SLF4J API including MDC/NDC and the delayed string substitution Gunnar mentions. A few things the extended log service allows that SLF4J does not is that it's "log entries" in addition contain the actual bundle that logged the message. This let you differentiate and find the real origin in situations where you have more than one instance of a class loaded. The other notable feature is that the extended log service allows you to log an arbitrary "context" object which is needed by some logging systems like the Eclipse Log but also auditing log systems that typically log richer context objects like Common Base Events. For a logging backend Logback again is a good choice but as pointed out this is entirely up to the integrator. The Extended Log Service lets multiple backends listen and filter on log entries as appropriate so you could have a targeted eclipse, logback, log4j, and some proprietary system all in play. The other notable capability is that the approach is OSGi friendly and for example lets you add/remove or start/stop and reconfigure a backend bundle. I don't want to push a hard sell on the Extended Log Service but I think as a binding for SLF4J at least in the Eclipse SDK case it's probably worth taking a good look at.
I assume this is not something that we plan on doing for 3.7?
If anyone is interested to contribute, please chime in.
Moving off the plan.
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. If the bug is still relevant, please remove the stalebug whiteboard tag.
