Community
Participate
Working Groups
To support people that want to write logging code that does not depend on a particular framework, I'd like to suggest that we provide a slf4j-binding that redirects all to the Platform log. That way a plugin/bundle using SLF4J could be dropped into an eclipse without additional configuration or problems if there are multiple bindings.
I could provide an implementation but don't know what is the process to get a new dependency into "platform", in this case we would need the slf4j-api from orbit. org.slf4j.api (source) 1.7.30 21574 Tony Homer https://download.eclipse.org/tools/orbit/downloads/drops/R20211213173813/ Could it be just added to some kind of target platform that is then used for the whole platform build?
For prior art, please see * https://git.eclipse.org/r/#/c/96277/ * https://github.com/osgi/slf4j-osgi/ and https://www.eclipsecon.org/europe2018/sessions/integrating-slf4j-and-new-osgi-logservice-14 Compare also bug 549869 and bug 578109.
(In reply to Thomas Wolf from comment #2) > For prior art, please see > > * https://git.eclipse.org/r/#/c/96277/ > * https://github.com/osgi/slf4j-osgi/ and > https://www.eclipsecon.org/europe2018/sessions/integrating-slf4j-and-new- > osgi-logservice-14 > > Compare also bug 549869 and bug 578109. Thanks for sharing this, I searched the Bugzilla but nothing was revealed. I'm also using slf4j in my RCP application and also have used https://github.com/osgi/slf4j-osgi/ with success so it should be technically possible but is more a management-issue probably.
In general: if slfj4 logging is piped directly into the Eclipse application log, a lot of irrelevant log messages may suddenly be generated (and be visible in and cause updates of the Error view). A user would need to have a way to configure the logging, i.e., set detailed logging levels as one usually does, and the default config should probably filter out anything below ERROR level. DEBUG and TRACE logging should maybe not even go to the application log but to the trace mechanism in Eclipse? Or perhaps it'd be best to direct all this slf4j logging not to the OSGi/application log at all but to a separate .metadata/.slf4j-log? Having a way for fine-grained enablement/disablement/configuration of slf4j logging would be very helpful for problem diagnosis. But overloading the user or Error view with tons of slf4j log messages should be avoided.
The 2018 EclipseCon presentation is also available at https://www.youtube.com/watch?v=DJF0aETiNec .
(In reply to Thomas Wolf from comment #4) > Having a way for fine-grained enablement/disablement/configuration of slf4j > logging would be very helpful for problem diagnosis. But overloading the > user or Error view with tons of slf4j log messages should be avoided. In general: should we not avoid useless log messages at all? :-) So who decides whats useless and what not ... I actual get a lot of messages right now that seem useless to me, but if the bug me to much I report them to the corresponding project so they are probably not that useless at all. Hitting configure on the error-log already reveals a lot of configuration (OK, Info, Warning, ...) I can even filter ... so I think we are not that far and thinking about all "what-if" would probably delay this for another 20 years ...
(In reply to Thomas Wolf from comment #5) > The 2018 EclipseCon presentation is also available at > https://www.youtube.com/watch?v=DJF0aETiNec . Thanks for the link. My proposal would be that we a) add slf4j API so it could be used in platform SDK b) add slf4j-osgi (who can do that) to orbit, via maven, whatever ... c) if necessary extend the filters dialog
