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