[
https://issues.apache.org/jira/browse/HBASE-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872197#action_12872197
]
Lars Francke commented on HBASE-2608:
-------------------------------------
I have an E-Mail draft about this sitting in GMail since February (since we
switched to Maven). I'll just paste it here. Sorry it's rather long and some
things are outdated (contrib stuff) but I hope it helps.
Hi,
the tl;dr version: I propose switching from Commons Logging and Log4j to SLF4J
and Logback with me being the one doing the work and not much/nothing changing
for the developers
We currently use Commons Logging and Log4j. Those two have largely been
superseded by SLF4J[1] and Logback[2] respectively. Those two are written by
the author of Log4j and it is his opinion that Log4j+CL shouldn't be used
anymore.
I wanted to know how you feel about switching?
We've pulled in SLF4j via dependencies (Thrift and Hadoop [indirect via Avro])
anyway and it is very easy to replace Commons Logging transparently with
SLF4J[3] and immediately gain the benefits without having to do any work. A
second optional step would be to replace Log4j with Logback. This too would be
transparent from a code perspective but once again we'd gain the benefits[4]
for the price of writing new properties files (there is a tool available to
migrate[6] log4 files)
There is also a tool to help with the migration[5] if we chose to code against
the SLF4J and not the CL APIs. I would volunteer to make any changes necessary.
Why (now)? A couple of reasons with the first being that we've pulled in SLF4J
anyway and it is superior to CL in every way so this could be done
effortlessly. Another reason is that we're in the process of refactoring the
build structure from HBase at the moment (Mavenization) and this'll mean that a
few Log4j property files will probably have to be adjusted and/or added
(because every contrib seems to need his own now) so this'd be a good time to
switch to clean up and switch. Another reason might be that more and more
projects switch to this combination (or at least to SLF4J). The last reason I
can think of is that we have a volunteer (me) for making this switch happen who
has used those two in combination for years after being bitten by the
classloader issues from Commons Logging once too often.
Reasons against? Well it'll be another "cross cutting" change touching a lot of
code (if we switch APIs) just like the switch to Maven. We also have no real
problems with the current setup and a lot of developers and users probably
aren't to familiar with those two projects while everyone know CL+Log4j.
Your choice. I'm just offering to do the work :)
The options as I see them:
1) Leave everything as it is
2) Switch from CL to SLF4J (only configuration changes)
3) Switch from CL to SLF4J and alter the existing code to use the SLF4J API[7]
instead of the CL API
4) Switch from CL+Log4j to SLF4J+Logback (only configuration changes)
5) Switch from CL+Log4j to SLF4J+Logback and alter the existing code to use the
SLF4J API[7] instead of the CL API
Cheers,
Lars
[1] http://www.slf4j.org/
[2] http://logback.qos.ch/
[3] http://www.slf4j.org/legacy.html
[4] http://logback.qos.ch/reasonsToSwitch.html
[5] http://www.slf4j.org/migrator.html
[6] http://logback.qos.ch/translator/
[7] http://www.slf4j.org/apidocs/org/slf4j/Logger.html
> Switch to SLF4J
> ---------------
>
> Key: HBASE-2608
> URL: https://issues.apache.org/jira/browse/HBASE-2608
> Project: HBase
> Issue Type: Improvement
> Reporter: Benoit Sigoure
>
> There are 2 compelling reasons to switch from log4j to slf4j:
> * HBase provides a client library that is going to be embedded in another
> application. Using SLF4J lets the application chose whatever logging library
> it wants instead of imposing log4j.
> * When using SLF4J, we should use logback by default as it is basically a
> better, faster, stronger log4j. Same author, new design / new code. See
> http://logback.qos.ch/reasonsToSwitch.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
