aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: [PROPOSAL] Use standard logging practices
Date Wed, 30 Dec 2015 04:47:17 GMT
Aha, good catch.  Sounds like log4j takes the cake.

On Tue, Dec 29, 2015 at 7: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