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

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


Back to the top