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
|
