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: Want to help with migrating from Apache LogKit to SLF4J
Date Fri, 06 Jan 2017 20:23:15 GMT
On Wednesday, January 4, 2017, sebb <sebbaz@gmail.com> wrote:

> On 3 January 2017 at 20:59, Woonsan Ko <woonsan@apache.org <javascript:;>>
> wrote:
> > On Tue, Jan 3, 2017 at 2:32 PM, Felix Schumacher
> > <felix.schumacher@internetallee.de <javascript:;>> wrote:
> >> Am 02.01.2017 um 21:31 schrieb Philippe Mouawad:
> >>>
> >>> On Monday, January 2, 2017, Woonsan Ko <woonsan@apache.org
> <javascript:;>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I'd like to help with migrating from Apache LogKit to SLF4J [1], and
> >>>> so I've been reading the current logging implementation with logkit,
> >>>> avalon-framework and excalibur-logger.
> >>>
> >>> Thanks for your proposal
> >>
> >> +1
> >>>
> >>>
> >>>>  From my understanding, maybe we can take the following approach:
> >>>> - Since SLF4J API doesn't provide a logging implementation or binding
> >>>> by itself, we need to choose one at least such as log4j2 [2] or
> >>>> logback. [3] IMHO, log4j2 binding provided by Apache Logging services
> >>>> project could be a good default binding option.
> >>>
> >>>
> >>> +1
> >>
> >> Well, I would start with what we have, which is a working binding for
> SLF4J.
> >
> > It seems more important to migrate each logger usages to use slf4j
> > logger in each class than replacing logging framework in the first
> > step. So, we can keep the current logkit binding in the first step.
> > That prioritization makes sense to me.
> >
> >>>
> >>>
> >>>> - By the default binding such as log4j2, I mean JMeter should be
> >>>> bundled with log4j2 library and its binding library as well as a
> >>>> default configuration file (e.g, log4j2.xml), by default. It seems
> >>>> neater to separate the logging configuration file from
> >>>> jmeter.properties with simply following its default auto-resolving
> >>>> conventions such as log4j2.xml [4] or logback.xml [5] to me.
> >>>
> >>> +1
> >>
> >> I am +-0 to any decision right now.
> >
> > This can be revisited with separate ticket after the first step done.
> >
> >>>
> >>>
> >>>> - It seems like each Logger instance is created as a static member by
> >>>> `LoggingManager.getLoggerForXXX()' method(s). I suppose all of those
> >>>> should be replaced by simply using slf4j logger factory as done in
> >>>> AbstractSampleConsumer.java.
> >>>
> >>> Yes
> >>>
> >>>> - It might be even better if each logging line is more optimized by
> >>>> taking advantage of slf4j logging methods (e.g, message format
> >>>> arguments and throwable argument).
> >>>
> >>> Yes
> >>
> >> Plus, if we use formatted messages with arguments, the need for if
> >> (log-is-enabled) statements might be gone for simple cases.
> >
> > Yes.
> >
> >>
> >>>
> >>>> - After all migrated, the old logkit and some other related unused
> >>>> libraries should be gone.
> >>>
> >>>
> >>> A possible option to avoid breaking too many existing third party
> plugins
> >>> would be to embed in source code current logkit logger factory and
> logger
> >>> so that it delegates to slf4j.
> >>> We would drop avalon, logkit and  excalibur jars.
> >
> > Good point. This can be revisited in the later step.
> >
> >>>
> >>>
> >>>
> >>>> Am I in the right track? Any advice or thoughts?
> >>>
> >>>
> >>> please wait for other team members to answer before starting code.
> >>> Give a week .
> >>
> >> I would start slowly and contribute drop by drop first, to see if you
> are
> >> going in the right direction.
> >
> > You're right.
> > Maybe we can split the steps (with separate bz tickets) like the
> > following (ordered by priority):
> > Step 1: Replace logkit loggers with slf4j ones with keeping the
> > current logkit binding solution.
> > Step 2: Optimize logging statements. e.g, message format args,
> > throwable args, unnecessary if-enabled-logging in simple ones, etc.
> > Step 3: Drop avalon, logkit and excalibur with backward compatibility
> > for 3rd party modules. (This step would require discussions about
> > which logging framework/configuration can be used/changed later.)
>
> I still think it's unnecessary.

I don't share your point.
I think we need to remove the old attic dependencies and use a more up to
date framework.
Besides some like log4j2 have really important perf improvements.
This will also let us reduce code size.


> However, the most important aspect is that users are able to use the
> logging system to debug problems.
> This means that there needs to be updated documentation on how to use
> the configuration options.
>
> I would start with the user-facing items.
> i.e documentation

+1

>
> and any user-configuration such as menu options.

+0 what exact menu item ? the one that allows settings log level on element
?

>
> Getting the documentation done is critical to the process.
> Doing it first should help tease out any so far unforseen issues.

+1


I'd also suggest short to medium PRs to avoid conflict if we take some time
to integrate them.

>
> > Regards,
> >
> > Woonsan
> >
> >>
> >> Regards,
> >>  Felix
> >>
> >>>
> >>>> Kind regards,
> >>>>
> >>>> Woonsan
> >>>>
> >>>> [1]
> >>>> https://helpwanted.apache.org/task.html?
> ad91cbf270c711a1c6aa0e67180309
> >>>> d282c81e02
> >>>> [2] https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html
> >>>> [3] http://www.slf4j.org/manual.html
> >>>> [4] https://logging.apache.org/log4j/2.x/manual/
> >>>> configuration.html#Automatic_Configuration
> >>>> [5] http://logback.qos.ch/manual/configuration.html#auto_
> configuration
> >>>>
> >>>
> >>
>


-- 
Cordialement.
Philippe Mouawad.

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