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 <davelnew...@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 <grobme...@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 <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 > >> > > > > > > --- > > 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 > > > > > > > -- > e: davelnew...@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> >
