Add SLF4J to Log4j API bridge #1
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
git-svn-id: https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk@1241269 13f79535-47bb-0310-9956-ffa450edef68
Since the 1.8 binding is gone, we can use a simpler name.
Replace `slf4j18` with `slfj42`. Add a warning on the discontinuation of `slf4j18`.
Adds a test scope to all dependencies that inherit their scope from the parent POM.
Improves the `src/tools/sort-pom.xslt` stylesheet to sort dependencies in the POM files according to the scope, artifact id (with a priority for Logj2 artifacts) and group id. It uses this script to automatically sort all POM files.
This also requires fixing some OSGI tests.
This PR removes all explicitly versioned plugins that are also defined in the Apache ASF parent POM (`org.apache:apache`). This has the following effect on plugin versions: * `maven-assembly-plugin` bumped to 3.4.1 * `maven-jar-plugin` bumped to 3.2.2 * `maven-javadoc-plugin` bumped to 3.4.0 * `maven-project-info-reports-plugin` bumped to 3.3.0 * `maven-release-plugin` bumped to 3.0.0-M6 * `maven-scm-plugin` bumped to 1.13.0 * `maven-site-plugin` bumped to 3.12.0
The versions of all used plugins are specified in the `log4j` parent POM or other parent POMs (`log4j-bom`, `log4j-samples`, `log4j-spring-cloud-config` or `log4j-spring-cloud-config-samples`). The script `src/tools/explicit-version.xslt` can be used to check for explicitly provided version.
This replaces as many managed dependencies as possible with BOMs. All dependencies (except those specific to unpublished artifacts/samples) are listed in the main POM as property + dependency or property + BOM. It is therefore possible to override a dependency overriding a single property.
The 'default' maven-remote-resources-plugin execution is a no-op, because the ASF parent uses a different id.
Log4j2's Marker#getParents() does actually return `null` instead of an empty array.
To ensure maximum compatibility with Logback and the changes in SLF4J 2.0.1 (cf. [SLF4J-560](https://jira.qos.ch/browse/SLF4J-560)) we create the `LogBuilder` lazily only when `log()` is called.
- `/pom.xml` is moved to `/log4j-parent/pom.xml` - `/log4j-bom/pom.xml` is moved to `/pom.xml` - Implements the BOM organization described by Maven[1]. That is, `parent` inherits from `bom`. - Takes advantage of `flatten-bom` provided by `logging-parent` - Identical scheme to the one found in `-tools` and `-transformation` [1] https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
There are many modules that do not depend on `log4j-core` and they can be easily built without it on the processor path.
Since the split between modules that have Log4j Core plugins and those that don't is about 50/50, it is more proper to add `log4j-core` to some modules instead of removing it from others (and copy/paste all other options).
In order to prevent API breaking changes, this: * adds [`bnd-baseline-maven-plugin`](https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin), * fix the API changes that would require a major version bump, * set the OSGi version of each packages to `2.20.1` or `2.21.0`, depending on the kind of changes the package underwent since the `2.20.0` release.
Most of our modules with a transitive dependency on `slf4j-api` used version 1.7.36, while `log4j-slf4j-impl` used version 1.7.25 (due to a breaking change in `slf4j-ext`) and `log4j-slf4j2-impl` used version 2.0.x. This PR simplifies this configuration by: * switching `log4j-slf4j-impl` to use version 1.7.36 of `slf4j-api` and version 1.7.25 of `slf4j-ext`, * removing the need of `slf4j-ext` where applicable, * switching all the other modules to SLF4J 2.x, * modernizing the `log4j-to-slf4j` tests to use JUnit 5 instead of JUnit 4.
The `org.slf4j.ext.EventData` class was a primitive equivalent of Log4j's `StructuredDataMessage`. QOS.CH published CVE-2018-8088 against this class and removed it from `slf4j-ext` version 1.7.26. For a long time we kept support code to convert `EventData` to its Log4j equivalent for compatibility's sake: users that relied on this class could still use Log4j Core, but the functionality was **automatically** disabled once they upgraded `slf4j-ext`. Since 5 years passed since `slfj4-ext` 1.7.26 was published, we can safely assume that all the users upgraded the library and the support code can be removed.
After the removal of `EventData`, the only usage of `slf4j-ext` was in tests. However, since all `slf4j-ext` method calls delegate to `slfj4-api` method calls there is no sense in testing it directly.
The attribute is removed from all documentation and test configurations, except those that tes the `packages` attribute itself.
BND 7.x supports multi-release JARs, so we can remove many manual overrides of module names. We also **add** an override from `disruptor` to `com.conversantmedia.disruptor`, since new (Java 11 based) versions of `com.conversantmetida:disruptor` have a JPMS descriptor.
The semantics used to determine the `Throwable` attached to a log event changed in Logback 1.1.0 (in the fix to [LOGBACK-873](https://jira.qos.ch/browse/LOGBACK-873)). When there are not enough arguments to the log call to fill both the throwable field and the placeholders contained in the message pattern, Logback 1.1.0 and later prefer to fill the throwable field and leave some placeholders empty. Log4j Core does the opposite choice: it first fills all the placeholders and only fills the throwable field if there is something left. This change allows `log4j-slf4j-impl` and `log4j-slf4j2-impl` users to switch between the two behaviors by setting the property `log4j2.messageFactory` to: ``` org.apache.logging.slf4j.message.ThrowableConsumingMessageFactory ```
Bumps org.slf4j:slf4j-api from 2.0.9 to 2.0.16. --- updated-dependencies: - dependency-name: org.slf4j:slf4j-api dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: Piotr Karwasz <[email protected]>
Migrate `log4j-slf4j2-impl` to JUnit 5.
ppkarwasz
force-pushed
the
feature/slf4j-to-log4j-api
branch
from
22dc816 to
849e4b8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a new
slf4j-to-log4j-apibridge based onlog4j-slf4j2-implfrom the2.xbranch of Log4j.