struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pratt <thechrispr...@gmail.com>
Subject Re: Less boilerplate in code
Date Fri, 23 May 2014 16:22:50 GMT
I'm preparing to start working on the logging for Struts 3.0, so we need to
come to some consensus.  As I see it, the leading options are:

   1. Don't do anything
   2. Switch to SLF4j (or Log4j2)
   3. Use Onyx as is
   4. Use Onyx as an Object Aware Facade directly to SLF4j (or Log4j2)

My preference would actually be #4.  Onyx has some nice readability and
performance benefits over using SLF4j/Log4j2 directly that I think are
worth the minimal effort.  Please weigh in with your opinion before I get
too deep into this.
  (*Chris*)



On Fri, May 23, 2014 at 7:17 AM, Dave Newton <davelnewton@gmail.com> wrote:

> Just my $0.02:
>
> I'd prefer to see stuff that other people implement and have more eyes on
> take precedence over framework code.
>
> Similar to how XW has/had string utils duped by commons, etc, it just
> doesn't make sense to maintain that kind of boilerplate when it's already
> implemented, and implemented pretty well.
>
> Dave
>
>
>
> On Fri, May 23, 2014 at 9:37 AM, Christian Grobmeier <grobmeier@gmail.com
> >wrote:
>
> > On 23 May 2014, at 11:58, Lukasz Lenart wrote:
> >
> >  Yes, we can break everything in 3.x but ... do we want to start from
> >> scratch?
> >>
> >
> > It's not from scratch, is removing something from our codebase and use
> > something which already exists.
> >
> >  And what's wrong in tiny logging facade? I've said it already, I will
> >> say it again: not all ppl are using Log4j or SLF4j or jul - it's the
> >> worst thing if you must handle configuration of two or three different
> >> logging libraries because each framework is using a different one.
> >>
> >
> > First, we are a tiny active team. Why do we re-implement tiny facades
> > when they exist? I think with the less man-power we have we can surely
> > do better and more necessary things than reinventing the wheel.
> >
> > Surely, not all ppl use log4j or slf4j or jul. But most do. I can't help
> > but believe that there are only a handful people who still write their
> own
> > logging thing.
> >
> > Please see this non-representative survey from ZeroTurnaround:
> > http://zeroturnaround.com/rebellabs/the-state-of-logging-in-java-2013/
> >
> > Looks like everybody is using *something*, except 7% of participants
> > who is doing their own thing. It also says slf4j and log4j are the most
> > used
> > logging frameworks.
> >
> > Sure, logging has something to do with configuration. If you want
> > to get out of this, then use the simple logging implementation which
> > comes with slf4j. If you need more, configure something in addition.
> >
> > Maybe Java logging is a mess, but I believe it's not to Struts to solve
> > it. Instead I would offer something which the most people use (maybe
> > slf4j) or
> > something which we believe in (maybe log4j2).
> >
> >  Right now Struts2 doesn't force users to use given logging library, it
> >> can be configured to use whatever user is using in his project - thus
> >> is huge advantage and I don't want to loose it.
> >>
> >
> > You have the same with slf4j. Why is having our own custom thing better
> > than something which is widely accepted and adopted?
> >
> > With slf4j you can:
> >
> >  - do not configure anything, go with slf4j
> >  - do configure something, go with the framework you like
> >
> > The same is true for the new log4j2 facade.
> >
> > Thanks for the discussion!
> >
> >
> >
> >
> >>
> >> 2014-05-22 18:28 GMT+02:00 Christian Grobmeier <grobmeier@gmail.com>:
> >>
> >>> Hi all,
> >>>
> >>> with Struts 3.x we are allowed to "break things" and it is expected
> that
> >>> we
> >>> do major steps.
> >>>
> >>> Personally I would like to remove any custom made logging layer
> >>> and move on to a more standard one. Performance is not an issue, when
> >>> logging
> >>> is done right:
> >>> http://www.grobmeier.de/log4j-2-performance-close-to-insane-
> >>> 20072013.html
> >>>
> >>> I consider commons-logging almost dead. It will not be developed much
> >>> further, at least
> >>> not when looking at recent activity of the past years.
> >>>
> >>> I think slf4j is stable and well maintained. You can even use log4j2
> with
> >>> it.
> >>>
> >>> Saying log4j2 I am pretty much biased and need to tell you that log4j2
> >>> also
> >>> provides a logging interface similar to slf4j with which you can switch
> >>> implementations.
> >>>
> >>> In no case I would go to anything exotic or jul. The latter one often
> >>> needs
> >>> wrappers
> >>> to work as wanted.
> >>>
> >>> That being said, I only see slf4j and log4j. If we want to stick in the
> >>> ASF
> >>> world
> >>> we can use the log4j2 interfaces and explain how to integrate in
> example
> >>> logback.
> >>> That would be my preferred choice. Also I think log4j2 provides more
> >>> features and
> >>> is pretty much better maintained (my personal opinion)
> >>>
> >>> If we want to use something which is longer on the market, then slf4j.
> >>>
> >>> cheers
> >>>
> >>>
> >>> On 22 May 2014, at 9:19, Chris Pratt wrote:
> >>>
> >>>  You are correct, it delegates the actual logging to a logging engine,
> >>>> currently either Log4j, Logback, java.util.logging or to SLF4j.
> >>>> (*Chris*)
> >>>>
> >>>>
> >>>> On Wed, May 21, 2014 at 10:10 PM, Lukasz Lenart
> >>>> <lukaszlenart@apache.org>wrote:
> >>>>
> >>>>  @Chris
> >>>>> Do I get it right - Onyx is just logging facade not the full-blow
> >>>>> logging library?
> >>>>>
> >>>>> 2014-05-17 8:52 GMT+02:00 Lukasz Lenart <lukaszlenart@apache.org>:
> >>>>>
> >>>>>>
> >>>>>> Some were already addressed, another thing is that across the
> >>>>>> framework we are using different semantic inside logging messages,
> ie:
> >>>>>> "Value [#0] was excluded by pattern [#1]" and re-writing all
these
> >>>>>> doesn't make sense. Right now XWork logging facade is very thin
-
> one
> >>>>>> class implementing Logger interface and another implementing
> >>>>>> LoggerFactory - the rest is delegated to given logging library.
> >>>>>>
> >>>>>> Besides that, users don't care what kind of logging library
> framework
> >>>>>> is using - till it doesn't interfere with the one used in their
apps
> >>>>>> or clashes with logging layers from other frameworks. Switching
> >>>>>> entirely to SLF4j can break few apps and we'll get a lot of
> complains
> >>>>>> why (not the first time ;-)
> >>>>>>
> >>>>>> My plan looks like this:
> >>>>>> - add checking if given log level is enabled inside logging
methods
> >>>>>> - start migrating code to the new semantic (removing if
> >>>>>>
> >>>>>
> >>>>> (LOG.isXxxEnabled())
> >>>>>
> >>>>>>
> >>>>>> - migrate the rest of logging calls to use parameter substitution
> >>>>>> - (or start with this before previous step) use Onyx instead
of
> >>>>>> current LoggerUtils
> >>>>>> - change order of discovering logging libs on the classpath
and put
> >>>>>>
> >>>>>
> >>>>> SLF4j on top
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Regards
> >>>>>> --
> >>>>>> Łukasz
> >>>>>> + 48 606 323 122 http://www.lenart.org.pl/
> >>>>>>
> >>>>>> 2014-05-15 23:14 GMT+02:00 Chris Pratt <thechrispratt@gmail.com>:
> >>>>>>
> >>>>>>>
> >>>>>>> What is your reluctance to using SLF4j.  It seems like the
right
> >>>>>>>
> >>>>>>
> >>>>> technology
> >>>>>
> >>>>>>
> >>>>>>> for the problem.
> >>>>>>> (*Chris*)
> >>>>>>>
> >>>>>>> P.S.  ICLA on the way
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, May 14, 2014 at 11:16 PM, Lukasz Lenart <
> >>>>>>>
> >>>>>>
> >>>>> lukaszlenart@apache.org>wrote:
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>  2014-05-14 21:51 GMT+02:00 Chris Pratt <thechrispratt@gmail.com>:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Yes, we could use Onyx's interface mechanism, but
I think SLF4j's
> >>>>>>>>> is
> >>>>>>>>> probably more stable and definitely more supported.
 So I'd
> >>>>>>>>> probably
> >>>>>>>>> recommend that we extract the SLF4j support object
and use it
> >>>>>>>>>
> >>>>>>>>
> >>>>> directly
> >>>>>
> >>>>>>
> >>>>>>>> (or
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> at least make it the default).  If it's something
that you're
> >>>>>>>>>
> >>>>>>>>
> >>>>> interested
> >>>>>
> >>>>>>
> >>>>>>>>> in, I'd have to fill out the forms to become a committer
on
> Struts.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Where
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> would I find that information?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I'm not sure if this the right move, switching to SLF4j
over our
> >>>>>>>> custom solution. Please can we explore this topic a
bit?
> >>>>>>>>
> >>>>>>>> The first step to become a committer is to fill ICLA
> >>>>>>>> http://www.apache.org/licenses/#clas
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> --
> >>>>>>>> Łukasz
> >>>>>>>> + 48 606 323 122 http://www.lenart.org.pl/
> >>>>>>>>
> >>>>>>>> ------------------------------------------------------------
> >>>>>>>> ---------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>> ---
> >>> http://www.grobmeier.de
> >>> The Zen Programmer: http://bit.ly/12lC6DL
> >>> @grobmeier
> >>> GPG: 0xA5CC90DB
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> >
> > ---
> > http://www.grobmeier.de
> > The Zen Programmer: http://bit.ly/12lC6DL
> > @grobmeier
> > GPG: 0xA5CC90DB
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> e: davelnewton@gmail.com
> m: 908-380-8699
> s: davelnewton_skype
> t: @dave_newton <https://twitter.com/dave_newton>
> b: Bucky Bits <http://buckybits.blogspot.com/>
> g: davelnewton <https://github.com/davelnewton>
> so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
>

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