[
https://issues.apache.org/jira/browse/HBASE-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874448#action_12874448
]
stack commented on HBASE-2608:
------------------------------
I'm not averse to writing our own version of logging class (it help untether
our webapps from hadoops. From hadoop we get thread dumping, log level and log
viewing apps).
Your option 4. above looks attractive. Config. only changes w/o disruptive
change of all code. We can do the latter in the version after this one. What
would be involved? Could new classes start using slf4j api directly? Any
downsides?
Thanks Lars.
Hey, any chance of your taking up the thrift baton again? Whats to be done
over there?
> 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.
