You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by jo...@ventusproxy.com on 2025/01/25 12:37:27 UTC
Trying log4j3 with java24 (virtual threads)
Hello,
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.
1. Being log4j3 virtual thread compatible, must I use sync loggers instead of the async ones?
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?
For example, I see 'log4j-jakarta-web' still in '3.0.0-alpha1' since Jun 21, 2023.
Thanks,
Joan.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
Hi Piotr,
Ok, I will give it a try. I will post now a new thread with a new matter to not mix.
Thanks,
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@mailing.copernik.eu>
Sent: Tuesday, January 28, 2025 5:46 PM
To: log4j-user@logging.apache.org
Subject: Re: Trying log4j3 with java24 (virtual threads)
Hi Joan,
On 28.01.2025 17:31, joan.balaguero@ventusproxy.com wrote:
> Same error with 3.0.0-alpha1
>
> Joan.
>
> -----Original Message-----
> From: joan.balaguero@ventusproxy.com <jo...@ventusproxy.com>
> Sent: Tuesday, January 28, 2025 5:24 PM
> To: 'Log4J Users List' <lo...@logging.apache.org>
> Subject: RE: Trying log4j3 with java24 (virtual threads)
>
> ...
>
> But when I start my application, this error occurs:
>
> Caused by: java.lang.NoSuchMethodError: 'boolean org.apache.logging.log4j.core.util.Loader.isClassAvailable(java.lang.String)'
> at org.apache.logging.log4j.web.Log4jWebInitializerImpl.<clinit>(Log4jWebInitializerImpl.java:57)
> at org.apache.logging.log4j.web.WebLoggerContextUtils.getWebLifeCycle(WebLoggerContextUtils.java:84)
> at org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:56)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4426)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
I was afraid that might happen. A small breaking change between Log4j Core 2 and 3 broke both artifacts.
I have freshly compiled a new `3.0.0-SNAPSHOT` version of `log4j-jakarta-web`, which should work. You just need to add our snapshot releases repo:
<repositories>
<repository>
<releases>
<enabled>false</enabled>
</releases>
<id>apache.snapshots</id>
<name>Apache Snapshot Repository</name>
<url>https://repository.apache.org/snapshots</url>
</repository>
</repositories>
The release process for a beta release is not long, but we have a documentation backlog that we need to address before performing a release, so it might take some time before we publish a `beta1`.
On the other hand the code of the Jakarta artifacts is pretty stable and has not changed in years. It should be safe to use it in a test environment.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
Hi Piotr,
Ok, with this version the error is gone, but now using the ' log4j-jakarta-web' I can' t log anything ... This is the log4j2 debug log:
First it seems the log4j2.xml file is found:
INFO: 2025-01-29T10:04:08.083865584Z main DEBUG getConfigURI found resource paths [/WEB-INF/log4j2.xml] in servletContext at [/WEB-INF/]
INFO: 2025-01-29T10:04:08.085089121Z main DEBUG getConfigURI found resource [file:/opt/ventusproxy/app/proxy-war/ROOT/WEB-INF/log4j2.xml] in servletContext at [/WEB-INF/log4j2.xml]
But, after several lines, this message says the opposite:
INFO: 2025-01-29T10:04:08.606930494Z main TRACE Trying to find [log4j2.xml] using ClassLoader.getSystemResource().
INFO: 2025-01-29T10:04:08.607054706Z main WARN No Log4j 2 configuration file found. Using default configuration (logging only errors to the console), or user programmatically provided configurations. Set system property 'log4j2.debug' to show Log4j 2 internal initialization logging. See https://logging.apache
.org/log4j/2.x/manual/configuration.html for instructions on how to configure Log4j 2
INFO: 2025-01-29T10:04:08.614842658Z main DEBUG Starting OutputStreamManager SYSTEM_OUT.false.false-2
INFO: 2025-01-29T10:04:08.615839040Z main INFO Starting LoggerContext[name=344b8190] with configuration DefaultConfiguration...
On our code:
System.setProperty("log.dir", dirLogs);
System.setProperty("log4j.loggerContext.selector", "org.apache.logging.log4j.core.selector.BasicContextSelector");
LoggerContext context = (LoggerContext) LogManager.getContext(false);
//context.setConfigLocation(log4j2Path.toUri()); <-- I'm not specifying the path to log4j2 programmatically in this case, that's the only difference
this.accessLog = context.getLogger("LOGGER_ACCESS");
What am I doing wrong?
Thanks,
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@mailing.copernik.eu>
Sent: Tuesday, January 28, 2025 5:46 PM
To: log4j-user@logging.apache.org
Subject: Re: Trying log4j3 with java24 (virtual threads)
Hi Joan,
On 28.01.2025 17:31, joan.balaguero@ventusproxy.com wrote:
> Same error with 3.0.0-alpha1
>
> Joan.
>
> -----Original Message-----
> From: joan.balaguero@ventusproxy.com <jo...@ventusproxy.com>
> Sent: Tuesday, January 28, 2025 5:24 PM
> To: 'Log4J Users List' <lo...@logging.apache.org>
> Subject: RE: Trying log4j3 with java24 (virtual threads)
>
> ...
>
> But when I start my application, this error occurs:
>
> Caused by: java.lang.NoSuchMethodError: 'boolean org.apache.logging.log4j.core.util.Loader.isClassAvailable(java.lang.String)'
> at org.apache.logging.log4j.web.Log4jWebInitializerImpl.<clinit>(Log4jWebInitializerImpl.java:57)
> at org.apache.logging.log4j.web.WebLoggerContextUtils.getWebLifeCycle(WebLoggerContextUtils.java:84)
> at org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:56)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4426)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
I was afraid that might happen. A small breaking change between Log4j Core 2 and 3 broke both artifacts.
I have freshly compiled a new `3.0.0-SNAPSHOT` version of `log4j-jakarta-web`, which should work. You just need to add our snapshot releases repo:
<repositories>
<repository>
<releases>
<enabled>false</enabled>
</releases>
<id>apache.snapshots</id>
<name>Apache Snapshot Repository</name>
<url>https://repository.apache.org/snapshots</url>
</repository>
</repositories>
The release process for a beta release is not long, but we have a documentation backlog that we need to address before performing a release, so it might take some time before we publish a `beta1`.
On the other hand the code of the Jakarta artifacts is pretty stable and has not changed in years. It should be safe to use it in a test environment.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Modifying buffer size on runtime
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Joan,
On 28.01.2025 19:12, joan.balaguero@ventusproxy.com wrote:
> 1. I programmatically change it to 16K while the app is running:
> INFO: 2025-01-28T17:56:17.015816443Z main TRACE Configured node RollingRandomAccessFile Key[type: int; name: bufferSize; qualifierType: PluginBuilderAttribute]=16384
>
> I check the log4j2.xml file:
> <RollingRandomAccessFile name="ACCESS_LOG" fileName="${sys:log.dir}vproxy_access" filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" bufferedIo="true" bufferSize="16384" immediateFlush="false">
>
>
> 2. Then I change it to 2K:
> INFO: 2025-01-28T17:57:47.216638176Z Log4j2-TF-1-ConfigurationFileWatcher-6 TRACE Configured node RollingRandomAccessFile Key[type: int; name: bufferSize; qualifierType: PluginBuilderAttribute]=2048
>
> Check:
> <RollingRandomAccessFile name="ACCESS_LOG" fileName="${sys:log.dir}vproxy_access" filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" bufferedIo="true" bufferSize="2048" immediateFlush="false">
>
> ...
>
> So, is it possible that changing the buffer size for this 'RollingRandomAccessFile' is not working on runtime?
Sorry, in my previous answer I didn't realize that your appender has the
same `fileName` attribute before and after the change.
To implement reconfigurations without log event loss (which is one of
the main differences between Log4j Core and Logback), Log4j Core splits
most appenders into a skinny appender and a manager. The manager takes
care of the underlying resource, e.g. keeps a file open, rotates it,
keeps a TCP/UDP file open, etc. Managers are accessed through a global
static registry by name (a representation of the resource accessed, such
as path for a file) and are reference counted. This is a killer feature:
* If Log4j Core is installed in the common Tomcat classloader, multiple
application (with different logger contexts) can safely log to the same
file. There will be only one manager.
* When you reconfigure Log4j Core, the "old" rolling file appender
passes the manager to the "new" rolling file appender, so the log file
is never closed.
Unfortunately for your use-case, this also means that some configuration
attributes (those that are used by the manager) can not be changed by
reconfiguration. For that to happen, the appender should be removed and
then created again or you can change the path to the log file.
We tried to document it under each appender (see for example the note in
the Appenders section[1]) and in the architecture page[2]. Feel free to
suggest documentation changes to make this behavior clearer: there is an
"Edit this Page" on each documentation page, so you can easily make a PR.
Piotr
[1]
https://logging.apache.org/log4j/2.x/manual/appenders/rolling-file.html#appenders
[2]
https://logging.apache.org/log4j/2.x/manual/architecture.html#AbstractManager
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Modifying buffer size on runtime
Posted by jo...@ventusproxy.com.
Hi Piotr,
One more thing I've seen. Finally, I'm modifying directly in the log4j2.xml file the buffer size of one of my loggers. I have enabled the debug, the log4j2 xml file has a monitor interval of 30 seconds.
I start my application with a buffer of 8K. Then:
1. I programmatically change it to 16K while the app is running:
INFO: 2025-01-28T17:56:17.015816443Z main TRACE Configured node RollingRandomAccessFile Key[type: int; name: bufferSize; qualifierType: PluginBuilderAttribute]=16384
I check the log4j2.xml file:
<RollingRandomAccessFile name="ACCESS_LOG" fileName="${sys:log.dir}vproxy_access" filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" bufferedIo="true" bufferSize="16384" immediateFlush="false">
2. Then I change it to 2K:
INFO: 2025-01-28T17:57:47.216638176Z Log4j2-TF-1-ConfigurationFileWatcher-6 TRACE Configured node RollingRandomAccessFile Key[type: int; name: bufferSize; qualifierType: PluginBuilderAttribute]=2048
Check:
<RollingRandomAccessFile name="ACCESS_LOG" fileName="${sys:log.dir}vproxy_access" filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" bufferedIo="true" bufferSize="2048" immediateFlush="false">
The point is that, while I'm logging, the ratio of lines that are logged is always the same, with 2048 it should be continually logging and with 16384 I should see pauses between two consecutive loggings. But not.
Then, if I restart the application, it works as expected.
So, is it possible that changing the buffer size for this 'RollingRandomAccessFile' is not working on runtime?
Thanks,
Joan.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Trying log4j3 with java24 (virtual threads)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Joan,
On 28.01.2025 17:31, joan.balaguero@ventusproxy.com wrote:
> Same error with 3.0.0-alpha1
>
> Joan.
>
> -----Original Message-----
> From: joan.balaguero@ventusproxy.com <jo...@ventusproxy.com>
> Sent: Tuesday, January 28, 2025 5:24 PM
> To: 'Log4J Users List' <lo...@logging.apache.org>
> Subject: RE: Trying log4j3 with java24 (virtual threads)
>
> ...
>
> But when I start my application, this error occurs:
>
> Caused by: java.lang.NoSuchMethodError: 'boolean org.apache.logging.log4j.core.util.Loader.isClassAvailable(java.lang.String)'
> at org.apache.logging.log4j.web.Log4jWebInitializerImpl.<clinit>(Log4jWebInitializerImpl.java:57)
> at org.apache.logging.log4j.web.WebLoggerContextUtils.getWebLifeCycle(WebLoggerContextUtils.java:84)
> at org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:56)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4426)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
I was afraid that might happen. A small breaking change between Log4j
Core 2 and 3 broke both artifacts.
I have freshly compiled a new `3.0.0-SNAPSHOT` version of
`log4j-jakarta-web`, which should work. You just need to add our
snapshot releases repo:
<repositories>
<repository>
<releases>
<enabled>false</enabled>
</releases>
<id>apache.snapshots</id>
<name>Apache Snapshot Repository</name>
<url>https://repository.apache.org/snapshots</url>
</repository>
</repositories>
The release process for a beta release is not long, but we have a
documentation backlog that we need to address before performing a
release, so it might take some time before we publish a `beta1`.
On the other hand the code of the Jakarta artifacts is pretty stable
and has not changed in years. It should be safe to use it in a test
environment.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
Hi,
Same error with 3.0.0-alpha1
Joan.
-----Original Message-----
From: joan.balaguero@ventusproxy.com <jo...@ventusproxy.com>
Sent: Tuesday, January 28, 2025 5:24 PM
To: 'Log4J Users List' <lo...@logging.apache.org>
Subject: RE: Trying log4j3 with java24 (virtual threads)
Hi Piotr,
Thanks for the quick response. I'm trying to remove my initialization of log4j and delegate it to the log4j-jakarta-web. When I add the dependency, maven requires me to add a version tag, so I set:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jakarta-web</artifactId>
<version>2.24.3</version>
<scope>runtime</scope>
</dependency>
But when I start my application, this error occurs:
Caused by: java.lang.NoSuchMethodError: 'boolean org.apache.logging.log4j.core.util.Loader.isClassAvailable(java.lang.String)'
at org.apache.logging.log4j.web.Log4jWebInitializerImpl.<clinit>(Log4jWebInitializerImpl.java:57)
at org.apache.logging.log4j.web.WebLoggerContextUtils.getWebLifeCycle(WebLoggerContextUtils.java:84)
at org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:56)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4426)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
Should I use another version? The 3.0.0 is in alpha1 yet.
Thanks,
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@mailing.copernik.eu>
Sent: Tuesday, January 28, 2025 3:49 PM
To: log4j-user@logging.apache.org
Subject: Re: Trying log4j3 with java24 (virtual threads)
Hi Joan,
On 28.01.2025 14:58, joan.balaguero@ventusproxy.com wrote:
> 0. Using these java version and log4j3, and taking into account that 3.0.0-beta1 already includes support for virtual threads, will the fact of pinning a thread for log output no longer happen?
If you are referring to the usage of `synchronized` blocks, not all such blocks were removed in 3.x, although it should be a rather easy PR. Note that Java 24 removed thread pinning if `synchronized` blocks are used.
> 1. You told me to set up "log4j-core" with scope = runtime, but I'm using it on my code to load the log4j xml config file:
>
> import org.apache.logging.log4j.core.LoggerContext;
> ( . . . )
> LoggerContext context = (LoggerContext) LogManager.getContext(false);
> context.setConfigLocation(Paths.get(servletRealPath +
> "WEB-INF/log4j.xml).toUri());
>
> Is this the correct way to do this? Or is there any other way that does not need to directly use log4j-core?
Loading the appropriate configuration file from the WAR archive is the job of `log4j-jakarta-web`. See the description of the `log4jConfiguration` servlet init parameter[1]. If you don't set the parameter, `/WEB-INF/log4j2.xml` will be loaded (not `/WEB-INF/log4j.xml`). I haven't checked, but version `3.0.0-alpha1` or even `2.24.3` of `log4j-jakarta-web` should be compatible with beta 3 of `log4j-core`.
[1] https://logging.apache.org/log4j/2.x/jakarta.html#log4jConfiguration
> b) Imported "log4j-api" (that adds the "log4j-api-2.24.1.jar" to our
> war file)
As a transitional measure, you could bump the version of `log4j-api` to `2.24.3`. We had a critical bug that sometimes returns `null` loggers, so we do not recommend `2.24.1` of the Log4j API (see release notes [2]). Obviously we'll fix the dependency version in beta 4.
[2]
https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-24-1
> c) Imported "log4j-slf4j2-impl", otherwise when our app starts I get the following warning:
>
> INFO: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> INFO: SLF4J: Defaulting to no-operation (NOP) logger implementation
> INFO: SLF4J: Seehttp://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
>
> Question: is it possible this warning is coming from any of our external libraries that we are using?
This is a side-effect of Maven's breadth-first conflict resolution
algorithm: `log4j-slf4j2-impl` requires `slf4j-api` version 2.x or higher, while other dependencies might requires SLF4J 1.x. Those dependencies probably come first in your dependency tree.
> 3. We have not included "log4j-jakarta-web", everything seems to be working fine without it. Is it really necessary to include it in when using app webs like ours executing in a tomcat container?
The purpose of `log4j-jakarta-web` is to synchronize Log4j's lifecycle with the lifecycle of the container. Basically it pick the right configuration file at startup and shuts down the appenders, when the application shuts down. See the documentation[3] for more info.
[3]
https://logging.apache.org/log4j/2.x/jakarta.html#log4j-jakarta-web-installation
> 4. We have programatically added:
> System.setProperty("log4j.loggerContext.selector", "org.apache.logging.log4j.core.selector.BasicContextSelector");
> --> This is to use synchronous loggers, I understand it is correct.
Yes, `BasicContextSelector` creates a single logger context and synchronous loggers. However, since you bundle Log4j Core with your application and web application libraries are not shared between applications, you would have the same effect with the default value `ClassLoaderContextSelector` (theoretically it gives one logger context per classloader, but since it can not be accessed from other classloaders… you effectively have one logger context)
[4]
https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.contextSelector
> Question: if the config is reloaded due to some change and, at the same time, there was a change in the ${sys:log.buffer} env. variable, will log4j be able to get the new value of ${sys:log.buffer}?
Yes, variables are interpolated again at each reconfiguration.
> 5. Finally, if I enable the log4j debug, how should I look at to check I'm really using synchronous loggers?
In Log4j Core 3 the asynchronous logger implementation is in the `log4j-async-logger` artifact. You can be pretty sure your loggers are synchronous.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
Hi Piotr,
Thanks for the quick response. I'm trying to remove my initialization of log4j and delegate it to the log4j-jakarta-web. When I add the dependency, maven requires me to add a version tag, so I set:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jakarta-web</artifactId>
<version>2.24.3</version>
<scope>runtime</scope>
</dependency>
But when I start my application, this error occurs:
Caused by: java.lang.NoSuchMethodError: 'boolean org.apache.logging.log4j.core.util.Loader.isClassAvailable(java.lang.String)'
at org.apache.logging.log4j.web.Log4jWebInitializerImpl.<clinit>(Log4jWebInitializerImpl.java:57)
at org.apache.logging.log4j.web.WebLoggerContextUtils.getWebLifeCycle(WebLoggerContextUtils.java:84)
at org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:56)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4426)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
Should I use another version? The 3.0.0 is in alpha1 yet.
Thanks,
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@mailing.copernik.eu>
Sent: Tuesday, January 28, 2025 3:49 PM
To: log4j-user@logging.apache.org
Subject: Re: Trying log4j3 with java24 (virtual threads)
Hi Joan,
On 28.01.2025 14:58, joan.balaguero@ventusproxy.com wrote:
> 0. Using these java version and log4j3, and taking into account that 3.0.0-beta1 already includes support for virtual threads, will the fact of pinning a thread for log output no longer happen?
If you are referring to the usage of `synchronized` blocks, not all such blocks were removed in 3.x, although it should be a rather easy PR. Note that Java 24 removed thread pinning if `synchronized` blocks are used.
> 1. You told me to set up "log4j-core" with scope = runtime, but I'm using it on my code to load the log4j xml config file:
>
> import org.apache.logging.log4j.core.LoggerContext;
> ( . . . )
> LoggerContext context = (LoggerContext) LogManager.getContext(false);
> context.setConfigLocation(Paths.get(servletRealPath + "WEB-INF/log4j.xml).toUri());
>
> Is this the correct way to do this? Or is there any other way that does not need to directly use log4j-core?
Loading the appropriate configuration file from the WAR archive is the
job of `log4j-jakarta-web`. See the description of the
`log4jConfiguration` servlet init parameter[1]. If you don't set the
parameter, `/WEB-INF/log4j2.xml` will be loaded (not
`/WEB-INF/log4j.xml`). I haven't checked, but version `3.0.0-alpha1` or
even `2.24.3` of `log4j-jakarta-web` should be compatible with beta 3 of
`log4j-core`.
[1] https://logging.apache.org/log4j/2.x/jakarta.html#log4jConfiguration
> b) Imported "log4j-api" (that adds the "log4j-api-2.24.1.jar" to our war file)
As a transitional measure, you could bump the version of `log4j-api` to
`2.24.3`. We had a critical bug that sometimes returns `null` loggers,
so we do not recommend `2.24.1` of the Log4j API (see release notes
[2]). Obviously we'll fix the dependency version in beta 4.
[2]
https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-24-1
> c) Imported "log4j-slf4j2-impl", otherwise when our app starts I get the following warning:
>
> INFO: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> INFO: SLF4J: Defaulting to no-operation (NOP) logger implementation
> INFO: SLF4J: Seehttp://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
>
> Question: is it possible this warning is coming from any of our external libraries that we are using?
This is a side-effect of Maven's breadth-first conflict resolution
algorithm: `log4j-slf4j2-impl` requires `slf4j-api` version 2.x or
higher, while other dependencies might requires SLF4J 1.x. Those
dependencies probably come first in your dependency tree.
> 3. We have not included "log4j-jakarta-web", everything seems to be working fine without it. Is it really necessary to include it in when using app webs like ours executing in a tomcat container?
The purpose of `log4j-jakarta-web` is to synchronize Log4j's lifecycle
with the lifecycle of the container. Basically it pick the right
configuration file at startup and shuts down the appenders, when the
application shuts down. See the documentation[3] for more info.
[3]
https://logging.apache.org/log4j/2.x/jakarta.html#log4j-jakarta-web-installation
> 4. We have programatically added:
> System.setProperty("log4j.loggerContext.selector", "org.apache.logging.log4j.core.selector.BasicContextSelector");
> --> This is to use synchronous loggers, I understand it is correct.
Yes, `BasicContextSelector` creates a single logger context and
synchronous loggers. However, since you bundle Log4j Core with your
application and web application libraries are not shared between
applications, you would have the same effect with the default value
`ClassLoaderContextSelector` (theoretically it gives one logger context
per classloader, but since it can not be accessed from other
classloaders… you effectively have one logger context)
[4]
https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.contextSelector
> Question: if the config is reloaded due to some change and, at the same time, there was a change in the ${sys:log.buffer} env. variable, will log4j be able to get the new value of ${sys:log.buffer}?
Yes, variables are interpolated again at each reconfiguration.
> 5. Finally, if I enable the log4j debug, how should I look at to check I'm really using synchronous loggers?
In Log4j Core 3 the asynchronous logger implementation is in the
`log4j-async-logger` artifact. You can be pretty sure your loggers are
synchronous.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Trying log4j3 with java24 (virtual threads)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Joan,
On 28.01.2025 14:58, joan.balaguero@ventusproxy.com wrote:
> 0. Using these java version and log4j3, and taking into account that 3.0.0-beta1 already includes support for virtual threads, will the fact of pinning a thread for log output no longer happen?
If you are referring to the usage of `synchronized` blocks, not all such
blocks were removed in 3.x, although it should be a rather easy PR. Note
that Java 24 removed thread pinning if `synchronized` blocks are used.
> 1. You told me to set up "log4j-core" with scope = runtime, but I'm using it on my code to load the log4j xml config file:
>
> import org.apache.logging.log4j.core.LoggerContext;
> ( . . . )
> LoggerContext context = (LoggerContext) LogManager.getContext(false);
> context.setConfigLocation(Paths.get(servletRealPath + "WEB-INF/log4j.xml).toUri());
>
> Is this the correct way to do this? Or is there any other way that does not need to directly use log4j-core?
Loading the appropriate configuration file from the WAR archive is the
job of `log4j-jakarta-web`. See the description of the
`log4jConfiguration` servlet init parameter[1]. If you don't set the
parameter, `/WEB-INF/log4j2.xml` will be loaded (not
`/WEB-INF/log4j.xml`). I haven't checked, but version `3.0.0-alpha1` or
even `2.24.3` of `log4j-jakarta-web` should be compatible with beta 3 of
`log4j-core`.
[1] https://logging.apache.org/log4j/2.x/jakarta.html#log4jConfiguration
> b) Imported "log4j-api" (that adds the "log4j-api-2.24.1.jar" to our war file)
As a transitional measure, you could bump the version of `log4j-api` to
`2.24.3`. We had a critical bug that sometimes returns `null` loggers,
so we do not recommend `2.24.1` of the Log4j API (see release notes
[2]). Obviously we'll fix the dependency version in beta 4.
[2]
https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-24-1
> c) Imported "log4j-slf4j2-impl", otherwise when our app starts I get the following warning:
>
> INFO: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> INFO: SLF4J: Defaulting to no-operation (NOP) logger implementation
> INFO: SLF4J: Seehttp://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
>
> Question: is it possible this warning is coming from any of our external libraries that we are using?
This is a side-effect of Maven's breadth-first conflict resolution
algorithm: `log4j-slf4j2-impl` requires `slf4j-api` version 2.x or
higher, while other dependencies might requires SLF4J 1.x. Those
dependencies probably come first in your dependency tree.
> 3. We have not included "log4j-jakarta-web", everything seems to be working fine without it. Is it really necessary to include it in when using app webs like ours executing in a tomcat container?
The purpose of `log4j-jakarta-web` is to synchronize Log4j's lifecycle
with the lifecycle of the container. Basically it pick the right
configuration file at startup and shuts down the appenders, when the
application shuts down. See the documentation[3] for more info.
[3]
https://logging.apache.org/log4j/2.x/jakarta.html#log4j-jakarta-web-installation
> 4. We have programatically added:
> System.setProperty("log4j.loggerContext.selector", "org.apache.logging.log4j.core.selector.BasicContextSelector");
> --> This is to use synchronous loggers, I understand it is correct.
Yes, `BasicContextSelector` creates a single logger context and
synchronous loggers. However, since you bundle Log4j Core with your
application and web application libraries are not shared between
applications, you would have the same effect with the default value
`ClassLoaderContextSelector` (theoretically it gives one logger context
per classloader, but since it can not be accessed from other
classloaders… you effectively have one logger context)
[4]
https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.contextSelector
> Question: if the config is reloaded due to some change and, at the same time, there was a change in the ${sys:log.buffer} env. variable, will log4j be able to get the new value of ${sys:log.buffer}?
Yes, variables are interpolated again at each reconfiguration.
> 5. Finally, if I enable the log4j debug, how should I look at to check I'm really using synchronous loggers?
In Log4j Core 3 the asynchronous logger implementation is in the
`log4j-async-logger` artifact. You can be pretty sure your loggers are
synchronous.
Piotr
RE: Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
Hello,
I'm already running log4j3 with java24 / tomcat 10.1.34. Just some questions:
0. Using these java version and log4j3, and taking into account that 3.0.0-beta1 already includes support for virtual threads, will the fact of pinning a thread for log output no longer happen?
1. You told me to set up "log4j-core" with scope = runtime, but I'm using it on my code to load the log4j xml config file:
import org.apache.logging.log4j.core.LoggerContext;
( . . . )
LoggerContext context = (LoggerContext) LogManager.getContext(false);
context.setConfigLocation(Paths.get(servletRealPath + "WEB-INF/log4j.xml).toUri());
Is this the correct way to do this? Or is there any other way that does not need to directly use log4j-core?
2. My config is finally this:
On the parent pom:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-bom</artifactId>
<version>${log4j2.version}</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
On the module (child) pom:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j2-impl</artifactId>
<scope>runtime</scope>
</dependency>
a) Imported "log4j-core" because of what I said in point 1.
b) Imported "log4j-api" (that adds the "log4j-api-2.24.1.jar" to our war file)
c) Imported "log4j-slf4j2-impl", otherwise when our app starts I get the following warning:
INFO: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
INFO: SLF4J: Defaulting to no-operation (NOP) logger implementation
INFO: SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Question: is it possible this warning is coming from any of our external libraries that we are using?
3. We have not included "log4j-jakarta-web", everything seems to be working fine without it. Is it really necessary to include it in when using app webs like ours executing in a tomcat container?
4. We have programatically added:
System.setProperty("log4j.loggerContext.selector", "org.apache.logging.log4j.core.selector.BasicContextSelector");
--> This is to use synchronous loggers, I understand it is correct.
System.setProperty("log.buffer", 4096);
--> This system property is used in the log4j.xml:
<RollingRandomAccessFile name="ACCESS_LOG" fileName="${sys:log.dir}vproxy_access" filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" ******** bufferSize="${sys:log.buffer}" ******* immediateFlush="false">
Question: if the config is reloaded due to some change and, at the same time, there was a change in the ${sys:log.buffer} env. variable, will log4j be able to get the new value of ${sys:log.buffer}?
5. Finally, if I enable the log4j debug, how should I look at to check I'm really using synchronous loggers?
Thanks!
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@mailing.copernik.eu>
Sent: Monday, January 27, 2025 10:44 AM
To: log4j-user@logging.apache.org
Subject: 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, joan.balaguero@ventusproxy.com 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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Trying log4j3 with java24 (virtual threads)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
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, joan.balaguero@ventusproxy.com 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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
Hi Piotr,
Thanks for all the info !
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@mailing.copernik.eu>
Sent: Monday, January 27, 2025 10:54 AM
To: log4j-user@logging.apache.org
Subject: Re: Trying log4j3 with java24 (virtual threads)
Hi Joan,
On 27.01.2025 10:05, joan.balaguero@ventusproxy.com wrote:
> BTW, do you have a realistic date to release the log4j3 GA?
The current `3.0.0-beta3` release contains all the features of a `3.0.0` release as far as I am concerned. The only blocker for a `3.0.0-rc.1` or even `3.0.0` release is:
* A certain number of PRs that were merged in the `2.x` branch, but not into `main`[1].
* Time to prepare releases. Last year Volkan and I contributed to Log4j as part of our dayjob, now our dayjobs are not Log4j-related.
Although `3.0.0` GA might not be far, we probably need a couple of months to find the time to release it.
Piotr
[1] https://github.com/apache/logging-log4j2/issues/3161
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Trying log4j3 with java24 (virtual threads)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Joan,
On 27.01.2025 10:05, joan.balaguero@ventusproxy.com wrote:
> BTW, do you have a realistic date to release the log4j3 GA?
The current `3.0.0-beta3` release contains all the features of a `3.0.0`
release as far as I am concerned. The only blocker for a `3.0.0-rc.1` or
even `3.0.0` release is:
* A certain number of PRs that were merged in the `2.x` branch, but not
into `main`[1].
* Time to prepare releases. Last year Volkan and I contributed to Log4j
as part of our dayjob, now our dayjobs are not Log4j-related.
Although `3.0.0` GA might not be far, we probably need a couple of
months to find the time to release it.
Piotr
[1] https://github.com/apache/logging-log4j2/issues/3161
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
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ı <vo...@yazi.ci>
Sent: Monday, January 27, 2025 9:52 AM
To: Log4J Users List <lo...@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 <jo...@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Trying log4j3 with java24 (virtual threads)
Posted by Volkan Yazıcı <vo...@yazi.ci>.
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 <jo...@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.