jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or Commons-Logging
Date Sat, 11 Feb 2017 08:38:58 GMT
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.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message