jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <a...@ya.ru>
Subject Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or Commons-Logging
Date Sat, 11 Feb 2017 11:58:20 GMT
Great initiative! Good to hear that project is migrating towards modern
libraries.

Andrey Pokhilko

On 11.02.2017 11:38, Philippe Mouawad wrote:
> Hello,
> I'm happy to announce that thanks to the huge work of Woonsan Ko, we've now
> completed the migration to SLF4J/LOG4J2.
>
> Big thanks to Woonsan ! for the quality of his work and the amount of
> involvement on this.
>
> Regards
> Philippe
>
> On Wed, Dec 30, 2015 at 4:35 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>> Hello,
>> I will start work on this, I propose to go for SLF4J + Log4j2 as default
>> binding.
>>
>> Slf4j is already in JMeter and log4j2 is Apache project and the most
>> efficient one currently.
>>
>> Unless I get a NOGO within the 24 hours,  I will start coding it.
>> Regards
>> Philippe
>>
>> On Wed, Oct 21, 2015 at 8:52 AM, Milamber <milamber@apache.org> wrote:
>>
>>> 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.
>>>>>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>


Mime
View raw message