Add Log4j API to SLF4J bridge #2
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
git-svn-id: https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk@1614512 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk@1618450 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk@1618452 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk@1619028 13f79535-47bb-0310-9956-ffa450edef68
…or the version. git-svn-id: https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk@1619308 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/logging/log4j/log4j2/tags/log4j-2.0.2@1618451 13f79535-47bb-0310-9956-ffa450edef68
- Also added component names where one wasn't there.
SLF4J Simple Logger
- Using a lock in log4j-api (ProviderUtil) has prevented the need for this hack in OSGi.
complains. POM inheritance does not work like I thought it did!
- `/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.
Due to the upgrade from SLF4J 1.7.x to 2.x, the JPMS and OSGi descriptors of `log4j-to-slf4j` suffer from these shortcomings: * the JPMS descriptor uses a filebased `slf4j-api` module name (instead of `org.slf4j`, * the OSGi descriptor accepts a restricted range of SLF4J versions: [2, 3). Since `slf4j-api` 2.x is technically just a minor version update of `slf4j-api` 1.7.x, we should use an extended range of [1.7, 3). Closes #1983.
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.
By removing the reflective instantiation of `LoggerContextFactory` and `ThreadContextMap`, we make `log4j-to-jul` and `log4j-to-slf4j` more GraalVM-friendly.
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]>
- Make `StringArray` the default thread context map - Remove `CopyOnWriteSortedArrayThreadContextMap` - Move `GarbageFreeSortedArrayThreadContextMap` to `log4j-core`
This adds a Groovy script that fails the build if any optional JPMS module has the `transitive` qualifier. We remove the `transitive` modifier from all optional dependencies. Closes #2929. Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Piotr P. Karwasz <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
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
log4j-api-to-slf4jbridge based onlog4j-to-slf4jfrom the2.xbranch of Log4j.