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ıcı <vol...@yazi.ci> Sent: Monday, January 27, 2025 9:52 AM To: Log4J Users List <log4j-user@logging.apache.org> 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 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. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
