aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Lester <d...@davelester.org>
Subject Re: [PROPOSAL] Use standard logging practices
Date Wed, 30 Dec 2015 05:05:55 GMT
Looks like logback is actually dual-licensed under EPL v1.0 and LGPL. http://logback.qos.ch/license.html
<http://logback.qos.ch/license.html>

So technically, the logbook EPL code could be included in object/binary form http://www.apache.org/legal/resolved.html#category-b
<http://www.apache.org/legal/resolved.html#category-b>

> On Dec 29, 2015, at 10:34 PM, Jake Farrell <jfarrell@apache.org> wrote:
> 
> Logback can not be used as it is LGPL licensed
> 
> -Jake
> 
> On Tue, Dec 29, 2015 at 7:02 PM, Jeff Schroeder <jeffschroeder@computer.org>
> wrote:
> 
>> Primarily it is faster, uses less memory, and annotates tracebacks with
>> package versions. The last one seems like a winner for debugging user
>> issues or operationally.
>> 
>> http://logback.qos.ch/reasonsToSwitch.html
>> 
>> I'm not strongly opinionated either way, but it does seem like a better
>> log4j.
>> 
>> On Tuesday, December 29, 2015, Bill Farner <wfarner@apache.org> wrote:
>> 
>>> I don't have a strong opinion about logback vs log4j.  Can you summarize
>>> some of the tradeoffs?
>>> 
>>> On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
>>> jeffschroeder@computer.org <javascript:;>>
>>> wrote:
>>> 
>>>> What about using logback instead of log4j? It has some interesting
>>> benefits
>>>> over log4j and we wouldn't be the first large mesos framework to switch
>>> to
>>>> it.
>>>> 
>>>> Personally, I'd love to see glog burn and die in a fire.
>>>> 
>>>> On Monday, December 28, 2015, Bill Farner <wfarner@apache.org
>>> <javascript:;>> wrote:
>>>> 
>>>>> We're currently using some logging scaffolding carried over from
>>> Twitter
>>>>> commons.  I would like to propose that we dismantle some of this in
>>> favor
>>>>> of more standard java application logging conventions.
>>>>> 
>>>>> Concretely, i propose we remove the following scheduler command line
>>>>> arguments:
>>>>> -logtostderr
>>>>> -alsologtostderr
>>>>> -vlog
>>>>> -vmodule
>>>>> -use_glog_formatter
>>>>> 
>>>>> Instead of these, we can allow users to customize logging via
>> standard
>>>>> java.util.logging inputs (e.g. logging.properties).  We could explore
>>>> using
>>>>> an alternative to java.util.logging, but i suggest we retain that
>>> backend
>>>>> for now (since it's what we're currently using).
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Text by Jeff, typos by iPhone
>>>> 
>>> 
>> 
>> 
>> --
>> Text by Jeff, typos by iPhone
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message