Hi' folks... Okay here is my pitch for why we should move to slf4j.

1) hadoop is moving to use slf4j bindings asap, 

2) hive actually is moving also to use slf4j: it's a known "bug" that hive has 
commons-logging bits floating around.

Why so much fuss about logging? Because slf4j is easy to debug and manage, 
whereas commons logging is very tricky to debug (it is biased to log4j, has 
magic ways of setting up logging that can be tricky to unify on a large 
cluster, etc.

> On May 11, 2014, at 11:44 PM, Mark Grover <[email protected]> wrote:
> 
> There are also other components in the stack that use it. See Hive for
> example:
> https://github.com/apache/hive/blob/trunk/pom.xml#L299
> 
> Unless I am missing a good reason to remove it, I am personally happy with
> the status-quo w.r.t. commons-logging.
> 
> 
>> On Sat, May 10, 2014 at 9:32 PM, Konstantin Boudnik <[email protected]> wrote:
>> 
>> What we are going to replace it with?
>> 
>>> On Fri, May 09, 2014 at 08:27PM, Jay Vyas wrote:
>>> Hi bigtop !
>>> 
>>> Shall we work to start getting rid of commons logging, as hadoop is doing
>>> ?  I see its a dependency of itest.
>>> 
>>> +--- org.apache.bigtop.itest:itest-common:0.7.0
>>> |    +--- org.codehaus.groovy:groovy-all:1.8.6
>>> |    +--- junit:junit:4.11
>>> |    |    \--- org.hamcrest:hamcrest-core:1.3
>>> |    +--- commons-logging:commons-logging:1.1 -> 1.1.1
>>> |    +--- org.apache.ant:ant:1.8.2
>>> |    |    \--- org.apache.ant:ant-launcher:1.8.2
>>> |    \--- org.apache.ant:ant-junit:1.8.2
>>> |         +--- org.apache.ant:ant:1.8.2 (*)
>>> |         \--- junit:junit:3.8.2 -> 4.11 (*)
>>> 
>>> I personally dont like the way that it figures out how to log (there is
>>> complex hierarchy of logic to it).
>>> 
>>> --
>>> Jay Vyas
>>> http://jayunit100.blogspot.com
>> 

Reply via email to