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 Wed, 30 Mar 2016 06:26:25 GMT
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 <sebbaz@gmail.com> wrote:

> On 27 March 2016 at 20:00, Philippe Mouawad <philippe.mouawad@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 <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.
>



-- 
Cordialement.
Philippe Mouawad.

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