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? :)
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).
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.
Vlad
On 3/17/2011 3: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
 Vlad Tatavu ---03/17/2011 11:52:23 AM---Hi
all,
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
|
