+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.moua...@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 <milam...@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 <seb...@gmail.com>: >>>> >>>> On 17 October 2015 at 17:41, Philippe Mouawad >>>>> <philippe.moua...@gmail.com> wrote: >>>>> >>>>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <seb...@gmail.com> wrote: >>>>>> >>>>>> On 17 October 2015 at 15:06, Philippe Mouawad >>>>>>> <philippe.moua...@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. >> >> >> >
