New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate LogKit to SLF4J - Drop avalon, logkit and excalibur with backward compatibility for 3rd party modules #4226
Comments
Woonsan Ko (migrated from Bugzilla):
|
Woonsan Ko (migrated from Bugzilla):
One solution is to provide a custom log4j2 Appender implementation, as the most minimal direct log4j2 (runtime) dependency, for the Logs Viewer UI. So, users are supposed to configure this custom appender and reference in to root logger to keep the same functionality. The custom appender can possibly propagate events with the logging events. |
@pmouawad (migrated from Bugzilla): I am ok with all points. Thank you Regards |
Woonsan Ko (migrated from Bugzilla): This PR contains only the following at the moment:
It doesn't include a custom appender for the UI and unit test fixes yet. Also requires cleanups. But it seems working at runtime with log4j2 now in this steps: Please review the PR and share your thoughts on the direction. P.S. The original logkit Logger is a class (not an interface) with final methods. So, I decided to remove the final modifier and add abstract modifier for overridable methods (for wrapper impl). And I kept unsupportable methods as NOP impl. |
@pmouawad (migrated from Bugzilla):
The direction looks good to me. I suppose last step is having:
Regards |
Woonsan Ko (migrated from Bugzilla): I think the PR is now ready for review: Here's what I did with this PR in summary:
|
Woonsan Ko (migrated from Bugzilla):
It was added and configured in the default log4j2*.xml files.
I'm not sure if we want to do this with this ticket because the UI menu to change log level looks like a new improvement, not part of migration.
Yes, everything seems to be fixed. Thanks, Woonsan |
Woonsan Ko (migrated from Bugzilla):
Woonsan |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781756&view=rev Added: |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781757&view=rev Added: |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781758&view=rev Modified: |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781759&view=rev Added: |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781760&view=rev Added: |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781761&view=rev Removed: Author: pmouawad URL: http://svn.apache.org/viewvc?rev=1781762&view=rev Removed: |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781763&view=rev Added: Author: pmouawad URL: http://svn.apache.org/viewvc?rev=1781764&view=rev Modified: |
@pmouawad (migrated from Bugzilla): URL: http://svn.apache.org/viewvc?rev=1781765&view=rev Added: |
Woonsan Ko (Bug 60589):
First, I think the goals are as follows:
Goals
G1. Drop dependencies on logkit, exclalibur and logkit.
G2. Allow logging configuration with other popular logging framework configuration such as log4j2. log4j2 is the primary one to support.
(It should be able to support logback, but that's out of scope in this story. That can be part of other new story later.)
G3. Keep the existing UI functionalities.
G4. Keep the backward compatibility for 3rd party plugin modules.
G5. Ensure all the code use slf4j for logging (exception: usages of logkit logger interface for backward compatibility).
Second, let me try to list all the existing logging related features of JMeter
Current Logging Related Features
CF1. Users are able to configure log file, logging format, log levels for the combined root logger or for each category in the JMeter configuration properties file or command line arguments (
-j' for log file and
-L' for log level).CF2. Logs by libraries using Commons Logging are passed to the JMeter logging (logkit) by JMeter's Commons Logging implementation.
CF3. Advanced Excalibur logging configuration is possible through
log_config' property in JMeter configuration properties. CF3. Logs Viewer UI Menu can be turned on to receive logging event and show in the UI panel (org.apache.jmeter.gui.LoggerPanel). Note this is not reading the log file directly, but receives and renders log events currently propagated by the underlying logging framework at runtime only. CF4. For libraries using log4j API directly, log4j system property is set with
log4j.conf' configuration properties by default, but the logs through log4j is not used by JMeter, it's simply appended to a separate log file.Since the goals include removing dependencies on logkit, excalibur and avalon, and introducing log4j2 logging framework, I'd like to propose the following in the feature level.
Proposal in Feature Level
PF1. Users are able to configure log file, logging format, log levels, etc. for combined root logger and for each logger in a separate log4j2 configuration file, ./log4j2.xml or bin/log4j2.xml.
PF2. Users are able to change the log4j2 configuration by passing the standard log4j2 system property (e.g,
-Dlog4j2.configuration=file:/var/conf/log4j2-pt1.xml'). PF3. Logs Viewer UI Menu keeps the same functionality as it does. PF4. All the logging related configuration in JMeter configuration properties will be dropped. Also, the logging related command line arguments (
-j' for log file and-L' for log level) will be dropped. PF5. Advanced Excalibur logging configuration support will be dropped. PF6. JMeter Commons Logging provision will be dropped. Instead jcl-over-slf4j jar dependency will be provided for the same feature. PF7. log4j support through
log4j.configuration' system property and `log4j.conf' will be dropped. Instead Log4j 2's log4j-1.2-api.jar [1] will be provided for backward compatibility.Candidate solutions
[1] https://logging.apache.org/log4j/2.x/manual/migration.html
OS: All
Blocks:
The text was updated successfully, but these errors were encountered: