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.
