Yes, we can break everything in 3.x but ... do we want to start from scratch?
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. 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. 2014-05-22 18:28 GMT+02:00 Christian Grobmeier <grobme...@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 >> <lukaszlen...@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 <lukaszlen...@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 <thechrispr...@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 < >>> >>> lukaszlen...@apache.org>wrote: >>>>> >>>>> >>>>>> 2014-05-14 21:51 GMT+02:00 Chris Pratt <thechrispr...@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-unsubscr...@struts.apache.org >>>>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>>>> >>>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> > > > --- > http://www.grobmeier.de > The Zen Programmer: http://bit.ly/12lC6DL > @grobmeier > GPG: 0xA5CC90DB > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
