Roadmap for 2.25.1 release

[ppkarwasz]

Hi everyone,

@vy and I had a call to discuss the aftermath of the 2.25.0 release. While generally successful, we identified a few issues that affect usage in specific environments. To address these promptly, we're planning a 2.25.1 patch release in early July.

This schedule also gives users time to test and report any additional feedback on 2.25.0.

Upcoming Releases Overview

To give you a complete picture of what's ahead:

• 2.25.1: Early July — Patch release addressing specific regressions and edge-case issues.
• 3.0.0-beta4: Early August — The main blocker is Synchronization with main backlog #3161, which tracks the synchronization of improvements from the 2.x branch into main. Contributions are very welcome!
• 2.26.0: Early September — This release will include all improvements and bug fixes merged by then.

🔧 Roadmap for 2.25.1

We're targeting a small set of focused fixes that impact integration with alternative build tools and platforms:

• JBang Compatibility (Missing dependency jspecify version attribute in parent pom #3758, Missing property in the log4j-parent pom file in version 2.25.0 #3779):
  The jspecify.version property isn't resolvable in published parent POMs due to POM flattening. While this doesn't affect Maven or Gradle users (thanks to provided scope and inline metadata), it breaks tools like JBang. We'll address this in the patch.

• Gradle + Java 8 (log4j 2.25.0 cannot (directly) be used with Gradle on Java 8 #3754):
  The upgrade of spotbugs-annotations to a Java 11 version causes Gradle to reject log4j-api in Java 8 projects. Although the dependency is compileOnly, Gradle treats this conservatively.

• OSGi Compatibility (NPE in org.apache.logging.log4j.core.async.RingBufferLogEventHandler4.notifyCallback() #3706):
  Disruptor version detection currently misbehaves in OSGi environments due to improper use of TCCL. While a broader TCCL cleanup is planned for 2.26.0 (see Deprecate usage of TCCL in Loader/LoaderUtil #2850), a targeted fix will be made for this specific issue in 2.25.1.

• Third-party Plugin Compilation (java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options #3755):
  Users building third-party Log4j plugins have reported friction due to mandatory compiler arguments (-Alog4j.graalvm.groupId and -Alog4j.graalvm.artifactId). We'll improve documentation and investigate making these arguments optional, possibly adopting a strategy similar to picocli.

Thanks for your continued feedback and contributions!

Note

I'm sharing this roadmap both on GitHub Discussions and the dev@logging mailing list. However, since synchronization is one-way, please leave any comments on GitHub Discussions if possible.

[ppkarwasz]

🛠️ Additional Issue: Spring Boot Compatibility

2.25.0 introduced a regression that affects integration with Spring Boot (#3770):

• For historical reasons, Spring Boot uses LoggerContext.start(Configuration) to reconfigure the logging context, rather than the intended LoggerContext.reconfigure(Configuration) method.
• Although this usage is not recommended for new code, the widespread adoption of Spring Boot makes it important to preserve this (previously undocumented) behavior.

To maintain compatibility, we will restore the original behavior of LoggerContext.start(Configuration) in 2.25.1.

[garydgregory]

From my POV, I use Jetty (which has its own OSGi impl), Spring Boot and Spring Batch (😀 https://www.manning.com/books/spring-batch-in-action) for one project, so it's good to see 2.25.1 is planned for a July release.

[ppkarwasz]

The vote to release Apache Log4j 2.25.1 has started and will remain open for 72 hours. We invite the community to test the release candidate to help ensure a stable and reliable release.

How to Participate

We encourage developers and users to verify the release artifacts before they are published to Maven Central. Here’s how:

Maven Users

Add the following to your project's pom.xml:

<repositories>
  <!-- Always place Maven Central first to avoid overloading the Apache Nexus instance -->
  <repository>
    <id>central</id>
  </repository>
  <repository>
    <id>apache-logging-staging</id>
    <url>https://repository.apache.org/content/repositories/orgapachelogging-1320</url>
    <releases>
      <enabled>true</enabled>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </repository>
</repositories>

Then, update your Log4j dependencies to version 2.25.1.

Gradle Users

In your build.gradle, add the staging repository with proper filtering:

Groovy DSL

repositories {
    mavenCentral()

    maven {
        name = "apacheLoggingStaging"
        url = uri("https://repository.apache.org/content/repositories/orgapachelogging-1320")
        content {
            includeGroup "org.apache.logging"
            includeGroup "org.apache.logging.log4j"
        }
    }
}

Kotlin DSL

repositories {
    mavenCentral()

    maven {
        name = "apacheLoggingStaging"
        url = uri("https://repository.apache.org/content/repositories/orgapachelogging-1320")
        content {
            includeGroup("org.apache.logging")
            includeGroup("org.apache.logging.log4j")
        }
    }
}

Then, update your Log4j dependencies to version 2.25.1.

Reporting Results

• Run your application and test it against the release candidate
• Report any successes or issues by replying to the official vote thread on the dev@logging.apache.org mailing list.

Note

While only PMC members’ votes are binding, community feedback is highly valued—especially when it includes test results or bug reports.

Thank you for helping ensure a robust Log4j release!