You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2015/12/30 16:35:19 UTC
Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or Commons-Logging
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 <mi...@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 <se...@gmail.com>:
>>
>> On 17 October 2015 at 17:41, Philippe Mouawad
>>> <ph...@gmail.com> wrote:
>>>
>>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>> On 17 October 2015 at 15:06, Philippe Mouawad
>>>>> <ph...@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.
Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback orCommons-Logging
Posted by Woonsan Ko <wo...@apache.org>.
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, <fo...@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 <mi...@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 <se...@gmail.com>:
>>>>>
>>>>> On 17 October 2015 at 17:41, Philippe Mouawad
>>>>>> <ph...@gmail.com> wrote:
>>>>>>
>>>>>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>> On 17 October 2015 at 15:06, Philippe Mouawad
>>>>>>>> <ph...@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.
>>>
>>>
>>>
>>
>
>
RE: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback
orCommons-Logging
Posted by fo...@gmail.com.
+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 <mi...@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 <se...@gmail.com>:
>>>>
>>>> On 17 October 2015 at 17:41, Philippe Mouawad
>>>>> <ph...@gmail.com> wrote:
>>>>>
>>>>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>> On 17 October 2015 at 15:06, Philippe Mouawad
>>>>>>> <ph...@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.
>>
>>
>>
>
Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or
Commons-Logging
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <mi...@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 <se...@gmail.com>:
>>>>
>>>> On 17 October 2015 at 17:41, Philippe Mouawad
>>>>> <ph...@gmail.com> wrote:
>>>>>
>>>>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>> On 17 October 2015 at 15:06, Philippe Mouawad
>>>>>>> <ph...@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.
>>
>>
>>
>
Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or Commons-Logging
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <mi...@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 <se...@gmail.com>:
>>>
>>> On 17 October 2015 at 17:41, Philippe Mouawad
>>>> <ph...@gmail.com> wrote:
>>>>
>>>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>> On 17 October 2015 at 15:06, Philippe Mouawad
>>>>>> <ph...@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.