On Tue, Dec 29, 2015 at 5:05 PM, John Sirois <j...@conductant.com> wrote:
> > > On Tue, Dec 29, 2015 at 5: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. >> > > Looks like this decision is nicely limited to a build.gradle edit: > http://logback.qos.ch/reasonsToSwitch.html#slf4j > After a brief skim of the configuration docs [1], I'm in favor of switching in a follow-up RB to https://reviews.apache.org/r/41777/ In short - logback supports pointing to a non-root config file via a system-property out of the box, this makes aurora a non-nuisance for operators, they can easily modify init scripts to point to a custom config. [1] http://logback.qos.ch/manual/configuration.html > >> 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 >> > > > > -- > John Sirois > 303-512-3301 > -- John Sirois 303-512-3301
