Merge changes from 2.25.2 release
#3936
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
There is no `publish.profile` property in the `.asf.yaml` schema. Fixes #3598
The Javadoc site generation broke after upgrading to Maven Javadoc Plugin 3.10.0 due to a change in the output directory structure (see apache/maven-javadoc-plugin#1163). This update adjusts our build script to look in the new output location, restoring proper Javadoc generation. Closes #3753 > [!NOTE] > This change has already been applied to `2.x-site-pro`
…j-bom` to `log4j-parent` (#3763)
Bumps [org.apache.activemq:activemq-broker](https://github.com/apache/activemq) from 6.1.6 to 6.1.7. - [Commits](apache/activemq@activemq-6.1.6...activemq-6.1.7) --- updated-dependencies: - dependency-name: org.apache.activemq:activemq-broker dependency-version: 6.1.7 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>
…on `2.7.16` (#3769) Co-authored-by: ASF Logging Services RM <[email protected]>
Co-authored-by: ASF Logging Services RM <[email protected]>
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 #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 #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]>
…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 #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 #3770
) This update refines the `GraalVmProcessor` configuration example in response to feedback from #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 (#3745) * Update `com.fasterxml.jackson:jackson-bom` to version `2.19.1` (#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]>
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 #1485 and fixes #3792.
…tions (#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.
* 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 #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]>
Co-authored-by: Volkan Yazıcı <[email protected]>
Co-authored-by: Volkan Yazıcı <[email protected]>
…#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 #3828 * Add changelog entry
Historically, throwable pattern converters (`%ex`, `%xEx`, etc.) behaved in a context-sensitive way:
* If the **preceding formatter’s expansion** did not end with whitespace, the converter automatically inserted a space before rendering the exception.
In version `2.25.0`, this was changed to insert a **newline** instead of a space, but the behavior was still dependent on surrounding context.
#### What this change does
This PR removes the context-dependent behavior altogether and makes `%ex` expansion fully predictable, while remaining backward-compatible:
* When `%ex` is **added implicitly** because `alwaysWriteExceptions=true`:
* If the pattern already ends with `%n`, a plain `%ex` is appended.
* Otherwise, `%notEmpty{%n%ex}` is appended.
This ensures exceptions are always clearly separated from the main log message by a newline, without adding extra characters when no exception is present.
* When `%ex` is **explicitly included** in the pattern by the user:
* Its expansion is rendered exactly as written in the pattern.
* It will **never** prepend a newline on its own.
#### Why
* Eliminates confusing context-sensitive behavior.
* Makes output consistent and predictable.
* Preserves legacy expectations by only modifying implicitly added `%ex`.
Closes #3873
Co-authored-by: Volkan Yazıcı <[email protected]>
This update documents the historical whitespace handling of the `%ex` pattern converter and how it has evolved in the `2.25.x` releases. Key point: since `2.25.2`, when users add `%ex` explicitly in their pattern, Log4j no longer inserts any automatic separator. It is now entirely up to the user to decide how (or whether) to separate the stack trace from the preceding output. Related to #3837 Co-authored-by: Volkan Yazıcı <[email protected]>
ppkarwasz
approved these changes
Sep 22, 2025
ppkarwasz
reviewed
Sep 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 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.
Merge
rel/2.25.2tag to2.x