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

Reply via email to