On Tue, Jan 3, 2017 at 2:32 PM, Felix Schumacher <felix.schumac...@internetallee.de> wrote: > Am 02.01.2017 um 21:31 schrieb Philippe Mouawad: >> >> On Monday, January 2, 2017, Woonsan Ko <woon...@apache.org> wrote: >> >>> Hi, >>> >>> I'd like to help with migrating from Apache LogKit to SLF4J [1], and >>> so I've been reading the current logging implementation with logkit, >>> avalon-framework and excalibur-logger. >> >> Thanks for your proposal > > +1 >> >> >>> From my understanding, maybe we can take the following approach: >>> - Since SLF4J API doesn't provide a logging implementation or binding >>> by itself, we need to choose one at least such as log4j2 [2] or >>> logback. [3] IMHO, log4j2 binding provided by Apache Logging services >>> project could be a good default binding option. >> >> >> +1 > > Well, I would start with what we have, which is a working binding for SLF4J.
It seems more important to migrate each logger usages to use slf4j logger in each class than replacing logging framework in the first step. So, we can keep the current logkit binding in the first step. That prioritization makes sense to me. >> >> >>> - By the default binding such as log4j2, I mean JMeter should be >>> bundled with log4j2 library and its binding library as well as a >>> default configuration file (e.g, log4j2.xml), by default. It seems >>> neater to separate the logging configuration file from >>> jmeter.properties with simply following its default auto-resolving >>> conventions such as log4j2.xml [4] or logback.xml [5] to me. >> >> +1 > > I am +-0 to any decision right now. This can be revisited with separate ticket after the first step done. >> >> >>> - It seems like each Logger instance is created as a static member by >>> `LoggingManager.getLoggerForXXX()' method(s). I suppose all of those >>> should be replaced by simply using slf4j logger factory as done in >>> AbstractSampleConsumer.java. >> >> Yes >> >>> - It might be even better if each logging line is more optimized by >>> taking advantage of slf4j logging methods (e.g, message format >>> arguments and throwable argument). >> >> Yes > > Plus, if we use formatted messages with arguments, the need for if > (log-is-enabled) statements might be gone for simple cases. Yes. > >> >>> - After all migrated, the old logkit and some other related unused >>> libraries should be gone. >> >> >> A possible option to avoid breaking too many existing third party plugins >> would be to embed in source code current logkit logger factory and logger >> so that it delegates to slf4j. >> We would drop avalon, logkit and excalibur jars. Good point. This can be revisited in the later step. >> >> >> >>> Am I in the right track? Any advice or thoughts? >> >> >> please wait for other team members to answer before starting code. >> Give a week . > > I would start slowly and contribute drop by drop first, to see if you are > going in the right direction. You're right. Maybe we can split the steps (with separate bz tickets) like the following (ordered by priority): Step 1: Replace logkit loggers with slf4j ones with keeping the current logkit binding solution. Step 2: Optimize logging statements. e.g, message format args, throwable args, unnecessary if-enabled-logging in simple ones, etc. Step 3: Drop avalon, logkit and excalibur with backward compatibility for 3rd party modules. (This step would require discussions about which logging framework/configuration can be used/changed later.) Regards, Woonsan > > Regards, > Felix > >> >>> Kind regards, >>> >>> Woonsan >>> >>> [1] >>> https://helpwanted.apache.org/task.html?ad91cbf270c711a1c6aa0e67180309 >>> d282c81e02 >>> [2] https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html >>> [3] http://www.slf4j.org/manual.html >>> [4] https://logging.apache.org/log4j/2.x/manual/ >>> configuration.html#Automatic_Configuration >>> [5] http://logback.qos.ch/manual/configuration.html#auto_configuration >>> >> >
