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, <forag...@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.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. >>> >>> >>> >> > >
