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.
