On 27 March 2016 at 20:00, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > 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);
No; that is error-prone, tedious to do and unnecessary. If we really are going to drop the Avalon logger then the obvious way to do this is to create a new version of getLoggerForClass() that returns the correct Logger. But as I recall no one has addressed the issues I raised regarding loss of functionality. > 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.
