Hi +1 to remove all old/deprecated/not maintained framework If it's not made, technical debt will grow and in X years it will be more difficult (like migrate from ant to maven)
Of course if I can help, I will do it Antonio 2016-03-28 15:33 GMT+02:00 sebb <[email protected]>: > On 27 March 2016 at 20:00, Philippe Mouawad <[email protected]> > 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 <[email protected]> wrote: > > > >> On 3 January 2016 at 15:40, Philippe Mouawad < > [email protected]> > >> 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. >
