jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gomes Rodrigues <ra0...@gmail.com>
Subject Re: Dropping LogKit in favor of Apache Log4J2 or SLF4J+ Logback or Commons-Logging
Date Sun, 18 Oct 2015 17:45:21 GMT
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 <sebbaz@gmail.com>:

> On 17 October 2015 at 17:41, Philippe Mouawad
> <philippe.mouawad@gmail.com> wrote:
> > 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 ?
>
> 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.
>

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