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 ? > > 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. And popularity of these frameworks make them new standards compared to LogKit. 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. > > > - Performances of Log4j2 are now outstanding > > Is performance an issue? > It's a plus. 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. 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. > > > - 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. > 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. > > > 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 . It 's a certain piece of work and our time is precious, so I prefer to work on feature that will go in trunk. If experimentation is OK in branch , will you be ok to merge ? > > > > > 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.
