Conversation
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] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…on `2.7.16` (#3769) Co-authored-by: ASF Logging Services RM <private@logging.apache.org>
Co-authored-by: ASF Logging Services RM <private@logging.apache.org>
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 <175728472+Copilot@users.noreply.github.com>
…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.
Co-authored-by: ASF Logging Services RM <private@logging.apache.org>
Co-authored-by: ASF Logging Services RM <private@logging.apache.org>
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ı <volkan@yazi.ci>
This change sanitizes the output of `Log4j1XmlLayout` by replacing characters that are not permitted in XML 1.0 with the Unicode replacement character (`U+FFFD`). This guarantees that the generated log output is always well-formed XML and can be parsed by any XML 1.0–compliant parser, even when log data contains control characters or other invalid code points. Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This change sanitizes the output of `MapMessage.asXml()` by replacing characters not permitted in XML 1.0 with the Unicode replacement character (`U+FFFD`). Although `MapMessage.asXml()` is not currently used by any layout, this aligns its behavior with `XmlLayout` and `Log4j1XmlLayout`, ensuring consistent and well-formed XML output across the codebase.
This change updates `JsonWriter` to serialize non-finite `float` and `double` values (`NaN`, `Infinity`, and `-Infinity`) as JSON strings. This behavior aligns with Jackson's `JsonWriteFeature#WRITE_NAN_AS_STRINGS`. Previously, these values were written without quotes, which produces **invalid JSON** according to the JSON specification.
In `2.21.0`, `Rfc5424Layout` was migrated from a factory method to the builder pattern. During this change, the recognized names of several configuration attributes unintentionally diverged from the documented ones. As a result, some documented attributes were no longer recognized, while new, undocumented names were introduced. This change restores support for the documented attribute names while continuing to accept the names introduced in `2.21.0` for backward compatibility. Fixes #4022 Co-authored-by: Volkan Yazıcı <volkan@yazi.ci> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…4075) This change updates the usage of `SslConfiguration#createSSLConfiguration` to the 4-parameter factory method introduced in Log4j 2.12.0. Using the newer factory method keeps the code aligned with the current API and ensures that all configuration parameters supported by recent Log4j versions are correctly propagated during SSL configuration creation. Fixes #4061
* docs: recommend use of appropriately scoped trust roots This change adds an important note to the documentation for `log4j2.trustStoreLocation` and the `TrustStore` plugin, advising users to configure trust stores with trust roots that are appropriate for their communication scope. The recommendation is grounded in public guidance from [NIST SP 800-52 Rev. 2: *Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations*](https://csrc.nist.gov/pubs/sp/800/52/r2/final), which advises minimizing trust anchors to those necessary for the intended connections. * fix: rename partial
This PR introduces a new `versioning` page under *Support* that summarizes the support status of Apache Log4j releases and documents the long-standing project policy: * Log4j follows semantic versioning. * Only the latest minor of the latest major receives patch releases for bug and security fixes. * Vulnerability reports are accepted for **all** `2.x` releases. * Log4j `1.x` is EOL and no longer accepts vulnerability reports. Related to #1867 Fixes #3988 Co-authored-by: Volkan Yazıcı <volkan@yazi.ci>
… in Pattern Layout (#4033) Signed-off-by: Jongmin Chung <chungjm0711@gmail.com> Co-authored-by: Volkan Yazıcı <volkan@yazi.ci>
#4041) This makes it easier to build `PluginProcessor` by itself separately from the rest of `log4j-core`, and then include that processor when building the rest of core, instead of having to compile all of core twice.
# Conflicts: # log4j-core-test/src/main/java/org/apache/logging/log4j/core/test/package-info.java # log4j-core/src/main/java/org/apache/logging/log4j/core/appender/package-info.java # log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java # log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/action/package-info.java # log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/package-info.java # log4j-core/src/main/java/org/apache/logging/log4j/core/async/package-info.java # log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/processor/PluginProcessor.java # log4j-core/src/main/java/org/apache/logging/log4j/core/config/xml/package-info.java # log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/package-info.java # log4j-core/src/main/java/org/apache/logging/log4j/core/script/package-info.java # log4j-parent/pom.xml # pom.xml # src/changelog/.2.x.x/update_co_elastic_clients_elasticsearch_java.xml # src/changelog/.2.x.x/update_com_github_jnr_jnr_ffi.xml # src/changelog/.2.x.x/update_fast_xml_parser.xml # src/changelog/.2.x.x/update_org_apache_commons_commons_lang3.xml # src/changelog/.2.x.x/update_org_gradlex_gradle_module_metadata_maven_plugin.xml # src/changelog/.2.x.x/update_org_junit_junit_bom.xml # src/changelog/.2.x.x/update_org_xerial_snappy_snappy_java.xml # src/changelog/2.23.0/revamp_StatusLogger.xml # src/changelog/2.25.0/update_org_mongodb_bson.xml # src/changelog/2.25.1/3754_fix-gradle-build.xml # src/site/antora/modules/ROOT/pages/manual/plugins.adoc
vy
approved these changes
Mar 29, 2026
github-project-automation
bot
moved this from Approved
to Merged
in Log4j pull request tracker
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 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.
Merges the differences introduced in branch
2.25.xback to2.x