Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] slf4j logging configuration in eclipse

The use case of aggregating logging from components that use different logging frameworks is solved by slf4j bridges:


On 3/17/2011 5:00 PM, Igor Fedorenko wrote:
Personally, I am in favour of a single logging backend.

Coexistence between bundles that use slf4j and bundles that use
logback/log4j/etc directly is the only advantage of allowing multiple
logging backends I can think of. Have said that, I am not sure if is
possible to make everyone happy in this case. For example, if some
bundles use logback and other use log4j directly, I do not believe it is
possible to have single log file that includes all message from. Unless
we decide to build yet another logging framework to aggregate them all.


On 11-03-17 04:18 PM, Vlad Tatavu wrote:
I also don't see the use case for having multiple backends used

IMO, the backend (or the logging framework) should be the choice of the
integrator. The platform should only provide a good default in case a
logging framework was not specified otherwise.


On 3/17/2011 3:36 PM, Igor Fedorenko wrote:
What is going to happen if there are multiple backends? Each log message
will be forwarded to all of them?

Also, what is the advantage of having multiple slf4j backends instead of
picking one (personally, I don't really care which one)?


On 11-03-17 03:12 PM, Thomas Watson wrote:
We have been having a similar discussion in Equinox in the p2 bug

One thing we could consider doing is to provide an Equinox
ExtendedLogService binding for SLF4J. Currently bindings to the
org.slf4j.api orbit bundle are "configured" as fragments of the
org.slf4j.api bundle and provide the org.slf4j.impl package. This allows
the slf4j api to get bound to the implementation and load the
implementation classes. The problem with this approach (as you point
out) is that it only allows a single binding (one fragment wins in
providing the host with the org.slf4.impl package).

The advantage of providing an Equinox ExtendedLogService binding for
slf4j is that it opens up the ability to have multiple backends (e.g.
logback, eclipse log etc.) configured with the system by implementing
OSGi LogService LogListeners that intercept the log entries and do what
ever is needed with them on the back end.


Inactive hide details for Vlad Tatavu ---03/17/2011 11:52:23 AM---Hi
all,Vlad Tatavu ---03/17/2011 11:52:23 AM---Hi all,

Vlad Tatavu <vtatavu@xxxxxxxxxxxx>


03/17/2011 11:52 AM

[cross-project-issues-dev] slf4j logging configuration in eclipse


Hi all,

I want to open a discussion about slf4j logging configuration in
eclipse. :)

For those not familiar with slf4j, see [1].

Currently, several eclipse packages/components use slf4j for logging.
Since slf4j is just a logging facade, if there isn't any logging
framework supported by slf4j "available", the logging defaults to noop.
There are several logging frameworks supported by slf4j (all major
ones), but only one should be available/used in a JVM. Depending on the
available logging framework and how that framework is configured, the
logging behavior can be quite different. If more than one logging
framework is available, slf4j picks one (pretty much randomly). That
can cause problems and it almost forces each eclipse component to load
and configure a specific logging framework. Which can be quite bad...
conflicting logging frameworks, configurations, etc.
As the number of components that use slf4j increases, the problems will
just multiply and it may become a nightmare to handle and configure
slf4j logging.

Add generic support for slf4j logging at platform level. That requires
two things:
- Choose a logging framework to be used by default - I propose logback -
for those not familiar with logback, see [2]
- Provide default configuration for the chosen logging framework
Currently, the m2eclipse component provides an optional bundle that
loads and configures logback for slf4j in eclipse. The bundle is pretty
generic and it provides the following functionality:
- Loads logback as logging framework for slf4j
- Default logback configuration if logback configuration was not
provided already through one of the standard logback configuration
mechanisms - see [3]
The default configuration:
- Provides a log file destination
- Pipes the logging into the console if -consoleLog is specified
- Pipes the WARN and ERROR logging into the eclipse log
- Pipes the logging into MavenConsole - this part is a little bit
specific to m2eclipse. On the other hand, the MavenConsole acts more
like a console viewer and it could be easily re-factored to not be maven
or m2eclipse specific.


Best regards,
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list
cross-project-issues-dev mailing list

Back to the top