aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@apache.org>
Subject Re: [PROPOSAL] Use standard logging practices
Date Tue, 05 Jan 2016 21:15:06 GMT
I don't have any opinion between log4j and logback but I think these two
features of logback might be useful to people debugging issues in their
cluster:

   - http://logback.qos.ch/reasonsToSwitch.html#packagingData
   - http://logback.qos.ch/reasonsToSwitch.html#logbackAccess

The first ensures users can check if their packages/classpath were setup
correctly and the second is an easy way to check the logs without having to
determine and ssh into the leading master.

On Tue, Dec 29, 2015 at 10:31 PM, Bill Farner <wfarner@apache.org> wrote:

> FYI i have updated my patch to switch us to log4j as a straw man (mostly
> because i embarked before Dave's clarification)
> https://reviews.apache.org/r/41785/
>
> I'm interested in general feedback on the patch, but encourage continued
> discussion on deciding between log4j and logback.
>
>
> On Tue, Dec 29, 2015 at 9:55 PM, Bill Farner <wfarner@apache.org> wrote:
>
> > Aha, good catch^2!
> >
> > On Tue, Dec 29, 2015 at 9:05 PM, Dave Lester <dave@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 <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
> >> >>
> >>
> >>
> >
>



-- 
Zameer Manji

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