jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or Commons-Logging
Date Wed, 21 Oct 2015 06:52:22 GMT
Hello,

I'm agree with you. I thinks we must have a more modern vision for the 
code to attract more developers.
If the change from LogKit to Log4j2 is transparent then we must do the 
change.

I don't known if a technical vote is required, if yes, my vote will be +1.

Milamber

On 18/10/2015 18:45, Antonio Gomes Rodrigues wrote:
> Hi all,
>
> My 2 cents,
>
> Each time I talk to a JMeter user which have read the source code I have
> this answer : "The code is old ..."
>
> And I think to keep old framework like LogKit in JMeter doesn't help to
> attract new committers.
>
> Maybe LogKit make the job but it don't help the project
>
> Regards,
> Antonio
>
>
> 2015-10-17 22:36 GMT+02:00 sebb <sebbaz@gmail.com>:
>
>> On 17 October 2015 at 17:41, Philippe Mouawad
>> <philippe.mouawad@gmail.com> wrote:
>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <sebbaz@gmail.com> wrote:
>>>
>>>> On 17 October 2015 at 15:06, Philippe Mouawad
>>>> <philippe.mouawad@gmail.com> wrote:
>>>>> Hello,
>>>>> LogKit is in the Attic for a while now.
>>>>>
>>> AFAIK, we upgrade JDK version of JMeter based on EOL of Java version, why
>>> would strategy be different for dead libraries ?
>> Attic is not the same as Dead.
>>
>>>>> What about dropping it in favor of a more up to date Logging library:
>>>>> - Apache Log4J2 which has great performances now
>>>>> - SLF4+LogBack which is also nice
>>>>> - Commons-logging
>>>>>
>>>>> I see many benefits:
>>>>> - Drop an outdated library (I think it's never a good thing to rely on
>>>>> unmaintained libraries, it can be a security issue, it can make
>> newbies
>>>>> think that JMeter is not maintained nor up to date)
>>>> Newer is not necessarily better.
>>>>
>>> In this case, newer is better,  lot of technical reasons make the 3
>>> mentioned libraries better than logkit.
>> Such as?
>>
>>> And popularity of these frameworks make them new standards compared to
>>> LogKit.
>> For now, until the next new library comes along...
>>
>>> It's also IT World way, if a library disappears then even if it's great,
>> it
>>> is better not to rely on it anymore.
>> It's not going to disappear.
>>
>>>>> - Performances of Log4j2 are now outstanding
>>>> Is performance an issue?
>>>>
>>> It's a plus.
>> But is there a problem currently?
>>
>> It's obviously important that the performance is not significantly
>> worse, but otherwise it's not really relevant.
>>
>>> In my opinion, in this particular case, LogBack and Log4j2 are richer
>> than
>>> LogKit in the functionalities they provide  and they performa (Log4j2)
>> much
>>> better thanks to new concepts like LMAXDisruptor.
>> But do we need the extra functions?
>>
>>> There could be some case where you need to debug under load, having an
>>> efficient logging framework that does not impact load engine can be very
>>> useful.
>> That is the first possibly valid reason I have seen, but without
>> knowing the performance improvement it's difficult to be sure that it
>> would be useful to swap.
>>
>>>>> - There a nice useful API that we could use to concat and variabilize
>>>>> logging messages provided :
>>>>> * https://logging.apache.org/log4j/2.0/manual/messages.html
>>>>> * https://logging.apache.org/log4j/2.0/manual/thread-context.html
>>>> How is that going to help?
>>>>
>>> Well building messages with parameters make code much clearer and we
>> don't
>>> use String concat anymore.
>> Examples?
>>
>>>> Are there many situations where this is essential?
>>>>
>>> Not essential. But useful.
>>> Also newbies don't know LogKit while they usually know log4j or
>>> logback/slf4j or Commons-logging.
>> Why should that be an issue?
>> So long as they know how to enable/disable logging, that should be
>> sufficient.
>>
>>>>> Switching is not a big deal although it impacts a lot of classes on
>> the
>>>>> line:
>>>>> -     private static final Logger log =
>>>> LoggingManager.getLoggerForClass();
>>>>
>>>> I think you will find that there are other impacts on the JMeter code.
>>>> I suggest you experiment first in a branch.
>>>>
>>> I am ready to experiment but knowing the impact (nearly 80% of classes
>>> would be touched)  I would restrain test to Logging Manager .
>> You could convert just one area.
>> This would mean creating a new version of Logging Manager so the two
>> could co-exist for testing of the partial changes.
>>
>> That may well be necessary anyway to provide backward compatibility
>> for 3rd party plugins.
>>
>>> It 's a certain piece of work and our time is precious
>> Exactly, that's why I don't see the need to do it at all.
>>
>>> , so I prefer to work on feature that will go in trunk.
>>>
>>> If experimentation is OK in branch , will you be ok to merge ?
>> Let's see what the experiment shows.
>> Note that user documentation will also need to be updated.
>>
>>>>> We could make the changes to LoggingManager so that it is able to
>> reuse
>>>>> current logging setup configuration and allow configuration from a
>> usual
>>>>> configuration file as per the chosen library.
>>>> That would be essential
>>>>
>>>>> Thoughts ?
>>>>> Regards
>>>>> Philippe M.
>>>>> @philmdot
>>>
>>>
>>> --
>>> Cordialement.
>>> Philippe Mouawad.


Mime
View raw message