Remove jvmrunargs lookup (#3874)
#3891
Closed
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
* refactor(1.2-api): migrate to junit5 * refactor(junit5): replace assertTrue with AssertEquals where possible
Removes weak references to `Logger`s in `LoggerRepository`. The usage of weak references in `LoggerRepository` might cause `null` to be returned by `LogManager.getLogger()` of all Log4j Core versions up to `2.24.1`. Versions of Log4j API up to `2.24.0` did hold **hard** references to all the registered loggers, so the change will not alter the previous behavior. This PR also inverts the order of the `String` and `MessageFactory` keys to the `LoggerRepository` multi-map to limit the number of internal maps. The external map is a `WeakHashMap` to allow logger-specific message factories to be GC-ed. Closes apache#3143.
This adds setters to `@PluginBuilderAttribute` fields in setter classes that lack the corresponding public setter.
…ache#3209) This is a port of apache#3199 to the 2.24.x branch. Removes weak references to `Logger`s in `LoggerRepository`. The usage of weak references in `LoggerRepository` might cause `null` to be returned by `LogManager.getLogger()` of all Log4j Core versions up to `2.24.1`. Versions of Log4j API up to `2.24.0` did hold **hard** references to all the registered loggers, so the change will not alter the previous behavior. This PR also inverts the order of the `String` and `MessageFactory` keys to the `LoggerRepository` multi-map to limit the number of internal maps. The external map is a `WeakHashMap` to allow logger-specific message factories to be GC-ed. Closes apache#3143. Co-authored-by: Volkan Yazıcı <[email protected]>
This backports apache#3050 to the 2.24.x branch. Co-authored-by: Volkan Yazıcı <[email protected]>
Some libraries rely on `j.u.l.Logger.getLevel` returning the value that was set using `j.u.l.Logger.setLevel`. This PR changes apache#2353: - By default, the **effective** configuration of the logging backend is not modified by `log4j-jul` (same assumption as apache#2353). - All implementations of `j.u.l.Logger` mutator methods (`setLevel`, `setUseParentHandlers`, `addHandler`, …), must guarantee a change in the corresponding getter (`getLevel`, `getUseParentHandlers`, `getHandlers`, …). - Adds warnings in `ApiLogger` to inform users that calling those methods has no other side effect that change the result of the corresponding getter.
Fixes `RollingFileManager` to reopen the log file when the rollover was unsuccessful
The following commit modifies the annotation processor in 2.x to shell out a warning if the plugin builder attribute does not have a public setter.
A `@SuppressWarnings("log4j.public.setter")` annotation can be used to ignore this compilation warning in case it is a known issue.
The `@TempLoggingDir` JUnit 5 extensions create a totally deterministic directory to hold the log files for tests. Since the directory is deleted only if all the tests succeed, this causes a problem with test reruns.
…e#3785) This change explicitly defines the version of the `error_prone_annotations` dependency in the `log4j` parent POM. Previously, the version was inherited via the `error-prone.version` property from `logging-parent`. However, because the `log4j-bom` POM is flattened during publication, this property no longer resolves in consumer projects. Fixes apache#3779
### fix(test): fail `DisruptorTest` on async thread exceptions Ensure that DisruptorTest explicitly fails when an exception occurs on an asynchronous thread. This improves error detection and prevents silent test passes in the presence of async failures. ### fix: correctly detect Disruptor major version Ensure the Disruptor version is detected using the classloader that loaded `DisruptorUtil`, rather than the thread-context classloader. The previous implementation relied on `LoaderUtil.isClassAvailable`, which may fail in environments where the Disruptor classes aren't visible to the thread-context classloader.
Fixes apache#3771 This PR makes the `-Alog4j.graalvm.groupId` and `-Alog4j.graalvm.artifactId` arguments optional. * If **no arguments** are provided, metadata is stored in: ``` META-INF/native-image/log4j-generated/<content-derived-value> ``` Previously an error was thrown. * If **arguments are provided**, files go to: ``` META-INF/native-image/log4j-generated/<groupId>/<artifactId> ``` Previously `META-INF/native-image/<groupId>/<artifactId>` was used. The new path prevents collisions with user-provided metadata. Co-authored-by: Copilot <[email protected]>
…pache#3773) ### feat: add tests for `LoggerContext.start` behavior Add test verifying expected behavior of `LoggerContext.start(Configuration)` to ensure backward compatibility: - The configuration must always be replaced, even if the context has already started. - Only the first configuration should register the shutdown hook. ### fix: Restore Backward Compatibility with Spring Boot Reconfiguration Although Spring Boot never directly starts a `LoggerContext`, its logging system — including our `Log4j2SpringBootLoggingSystem` and equivalents in Spring Boot 2.x and 3.x — has consistently used `LoggerContext.start(Configuration)` for reconfiguration. This use case was not taken into consideration in apache#2614, causing a regression for Spring Boot users. To maintain backward compatibility with these usages, `start(Configuration)` now falls back to `reconfigure(Configuration)` if the context is already started. Closes apache#3770
…ache#3786) This update refines the `GraalVmProcessor` configuration example in response to feedback from apache#3755. The goal is to make the example more reliable and aligned with common Maven project setups. Key improvements include: * **Ensuring consistent parameter usage:** The example now adds `-Alog4j.graalvm.groupId` and `-Alog4j.graalvm.artifactId` to **all executions** of the Maven Compiler Plugin. This guarantees correct behavior regardless of the execution ID used in user projects. * **Simplifying plugin execution setup:** Instead of introducing a dedicated `generate-log4j-plugin-descriptor` execution, the example now modifies the existing `default-compile` execution. This reflects the most typical use case, where annotation processing and compilation occur together. These changes aim to make the setup easier to adopt while reducing configuration errors.
This update fixes the GraalVM reachability metadata generation for methods with annotated array parameters, such as `@Nullable String[]`. Previously, the code computed the fully qualified class name for the parameter using the **raw** type, which retained the annotations (e.g., `@org.jspecify.annotations.Nullable java.lang.String`). This resulted in incorrect metadata that was ignored by GraalVM. The issue is resolved by transforming the `DeclaredType` into a `TypeElement`, effectively removing any annotations, and then calling `getQualifiedName()` to correctly generate the fully qualified class name without annotations.
…j-parent (apache#3745) * Update `com.fasterxml.jackson:jackson-bom` to version `2.19.1` (apache#3745) * Empty commit to trigger required checks --------- Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Piotr P. Karwasz <[email protected]>
Co-authored-by: ASF Logging Services RM <[email protected]>
Co-authored-by: ASF Logging Services RM <[email protected]>
…3802) This change disables the sharing of formatted timestamps between threads in `InstantPatternThreadLocalCachedFormatter`. Previously, a mutable `StringBuilder` was shared across threads via a cached object. This could lead to situations where one thread ("owner") was modifying the builder while another thread was reading from it, resulting in inaccurate or truncated timestamps. This fix ensures that only thread-local instances are used, preventing concurrency issues and improving timestamp correctness under load. This change is similar in nature to apache#1485 and fixes apache#3792.
…tions (apache#3800) The `GraalVmProcessor` currently only generates metadata for Log4j plugins, overlooking other reflection usages in Log4j Core. This change adds reachability metadata for additional reflection cases to improve compatibility with GraalVM native images. ### Fixed Cases This PR addresses the following reflective instantiations: * **Context selectors and reliability strategies:** Ensures proper instantiation under GraalVM. * **`Configuration` instantiation in `DefaultConfigurationBuilder`:** Fixes support for the `log4j2.properties` configuration format when running on GraalVM. * **`BlockingQueue` instantiation in JSON Template Layout:** Enables GraalVM compatibility. Note: `MpmcArrayQueue` is not supported on GraalVM and must be fixed in the JCTools project. ### Known Limitations (Explicitly Ignored) The following cases are *not* addressed in this PR: * **JMX classes in `log4j-1.2-api`:** While GraalVM supports JMX, usage of Log4j 1.x’s JMX interface is likely minimal. * **`MulticastDnsAdvertiser`:** This feature is probably unused and could pose a security risk by advertising log file locations via mDNS.
…he#3795) * fix: Add `resource:` protocol to allowed URL schemes by default This update includes `resource:` in the list of allowed URL schemes for retrieving configuration files. See [`log4j2.configurationAllowedProtocols`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.configurationAllowedProtocols) Currently, the `resource:` protocol is used exclusively by a `URLStreamHandler` that retrieves files from the embedded resources in a GraalVM native image. This makes it a secure and appropriate source for trusted configuration files. This change cannot be easily and reliably tested through a unit test. An integration test will be provided in apache/logging-log4j-samples#345 Closes apache#3790 * fix: Add `resource` protocol only in native images This change introduces an internal `SystemUtils.isGraalVm()` method to detect the presence of GraalVM and enable the `resource` protocol. * Reword changelog entry --------- Co-authored-by: Volkan Yazıcı <[email protected]>
…he#3806) Bumps [org.junit:junit-bom](https://github.com/junit-team/junit-framework) from 5.13.2 to 5.13.3. - [Release notes](https://github.com/junit-team/junit-framework/releases) - [Commits](junit-team/junit-framework@r5.13.2...r5.13.3) --- updated-dependencies: - dependency-name: org.junit:junit-bom dependency-version: 5.13.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…apache#3831) * Correct log message format in AbstractDriverManagerConnectionSource The debug log message in AbstractDriverManagerConnectionSource had 4 placeholders but was supplied with 5 arguments. This corrects the format string to match the argument count, resolving the warning. Fixes apache#3828 * Add changelog entry
…attern Layout programmatically accessible (apache#3789) Co-authored-by: Piotr P. Karwasz <[email protected]> Co-authored-by: Roy Ash <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
ramanathan1504
force-pushed
the
issue-3887-cherry-pick
branch
from
20c0c51 to
e84655e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
33 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.
Cherry-pick #3874 (Remove
jvmrunargslookup) intomainto resolve LOG4J2-3887Important
Base your changes on
mainbranch for this PR, since it targets the 3.x line.Context
jvmrunargslookup is always empty #2726 removed the brokenjvmrunargslookup in 2.xjvmrunargslookup #3876 updated documentationjvmrunargslookup #3874 removed the lookup in 2.xjvmrunargslookup inmain#3887 ensures the removal is applied to mainChecklist
✅ Required checks
License: I confirm that my changes are submitted under the Apache License, Version 2.0.
Commit signatures: All commits are signed and verifiable. (See GitHub Docs on Commit Signature Verification).
Code formatting: The code is formatted according to the project’s style guide.
How to check and fix formatting
./mvnw spotless:check./mvnw spotless:applySee the build instructions for details.
Build & Test: Verified that the project builds and all unit tests pass.
How to build the project
Run:
./mvnw verifySee the build instructions for details.
🧪 Tests
jvmrunargsis already covered by existing tests.📝 Changelog
src/changelog/.3.x.x/3874_remove_jvmrunargs_lookup.xmlreflecting removal ofjvmrunargslookup.