Community
Participate
Working Groups
Mylyn integrates with a number of libraries from Apache and other providers many of which use the Apache commons logging framework. To avoid potentially confusing output to appear on the console Mylyn sets the "org.apache.commons.logging.Log" system property to "org.apache.commons.logging.impl.NoOpLog" which suppresses any output (users can override this behavior by explicitly setting the system property in which case it is not modified). Unfortunately, the logging configuration affects all consumers of commons logging. This can be problematic if other consumers that are not aware of Mylyn's default configuration intend to configure logging in a different way (e.g. bug 353168). Since logging is a platform concern it doesn't seem right to have explicit logging configuration in Mylyn. What is the best way to configuring logging? Should there be support in platform? Should each logging system be configured by separate bundles that are included on a distribution package level? Any other suggestions? Related discussions and bugs: * Discussion about SLF4j: http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05659.html * Logging output in EPP Java package: 340312 * Common logging service in platform: bug 292135 * Use SLF4J for p2: bug 338232 * Bridging legacy logging APIs: http://www.slf4j.org/legacy.html
There are some orbit bugs that discuss this issue also. Most recently ... the one with one possible approach to helping the situation is bug 329524 (even though its marked as a dup of a "won't fix" bug). The high level approach was to include a fragment that "controlled" logging ... but, I think, this would only make sense for something like an EPP package, where the package participants and maintainer all agreed on what the logger should be. No "general purpose" feature should include it. I suppose there might be some very-special-purpose features that included (nearly) only a fragment to control logging, never installed automatically from Eclipse, but which users could pick from the common repo to do logging as they'd like. But, I am not very knowledgeable about logging, so there might be many other solutions as far as I know. I will assign this to Steffen for eventual resolution. Please add yourself to the CC list if you are interested in this topic. It is an important, long standing problem.
Any thoughts on this? Almost *all* of our users are using mylyn, which overrides our logging configuration with NoOpLog and means that we can rarely get meaningful insight into errors. https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&id=353168
Pointers to other recent discussions on the topic: http://wiki.eclipse.org/Architecture_Council/Meetings/June_14_2012 http://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg01864.html
Most of the "plain Eclipse" logging / tracing is controlled through the Platform: eclipse.exe -debug /path/to/.options/file I think it would make sense to define a Policy for other loggers on Platform level as well. If everybody knows that the "org.apache.commons.logging.Log" System Property needs to be overridden to produce some logs, and this can be configured in eclipse.ini for instance, the problem is at least mitigated ... Thoughts ?
IMHO, logger configuration should be controll(ed|able) by the product. I have a patch kicking around somewhere to create a new "Eclipse-BuddyPolicy: product" that would redirect back to the product bundle. I can dust this patch off and submit if there's interest -- it was pretty simple but required uncommenting some service lookup code in org.eclipse.osgi.internal.loader.buddy.PolicyHandler#getPolicyImplementation().
Marcel, I'll hand this over to you since you mentioned on the last AC call that you were looking into this topic.
May be a silly question, but haven't we all pieces in place? I created a set of bundle projects that use log4j1.2, commons logging, slf4j, and java util logging. Each project imports the logging framework packages it requires (org.apache.log4j, org.apache.commons.logging, org.slf4j) and performs a info-log output in its bundle activator. The implementations of every logging package is provide and exported by a plugin org.eclipse.logging.slf4j which (internally) uses SLF4Js bridge implementations. This plugin transparently maps all log events to logback. It also declares a default logback logging configuration that keeps the console clean from debug messages. Does that solution have any critical drawbacks I'm not aware? If not, I'd propose to create a feature that: 1. contains various bridge plugins that export the logging apis (versioned + vendor=eclipse tag) and map all legacy logging calls transparently to slf4j. 2. contains org.eclipse.logging.slf4j.logback fragment that defines a default logging configuration using logback. The bridge bundles already exist in orbit (but may need modification). Users of the legacy logging frameworks then have to update their bundle manifest.mfs to use package imports rather than require-bundle and may have to change their builds to require the newly create org.eclipse.logging feature. That should be all needed to consolidate the logging output. For sure, as Brian said, there can only be one such feature per product. Extenders that want to modify the logging output have to modify the logback.xml file directly. One may also consider to allow users/programms to dynamically reconfigure the logging framework. But this is a discussion on its own I guess. I'd like to get your comments on this to check whether I missed some requirements. Thanks.
That sounds like a great proposal! For bridging legacy logging APIs we have the following in Orbit: org.slf4j.log4j - provides the log4j API org.slf4j.jcl - provides the Apache Commons Logging API org.slf4j.jul - redirects logging from java.util.logging to SLF4J As backend providers log4j and logback are available. For Mylyn for example we could get by with org.slf4j.jcl. From a quick glance it looks like the Orbit bundles that we use already use package import for commons logging so no changes should be needed there. In order for users to get the logging configuration we could re-distribute the Orbit logging bundle/feature from the Mylyn site for plug-in based installs. I guess EPP packages would already contain the logging bridges for Log4j, commons logging and JUL so most projects simply wouldn't have to worry about this at all.
I've done something like this for a RCP-based product. We had to do two additional things: (1) Create an SLF4j -> Eclipse Logger backend, so as to push logging messages back into the Eclipse logger. This backend will be necessary for the SDK at least, and many RCP apps will want this too. This backend is pretty straightforward except that the Eclipse logger has no notion of DEBUG or TRACE. We looked at the "eclipse.log.level" property and mapped "trace" and "debug" to INFO and instead prepended "[TRACE]" or "[DEBUG]" to the log message. (2) Create a OSGi LogService -> SLF4j bridge; the Eclipse logger re-logs messages to the OSGi logger. This was slightly complicated as we had to handle recursive entries when using the SLF4j -> Eclipse logger backend. I'll see if I can open-source these implementations. Where would we want these to live?
(In reply to Brian de Alwis from comment #9) > (1) Create an SLF4j -> Eclipse Logger backend, so as to push logging > messages back into the Eclipse logger.This backend will be necessary [..] Indeed. > (2) Create a OSGi LogService -> SLF4j bridge; the Eclipse logger re-logs > messages to the OSGi logger. This was slightly complicated as we had to > handle recursive entries when using the SLF4j -> Eclipse logger backend. > > I'll see if I can open-source these implementations. Would be great to have a look and reusing them! > Where would we want these to live? At the moment I'd make it part of the GSOC project/git repo and migrate it to platform or EPP later on if the community agrees. But no concrete plans yet. The core system will not need much code IMHO. Maybe we can contribute the bridge APIs to SLF4J.
FWIW, there is some progress in Gerrit [1]. Brian, I saw that SLF4J 1.7.7 comes with an "osgi-over-slf4j.jar" which sounds similar to what you described in comment 9 (2). Since the code you mentioned is not open-sourced yet and neither (1) or (2) sound like a big amount of code is needed, I'd continue as follows: 1) provide a simple appender as described by Brian in comment 9 (1). 2) provide a default logback configuration file to bootstrap the logging system with some reasonable defaults. 3) Then, I'd like to ask Ashwin (GSOCer) to migrate one existing (Mylyn) bundle to use the new logging configuration as proof-of-concept. 4) Thereafter we may go for some dynamic configuration features for that system. [1] https://git.eclipse.org/r/#/c/26955/
Created attachment 243413 [details] Alternative LogReaderService implementation Marcel — when I looked the osgi-over-slf4j bundle, which was a while back when it first came out, it didn't work well in an Eclipse context. It provided a LogService implementation via OSGi DS. But so does Equinox and as most consumers only log to the first service instance, the Equinox instance wins and the logs were never redirected to SLF4j. Taking a quick gander at 1.7.7, it doesn't look like it has changed. But thinking about it a bit more, it might actually be as simple as setting the service.ranking property so that this LogService takes precedence. I did some digging around the code I was looking to open-source and it turns out the source in question was code that I had originally written and granted them permission to use. So I've attached my original code here; this code doesn't handle the "recursive entries when using the SLF4j -> Eclipse logger backend" alluded to above. It's EPL and I'm happy for it to be renamed to org.eclipse if you choose that root.
(In reply to Brian de Alwis from comment #12) > It's EPL and I'm happy for it to > be renamed to org.eclipse if you choose that root. Brian, thank you for the contribution. I'll need some time to play with it but it looks like I'd expect it to look like ;-)
We would be ready to integrate a new "org.eclipse.[recommenders|core|epp].logging feature" into one of the epp packages for further testing. There was a brief discussion on architecture-council mailing list. There is also a basic slide deck describing what was done. See [1] for both. *Note that any (3rd party) bundle that makes direct use of a logging framework via "require-bundle" can not make use of this solution.* How do we continue? To get a slow migration started, the logging feature needs to be present in the platform or the epp packages. I'd propose to move that code to o.e.epp.logging and once there I'd ask package maintainers to add it into their packages. FWIW, the GSOC code is hosted in [2]. It certainly needs some adjustments before is can go into the products but the general structure is fine IMHO. [1] https://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg02285.html [2] https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.logging.git/tree/
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. -- The automated Eclipse Genie.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/142.
