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 <[email protected]> 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 <[email protected]>: >> >> On 17 October 2015 at 17:41, Philippe Mouawad >>> <[email protected]> wrote: >>> >>>> On Sat, Oct 17, 2015 at 5:44 PM, sebb <[email protected]> wrote: >>>> >>>> On 17 October 2015 at 15:06, Philippe Mouawad >>>>> <[email protected]> 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.
