Re: Approach for Dropping LogKit in favor of Apache Log4J2 + SLF4J

[Philippe Mouawad <ph...@gmail.com>]

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.mouawad@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 <se...@gmail.com> wrote:
>
>> On 27 March 2016 at 20:00, Philippe Mouawad <ph...@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 <se...@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.
>
>
>


-- 
Cordialement.
Philippe Mouawad.