struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Grobmeier" <grobme...@gmail.com>
Subject Re: Less boilerplate in code
Date Fri, 23 May 2014 19:19:38 GMT
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


Mime
View raw message