jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or Commons-Logging
Date Sat, 17 Oct 2015 16:41:23 GMT
On Sat, Oct 17, 2015 at 5:44 PM, sebb <sebbaz@gmail.com> wrote:

> On 17 October 2015 at 15:06, Philippe Mouawad
> <philippe.mouawad@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 ?


> > 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message