Hello, I'm happy to announce that thanks to the huge work of Woonsan Ko, we've now completed the migration to SLF4J/LOG4J2.
Big thanks to Woonsan ! for the quality of his work and the amount of involvement on this. Regards Philippe On Wed, Mar 30, 2016 at 8:26 AM, Philippe Mouawad < philippe.moua...@gmail.com> wrote: > Hello Sebb, > No problem for me to follow your approach. > Note that by doing this we would keep logkit and all the current feature > but just drop references to LogKit classes from all JMeter classes except > the one where configuration is used. > > So it will anyway ease the migration. > > Regards > > On Mon, Mar 28, 2016 at 3:33 PM, sebb <seb...@gmail.com> wrote: > >> 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. >> > > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
