RE: Trying log4j3 with java24 (virtual threads)

Hi Volkan,

Thanks, I will take a look at all this stuff.

BTW, do you have a realistic date to release the log4j3 GA?

Thanks,

Joan.

-----Original Message-----
From: Volkan Yaz=C4=B1c=C4=B1 <[email protected]>=20
Sent: Monday, January 27, 2025 9:52 AM
To: Log4J Users List <[email protected]>
Subject: Re: Trying log4j3 with java24 (virtual threads)

Hello Joan,

Thanks for reaching out for questions and feedback, much appreciated. =
See my responses below.

On Sat, Jan 25, 2025 at 1:39=E2=80=AFPM <[email protected]> =
wrote:

> I want to try log4j3 ... and I have some questions before getting =
started.
> We are in the process to migrate to virtual threads, our web=20
> application is running on java24/tomcat 10.1.34, still with log4j =
2.24.2.
>

Regarding your current production setup, note that the most recent Log4j =
2 version is `2.24.3`.


> 1. Being log4j3 virtual thread compatible, must I use sync loggers=20
> instead of the async ones?
>

It depends. For one, async. loggers are an extra performance =
optimization and we recommend users to carefully assess their use case =
and then opt for it =E2=80=93 see the performance =
<https://logging.apache.org/log4j/2.x/manual/performance.html> and =
async.
loggers <https://logging.apache.org/log4j/2.x/manual/async.html> page =
for details.

You might have migrated your code to Java 24 and virtual threads, etc. =
but there can still exist code paths that are logging from a platform =
thread.
If they happen to cause a bottleneck, async. loggers might still be an =
option there.

But allow me to remind the following from the Tuning Log4j Core for =
performance =
<https://logging.apache.org/log4j/2.x/manual/performance.html#core> =
section:

*"Extra tuning of any application will deviate you away from defaults =
and add up to the maintenance load. You are strongly advised to measure =
your application=E2=80=99s overall performance and then, if Log4j is =
found to be an important bottleneck factor, tune it carefully. When this =
happens, we also recommend you to evaluate your assumptions on a regular =
basis to check if they still hold. Remember, premature optimization is =
the root of all evil."*



> 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>
>     <dependency>
>       <groupId>org.apache.logging.log4j</groupId>
>       <artifactId>log4j-api</artifactId>
>       <version>${log4j2.version}</version>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.logging.log4j</groupId>
>       <artifactId>log4j-jakarta-web</artifactId>
>       <version>${log4j2.version}</version>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.logging.log4j</groupId>
>       <artifactId>log4j-slf4j-impl</artifactId>
>       <version>${log4j2.version}</version>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.logging.log4j</groupId>
>       <artifactId>log4j-1.2-api</artifactId>
>       <version>${log4j2.version}</version>
>     </dependency>
>
>    With log4j3, do I still need all these dependencies? I suppose I=20
> can remove disruptor if I use sync loggers, but is there anything else =

> not necessary to run my web application now?
>

Log4j 3 has a slightly different module breakdown:

   - Log4j 2 modules =
<https://logging.apache.org/log4j/2.x/components.html>
   - Log4j 3 modules
   <https://logging.staged.apache.org/log4j/3.x/components.html> (Note =
the
   `staged` in the host name. It means that you're looking at the latest
   documentation built from `main`, not from the most recent release!)

In particular, in Log4j 3, we tried to increase the granularity of the =
modules and avoid optional dependencies. For instance, Log4j 3 provides =
`log4j-async-logger`, which already depends on `com.lmax:disruptor`, =
hence you don't need to manually manage the Disruptor dependency =
anymore.

All in all, you shouldn't need to hand pick modules. Just follow the =
installation guide =
<https://logging.staged.apache.org/log4j/3.x/manual/installation.html>,
etc. and you should all be fine. (If not, please let us know, so we can =
improve the documentation in that direction.)


>    For example, I see 'log4j-jakarta-web' still in '3.0.0-alpha1'=20
> since Jun 21, 2023.
>

Log4j Jakarta has been moved to a separate repository. That is, it will =
have its own release cycle. Nevertheless, we will update Log4 3 BOM to =
reflect the most recent Log4j Jakarta components, so you don't need to =
worry about that.

Kind regards.