Re: Trying log4j3 with java24 (virtual threads)

--000000000000b4e0cc062cac3075
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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]> wr=
ote:

> 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 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 instea=
d
> 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 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' 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.

--000000000000b4e0cc062cac3075--