Aha, good catch^2! On Tue, Dec 29, 2015 at 9:05 PM, Dave Lester <d...@davelester.org> wrote:
> 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 <jfarr...@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 < > jeffschroe...@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 <wfar...@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 < > >>> jeffschroe...@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 <wfar...@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 > >> > >
