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

> 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.


Back to the top