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

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Yes, each listener gets the log entry, listeners have the option to filter. Vlad mentioned a configuration of logback in in m2eclipse that: logged to console for -consoleLog, to eclipse log, and to the maven console. So it seems like there is potential to want various backends that do different things. The other advantage is that we have bound the other eclipse logging APIs to the Equinox ExtendedLogService (ILog, FrameworkLog, RuntimeLog etc.). So the backend has the opportunity to respond to clients using these APIs as well, not just the slf4j clients.

Tom



Igor Fedorenko ---03/17/2011 02:36:16 PM---What is going to happen if there are multiple backends? Each log message

From:	Igor Fedorenko <ifedorenko@xxxxxxxxxxxx>
To:	cross-project-issues-dev@xxxxxxxxxxx
Date:	03/17/2011 02:36 PM
Subject:	Re: [cross-project-issues-dev] slf4j logging configuration in eclipse

---

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)?

--
Regards,
Igor

On 11-03-17 03:12 PM, Thomas Watson wrote:
> We have been having a similar discussion in Equinox in the p2 bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=338232
>
> 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.
>
> Tom
>
>
>
> 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,
>
>
> From:		 
> Vlad Tatavu <vtatavu@xxxxxxxxxxxx>
>
> To:		 
> cross-project-issues-dev@xxxxxxxxxxx
>
> Date:		 
> 03/17/2011 11:52 AM
>
> Subject:		 
> [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].
>
> Background/problem:
> 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.
>
> Proposal:
> 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.
>
>
> [1] http://www.slf4j.org/
> [2] http://logback.qos.ch/
> [3] http://logback.qos.ch/manual/configuration.html
>
> Best regards,
> Vlad
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev