jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <woon...@apache.org>
Subject Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback orCommons-Logging
Date Sun, 12 Feb 2017 16:37:29 GMT
Great initiative, indeed! And, it was great, pleasant and also
learning experiences for myself as a fan of the project!
Thanks a lot again for your collaborations for new comers and the community!

Cheers,

Woonsan


On Sat, Feb 11, 2017 at 10:32 AM,  <foragerr@gmail.com> wrote:
> +1!
>
> As a downstream consumer of jmeter maven packages, this is absolutely great!
>
> RaGe
>
> From: Andrey Pokhilko
> Sent: Saturday, February 11, 2017 6:58 AM
> To: dev@jmeter.apache.org
> Subject: Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback orCommons-Logging
>
> 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