Hello Joan,

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

On Sat, Jan 25, 2025 at 1:39 PM <joan.balagu...@ventusproxy.com> 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 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 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 – 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’s 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.

Reply via email to