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 Wed, 30 Dec 2015 15:35:19 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message