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 >