Return-Path: X-Original-To: apmail-struts-dev-archive@www.apache.org Delivered-To: apmail-struts-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BB6F911BAF for ; Fri, 23 May 2014 13:38:17 +0000 (UTC) Received: (qmail 87138 invoked by uid 500); 23 May 2014 13:38:17 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 87093 invoked by uid 500); 23 May 2014 13:38:17 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 87085 invoked by uid 99); 23 May 2014 13:38:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 May 2014 13:38:17 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of grobmeier@gmail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-ee0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 May 2014 13:38:13 +0000 Received: by mail-ee0-f52.google.com with SMTP id e53so3745565eek.39 for ; Fri, 23 May 2014 06:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=+dp5oNHGMhFMWUebDFYvVh634vtLfi7IEc4Sg7eC0nk=; b=bh+SZ1Na2kMyVDLfWHOJAnUWeUPuFA7bH0JmGuqhySyW9LXSQfVZWD5/0QnJHcx9I3 mJmGF5riz2WGO4LnwCZcvcFB7H2+Ci5K3NCjJfB5MJl9WP3hUOhh9DVuwo4i7Ox0L5GK NV4yZcnksUltqtVAU33MZIIHc2QByvNm1MoH6FC70KCWUPz7KULp548sKMtMoS4r8IRj x/EAcAMIHffsxqE1rpjilL29KAnPBVBonP4sRjmqE4GAtmEqPQCH5Hc5La8rkT+QS/FH +tA9tCgMK33thiID0Q2ydIALt2AumTv6RwLR8RgemauObeHlfzoMHRGS2IbLSyuWdxV4 lGOA== X-Received: by 10.14.53.66 with SMTP id f42mr4058923eec.70.1400852271967; Fri, 23 May 2014 06:37:51 -0700 (PDT) Received: from [192.168.178.39] (p579D52C6.dip0.t-ipconnect.de. [87.157.82.198]) by mx.google.com with ESMTPSA id v47sm8444273eel.22.2014.05.23.06.37.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 May 2014 06:37:50 -0700 (PDT) From: "Christian Grobmeier" To: "Struts Developers List" Subject: Re: Less boilerplate in code Date: Fri, 23 May 2014 15:37:39 +0200 Message-ID: <6EE2F746-0DB2-4FBF-860E-2A29B29AA62B@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.8r4214) X-Virus-Checked: Checked by ClamAV on apache.org 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 : >> 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 >>> 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 : >>>>> >>>>> 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 : >>>>>> >>>>>> 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 >>>>>>> : >>>>>>>> >>>>>>>> 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