[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] slf4j logging configuration in eclipse
|
Hi there,
Here is what we are doing for jetty:
1- the jetty code depends directly on slf4j's API.
3rd party dependencies may depend on slf4j, commons-logging, log4j
java's logging and more thanks to the bridges.
2- jetty does not provide any hook or special configuration for an
slf4j backend.
When we package the Eclipse RT Web StarterKit product we add logback
and set the system property "logback.configurationFile" to point to
the configuration file.
That is sufficient for logback to be configured; no start-level,
nothing else thanks to Gunnar's packaging of slf4j/logback.
Our experience shows that sticking to slf4j's design is sufficient:
- no need for custom code or plugins that wire a specific backend. choo
- if we must route the equinox logging services to slf4j, add an slf4j
bridge for those APIs and nothing more.
- clean-up the Require-Bundle: org.apache.commons.logging when we see
them and replace those by their corresponding ImportPackage.
If an application needs more than what slf4j-API provides, there is
probably a need to choose a logging backend and to work directly with
it.
For example a specific appender for logback to display logs in an
eclipse view as demonstrated by Ekke.
We are following this with interest and hope to avoid added complexity
when using slf4j.
Hugues
On Fri, Mar 18, 2011 at 6:14 AM, Vlad Tatavu <vtatavu@xxxxxxxxxxxx> wrote:
> I took a *very* brief look at ExtendedLogService and I'm pretty sure I don't
> understand all the details. :)
>
> I'm also pretty sure I don't understand all the reasons why it was needed.
> :)
>
> That being said, it looks to me a little bit like re-inventing a wheel...
> My gut feeling tells me I'm wrong on this one though. :)
>
> Here are some concerns I have:
> - Wrapping loggers is usually not a good idea. For an explanation, see [1].
> - The org.eclipse.equinox.log.Logger interface is far less convenient than
> org.slf4j.Logger.
>
> Right now, I don't see how the ExtendedLogService can solve or simplify the
> initial problem/requirements:
> 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
> - Provide default configuration for the chosen logging framework
>
> Having an implementation of ExtendedLogService act as slf4j implementation
> will just be a layer in between slf4j and the actual logging framework. It
> will have to wrap the backend loggers - which will bring the disadvantages
> of wrapping loggers. On the other hand, slf4j already has a mechanism to
> choose the backend logging and that works pretty well. As for providing a
> default configuration for the backend logging framework... that's usually
> just a config file. Am I missing something important here? :)
>
> Just to be clear: the initial problem I wanted to open for discussion was
> not about logging in eclipse in general or about eclipse's logging
> mechanisms or if these mechanisms are good, bad, obsolete, etc. It's also
> *not* about replacing any of the existing eclipse logging mechanism with
> slf4j. Although those are interesting problems and questions and worth
> discussions as well. :)
>
> The initial problem is very specific about slf4j being used from eclipse
> components and third party components. More precisely, having a common way
> to:
> - Choose a logging framework to be used by default - I propose logback
> - Provide default configuration for the chosen logging framework
> Implementation wise, IMO, that should be all done in an *optional* bundle
> because:
> - If an application/product does not use any component that requires slf4j,
> it should not have to provide an slf4j implementation or configuration
> - If an integrator decides to provide slf4j support that may be incompatible
> with the defaults provided by eclipse, they should be able to do so.
>
> [1] http://www.slf4j.org/faq.html#optional_dependency
>
> Vlad
>
>
> On 3/17/2011 4:58 PM, Thomas Watson wrote:
>
>> From:
>>
>> Vlad Tatavu <vtatavu@xxxxxxxxxxxx>
>>
>> I'm not familiar with the Equinox ExtendedLogService, so I don't
>> want to have any opinion about it before I take a look at it. :)
>> Where should I look? :)
>
> The core equinox framework now contains the Extended LogService
> implementation.
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=292135 for why this
> happened.
>
> As of Indigo M5 we now have the org.eclipse.equinox.log package exported by
> the core framework and the ExtendedLogReaderService and ExtendedLogService
> are registered by the core framework as OSGi services.
>
>>
>> That being said... If I understand correctly the second paragraph in
>> your message, the Equinox ExtendedLogService acts as an
>> implementation for slf4j. That doesn't make a lot of sense to me
>> because slf4j is already a facade for almost all the other major
>> logging frameworks out there. I don't see any advantage in pluging
>> in something in between slf4j and the final logging framework
>> (logback, log4j, etc). Having a layer in between can cause major
>> performance problems (please note that slf4j and logback were
>> developed for near zero performance impact).
>
> Simon Kaegi implemented the Equinox extended log service with this in mind.
> It is the reason LogFilters were introduced to the extended log service.
> This allows the implementation to quickly figure out if any backend
> listeners care about the log entry. Of coarse listeners can be evil and
> screw this up.
>
>>
>> As I said in the reply to Igor, I don't see the use case for having
>> multiple logging frameworks plugged in slf4j concurrently, but I'm
>> opened to hearing about such use cases.
>>
>> About log listeners... they can be both good and evil. :) Depending
>> on what they do and how they are implemented, of course. :) But
>> it's not easy at all to implement good log listeners. On the other
>> hand it's trivial to plugin log listeners in logback and log4j using
>> log appenders. Most probably other logging frameworks have similar
>> features. The big advantages in using appenders are:
>> - they can be plugged in and configured via logback/log4j config files.
>> - the logging framework is responsible for dealing with "bad"
>> appenders - and in my experience, both logback and log4j are good at that
>> :)
>>
>> I wasn't aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=338232
>> . The discussion points out something that really bothers me: the
>> proliferation of slf4j/logging solutions in eclipse. Especially
>> conflicting solutions. For example, somebody said that they "have a
>> framework hook which routes all Eclipse logging into SLF4J". Well,
>> m2eclipse has an appender that routes slf4j logging to eclipse log.
>> That will obviously cause circular logging if installed and
>> activated together.
>
> Same bothers me. That is why I jumped in on this topic because I think we
> need a common story so we don't start really messing things up across
> eclipse.
>
>
> Tom.
>
> _______________________________________________
> 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
>
>