Hello, Just for information , within fix of : https://bz.apache.org/bugzilla/show_bug.cgi?id=59240
I introduced an slf4j adapter for Logkit. It was not for this subject particularly but more because some very interesting 3rd party logs were dropped by Nop impl (ph-css in this case but it's for every 3rd party logging through slf4j). But thinking about it, a way to move forward is to replace now everywhere: private static final Logger LOG = LoggingManager.getLoggerForClass(); by : private static final Logger LOG = LoggerFactory.getLogger (<CurrentClass>.class); Regards Philippe On Tue, Jan 5, 2016 at 11:38 AM, sebb <seb...@gmail.com> wrote: > On 3 January 2016 at 15:40, Philippe Mouawad <philippe.moua...@gmail.com> > wrote: > > Hello, > > I am writing this message to have your opinion on the approach we should > > follow. > > This assumes that we are agreed on replacing logging. > I still think this is unnecessary work, and there is a lot to do. > > In any case, I think the work needs to be done in a branch so we can > see how it will work in practise. > > > Current situation: > > > > - log configuration is done in jmeter.properties through: > > - log_format > > - log_format_type > > - log_level.[package_name].[classname]=[PRIORITY_LEVEL] > > - log_file.[category]=[filename] > > - log_file=jmeter.log > > - log_config=logkit.xml > > > > > > I see 2 ways to proceed in implementation: > > > > COMMON PART: > > > > - We keep LoggingManager as is for third party plugins > > - We create a LogTarget implementation that uses SLF4J to make all > > current logging still work. > > - Only this implementation will still use LogKit > > - In next version of JMeter will will drop definitely > > LogKit+Excalibur+Avalon > > > > > > *APPROACH 1:* > > Recode what currently exists for LogKit for Log4j2: > > > > - We create a new class to initialize logging based on Log4j2 and > follow > > one of these approaches: > > - https://logging.apache.org/log4j/2.x/manual/customconfig.html > > - From my understanding , we should create a custom > > CustomConfigurationFactory that takes Properties as Constructor > passed in > > JMeterUtils#initLogging > > > > > > > > *APPROACH 2:* > > We drop what currently exists and just initialize it simply with a Log4j2 > > configuration file, we only keep: > > > > - log_file=jmeter.log as it is used by -j command line option > > - log_config=log4j2.xml to configure the logging > > This appears to ignore one of the most useful parts of the config > which allows one to configure logging separately for different > packages and classes. > It is also used by the JMeter menu item Help/Enable|Disable debug > > > > > My opinion is that we should stick to standard mechanism of Log4j2 that > is > > largelly documented and known and reduce as much as possible any custom > > configuration in JMeter. > > Where is it documented how to enable/disable debug for a specific class? > > > This of course breaks backward compatibility but version numbering will > be > > explicit about it as long as the release notes. > > Regards > > Philippe M. > > @philmdot > -- Cordialement. Philippe Mouawad.
