Re: Trying log4j3 with java24 (virtual threads)

Hi Joan,

We did prepare a migration guide from Log4j 2 to Log4j Core 3:

https://logging.apache.org/log4j/3.x/migrate-from-log4j2.html

As Volkan mentioned, some features migrated to new modules, others were 
deprecated.

On 25.01.2025 13:37, [email protected] wrote:
> 2. My current maven looks like below now, where log4j2.version is '2.24.2'
>
>      <!-- disruptor -->
>      <dependency>
>        <groupId>com.lmax</groupId>
>        <artifactId>disruptor</artifactId>
>        <version>4.0.0</version>
>      </dependency>
>
>      <!-- log4j -->
>      <dependency>
>        <groupId>org.apache.logging.log4j</groupId>
>        <artifactId>log4j-core</artifactId>
>        <version>${log4j2.version}</version>
>      </dependency>

We strongly recommend the usage of the Bill-of-Materials (BOM):

<dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>org.apache.logging.log4j</groupId>
       <artifactId>log4j-bom</artifactId>
       <version>3.0.0-beta3</version>
       <scope>import</scope>
       <type>pom</type>
     </dependency>
   </dependencies>
</dependencyManagement>

There are multiple reasons behind that:

* If you don't use the BOM an unrelated direct dependency (e.g. Apache 
POI) can pull a version of `log4j-api`, which is incompatible with 
`log4j-core` version `3.0.0-beta3`.

* The `log4j-core` artifact version `3.0.0-beta3` requires `log4j-api` 
version `2.24.x`. You don't have to remember that if you use the BOM.

We also recommend to put `log4j-core` in the `runtime` scope, since you 
will not be referring to it from your code.

<dependency>

   <groupId>org.apache.logging.log4j</groupId>

   <artifactId>log4j-core</artifactId>

   <scope>runtime</scope>

</dependency>

Regarding `com.lmax:disruptor`, you need to replace it with:

<dependency>

   <groupId>org.apache.logging.log4j</groupId>

   <artifactId>log4j-async-logger</artifactId>

   <scope>runtime</scope>

</dependency>

LMAX Disruptor will still be a transitive dependency of your project, 
but you don't need to upgrade it manually any more.

>      <dependency>
>        <groupId>org.apache.logging.log4j</groupId>
>        <artifactId>log4j-api</artifactId>
>        <version>${log4j2.version}</version>
>      </dependency>

As mentioned above, `log4j-core` 3.x will depend on `log4j-api` 2.x, so 
you should use the BOM.

Also, if you don't use the Log4j API[1] in your code (because you use 
another logging API like SLF4J for example), you can remove this 
dependency. Don't get me wrong: we are happy if you use Log4j API and 
there are a lot of advantages to use Log4j API over SLF4J[2], but we 
understand if you use a different logging API. After all, logging APIs 
are there to give you the freedom to choose whatever implementation you 
want.

[1] https://logging.apache.org/log4j/3.x/manual/api.html

[2] 
https://stackoverflow.com/questions/41498021/is-it-worth-to-use-slf4j-with-log4j2

>      <dependency>
>        <groupId>org.apache.logging.log4j</groupId>
>        <artifactId>log4j-jakarta-web</artifactId>
>        <version>${log4j2.version}</version>
>      </dependency>
As Volkan mentioned, `log4j-jakarta-web` will have its own lifecycle and 
we didn't have the time to release a Beta version yet, sorry. It is on 
our TODO list.
>      <dependency>
>        <groupId>org.apache.logging.log4j</groupId>
>        <artifactId>log4j-slf4j-impl</artifactId>
>        <version>${log4j2.version}</version>
>      </dependency>

The choice of the SLF4J-to-Log4j API bridge to use depends on the 
version of SLF4J you use. For SLF4J 2.x you need to use 
`log4j-slf4j2-impl` instead.

>      <dependency>
>        <groupId>org.apache.logging.log4j</groupId>
>        <artifactId>log4j-1.2-api</artifactId>
>        <version>${log4j2.version}</version>
>      </dependency>

This is a temporary artifact to help users upgrade from Log4j 1 to Log4j 
2. In 2025 you probably don't want it. It is only required if:

* If you have dependencies that use Log4j 1 as logging API. Most 
libraries migrated to Commons Logging or SLF4J by 2010, so no modern 
library should require it.

* If you have an extensive user base that has custom `log4j.properties` 
configuration files and you wish to allow them to keep using that format.

Piotr