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. > > > -- Cordialement. Philippe Mouawad.
