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 22:43:48 GMT
>
> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
> {0.enrollmentDate,date,yyyy-MM-dd}",student);

This makes logging complicated.


I actually find it a lot less complicated than the equivalent:

if(log.isDebugEnabled()) {
  log.debug("Loading Student [{}] {} Enrolled:
{}",student.getNumber(),student.getName(),new
SimpleDateFormat("yyyy-MM-dd").format(student.getEnrollmentDate()));
}

Also, what happens if there is no such property as number in the student
> object?


The formatter is extremely tolerant and prints out nothing for that
replacement parameter if it fails in any way.

Whats a "log concentrator"?


One of the awesome capabilities of SLF4j is concentrating logging from 3rd
party libraries.  If you decide you want to use Log4j2 as your logging
engine, but your 3rd party libraries use a combination of Common's Logging,
Log4j 1.2.x, and/or java.util.logging you can use SLF4j modules to funnel
messages from those 3rd party libraries to your Log4j2 setup.  That way you
can control all your logging with your Log4j2 configuration.
  (*Chris*)


On Fri, May 23, 2014 at 1:38 PM, Christian Grobmeier <grobmeier@gmail.com>wrote:

> On 23 May 2014, at 22:04, Chris Pratt wrote:
>
>  Sorry, I should have included the link - https://code.google.com/p/
>> anodyzed/
>>
>> It isn't a replacement for async loggers, it works on the other end of the
>> problem, building the log message when it isn't necessary.
>>
>
> you can disable logging in other frameworks too?
> Or do you mean, it just logs on exception?
>
> I see variable substitution in the modern frameworks as well.
>
> I am not sure if like that:
> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
> {0.enrollmentDate,date,yyyy-MM-dd}",student);
>
> This makes logging complicated. Also, what happens if there is no such
> property as number in the student object?
>
>
>  I would actually recommend SLF4j for two reasons.  One, it is the front
>> runner, almost a de-facto standard at this point.
>>
>
> But it's driven by another company and not in the same "safe waters" as
> the ASF.
> Maybe I am paranoid here, but I simply prefer community driven projects
> were the
> community i.e. the surrounding foundation has full rights on repositories.
> This is not against QOS itself, its a general fright.
> However I totally see that the facade is ways better than commons-logging
> and
> that the log4j2 api isn't as widely adopted.
>
>
>  And two, it supports Log4j2.
>>
>
> Sure: http://logging.apache.org/log4j/2.x/log4j-slf4j-impl/index.html
>
> But the Log4j2 API also supports the Slf4j API:
> http://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html
>
>
>  So there's no down side to picking SLF4j.  If you want to use
>> Log4j2, great, it's an awesome engine, but SLF4j is an awesome API and log
>> concentrator.  That's what it's good at, and how we should use it (IMHO).
>>
>
> Please note Log4j2 is not only an engine, its also an API. It's two
> separate packages.
> The API does support slf4j and other things too. However, my argument
> against it would
> be the missing Logback support. Not that I like Logback very much, but it
> has some fans.
>
> Whats a "log concentrator"?
>
> Thanks,
> Christian
>
>
>> Thanks.
>> (*Chris*)
>>
>>
>> On Fri, May 23, 2014 at 12:19 PM, Christian Grobmeier
>> <grobmeier@gmail.com>wrote:
>>
>>  On 23 May 2014, at 18:22, Chris Pratt wrote:
>>>
>>> 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)
>>>>
>>>>
>>> I am sure you have posted links before, but could you repost links to the
>>> Onxy project.
>>> I am unable to find the right page with google.
>>>
>>>
>>> My preference would actually be #4.  Onyx has some nice readability and
>>>
>>>> performance benefits over using SLF4j/Log4j2 directly
>>>>
>>>>
>>> I can't believe it has performance benefits compared to async loggers of
>>> log4j2:
>>> http://www.grobmeier.de/log4j-2-performance-close-to-insane-
>>> 20072013.html
>>>
>>>
>>> that I think are
>>>
>>>> worth the minimal effort.  Please weigh in with your opinion before I
>>>> get
>>>> too deep into this.
>>>>
>>>>
>>> Personally I would prefer Log4j2. I am biased as I am involved in that
>>> project.
>>> However this is not marketing, I really believe this is so far the best
>>> logging framework you can have atm (I haven't checked Onyx).
>>>
>>> Also I like the ASF and believe we are developing here for a reason. For
>>> the same
>>> reason I always prefer other ASF projects.
>>>
>>> If we do not want Log4j2 for some reason (it's currently RC1 - I say its
>>> stable
>>> and until we get S3 out it will be GA, but others may think different)
>>> then
>>> I definitely prefer slf4j. It has quite a market share and is commonly
>>> accepted
>>> by people.
>>>
>>> We need to have good reasons to not use what anybody else use.
>>>
>>> As I find slf4j/log4j2 syntax nice to read too and I doubt about
>>> performance
>>> benefits I would love to hear more arguments pro-Onyx.
>>>
>>> In short, my current preference is #2 with Log4j2, but if necessary even
>>> with slf4j.
>>>
>>> And I am willing to invest some time here too, esp if I could budget this
>>> on my log4j2 budget :-)
>>>
>>> Cheers
>>> Christian
>>>
>>>
>>>
>>>
>>>
>>>
>>> (*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>
>>>>>
>>>>>
>>>>>
>>> ---
>>> 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
>>>
>>>
>>>
>
> ---
> 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
>
>

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