jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Approach for Dropping LogKit in favor of Apache Log4J2 + SLF4J
Date Sun, 27 Mar 2016 19:00:20 GMT
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 <sebbaz@gmail.com> wrote:

> On 3 January 2016 at 15:40, Philippe Mouawad <philippe.mouawad@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message