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 2024/01/25 11:04:34 UTC
Async logger not logging after upgrading tomcat, jdk and log4j
Hello,
I would like to ask about this issue before starting to post debug logs.
My application has been using async logging for years by setting this env variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9:
-DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector
Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the above variable set, nothing is logged. If I remove it then it starts to log again, but without async.
Is there any change I'm missing regarding this async logging when moving to these new versions of tomcat, java and log4j?
Thanks,
Joan.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by jo...@ventusproxy.com.
Hi Ganesh,
I already have this <properties><log4j2.version>2.22.1</log4j2.version></properties>. The war file contains the right libraries, all in version 2.22.1.
Where can I see the supported tomcat/java versions depending on the log4j version?
Thanks,
Joan.
-----Original Message-----
From: Ganesh S <ga...@gmail.com>
Sent: Thursday, January 25, 2024 1:14 PM
To: Log4J Users List <lo...@logging.apache.org>
Subject: Re: Async logger not logging after upgrading tomcat, jdk and log4j
Hello,
Check the dependency hierarchy, which version of log4j is being used.
I had faced similar issue, even though if I specified some particular version of log4j, maven was not picking that particular version though there were no other dependencies which were using log4j at any nested level.
For that I had added the below in the pom.xml file
<properties>
<log4j2.version>2.22.1</log4j2.version></properties>
After this also if it doesn't work pick the appropriate version of log4j which supports your version of Java and tomcat.
On Thu, Jan 25, 2024, 4:35 PM <jo...@ventusproxy.com> wrote:
> Hello,
>
> I would like to ask about this issue before starting to post debug logs.
>
> My application has been using async logging for years by setting this
> env variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9:
>
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncL
> oggerContextSelector
>
> Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With
> the above variable set, nothing is logged. If I remove it then it
> starts to log again, but without async.
>
> Is there any change I'm missing regarding this async logging when
> moving to these new versions of tomcat, java and log4j?
>
> Thanks,
>
> Joan.
>
>
> ---------------------------------------------------------------------
> 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: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by Ganesh S <ga...@gmail.com>.
Hello,
Check the dependency hierarchy, which version of log4j is being used.
I had faced similar issue, even though if I specified some particular
version of log4j, maven was not picking that particular version though
there were no other dependencies which were using log4j at any nested level.
For that I had added the below in the pom.xml file
<properties>
<log4j2.version>2.22.1</log4j2.version></properties>
After this also if it doesn't work pick the appropriate version of log4j
which supports your version of Java and tomcat.
On Thu, Jan 25, 2024, 4:35 PM <jo...@ventusproxy.com> wrote:
> Hello,
>
> I would like to ask about this issue before starting to post debug logs.
>
> My application has been using async logging for years by setting this env
> variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9:
>
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector
>
> Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the
> above variable set, nothing is logged. If I remove it then it starts to log
> again, but without async.
>
> Is there any change I'm missing regarding this async logging when moving
> to these new versions of tomcat, java and log4j?
>
> Thanks,
>
> Joan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
RE: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by jo...@ventusproxy.com.
Hello,
I have checked the debug log using '-Dlog4j2.contextSelector' (that does not log) with the debug log without using this variable.
I can't see any differences, except obviously the messages regarding async contexts:
Async:
TRACE StatusLogger [AsyncContext@4857245] AsyncLoggerDisruptor creating new disruptor for this context.
DEBUG StatusLogger No AsyncWaitStrategyFactory was configured in the configuration, using default factory...
TRACE StatusLogger DefaultAsyncWaitStrategyFactory property AsyncLogger.WaitStrategy=TIMEOUT
TRACE StatusLogger DefaultAsyncWaitStrategyFactory creating TimeoutBlockingWaitStrategy(timeout=10, unit=MILLIS)
TRACE StatusLogger Log4jLoggerFactory.getContext() found anchor class org.mariadb.jdbc.util.log.Loggers$Slf4JLoggerFactory
TRACE StatusLogger [AsyncContext@4857245] AsyncLoggerDisruptor not starting new disruptor for this context, using existing object.
DEBUG StatusLogger Starting LoggerContext[name=AsyncContext@4857245, org.apache.logging.log4j.core.async.AsyncLoggerContext@70f14ed7]...
DEBUG StatusLogger Reconfiguration started for context[name=AsyncContext@4857245] at URI null (org.apache.logging.log4j.core.async.AsyncLoggerContext@70f14ed7) with optional ClassLoader: null
No Async:
DEBUG StatusLogger Starting LoggerContext[name=55494dde, org.apache.logging.log4j.core.LoggerContext@35c5ff53]...
DEBUG StatusLogger Reconfiguration started for context[name=55494dde] at URI null (org.apache.logging.log4j.core.LoggerContext@35c5ff53) with optional ClassLoader: null
Async:
DEBUG StatusLogger Stopped org.apache.logging.log4j.core.config.DefaultConfiguration@70f19d15 OK
TRACE StatusLogger Reregistering MBeans after reconfigure. Selector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector@788c3bad
TRACE StatusLogger Reregistering context (1/1): 'AsyncContext@4857245' org.apache.logging.log4j.core.async.AsyncLoggerContext@70f14ed7
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245,component=StatusLogger'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245,component=ContextSelector'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245,component=Loggers,name=*'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245,component=Appenders,name=*'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245,component=AsyncAppenders,name=*'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245,component=AsyncLoggerRingBuffer'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=AsyncContext@4857245,component=Loggers,name=*,subtype=RingBuffer'
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=AsyncContext@4857245
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=AsyncContext@4857245,component=AsyncLoggerRingBuffer
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=AsyncContext@4857245,component=StatusLogger
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=AsyncContext@4857245,component=ContextSelector
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=AsyncContext@4857245,component=Appenders,name=DefaultConsole-2
No async:
DEBUG StatusLogger Stopped org.apache.logging.log4j.core.config.DefaultConfiguration@35c5ff76 OK
TRACE StatusLogger Reregistering MBeans after reconfigure. Selector=org.apache.logging.log4j.core.selector.ClassLoaderContextSelector@4274e977
TRACE StatusLogger Reregistering context (1/1): '55494dde' org.apache.logging.log4j.core.LoggerContext@35c5ff53
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde,component=StatusLogger'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde,component=ContextSelector'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde,component=Loggers,name=*'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde,component=Appenders,name=*'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde,component=AsyncAppenders,name=*'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde,component=AsyncLoggerRingBuffer'
TRACE StatusLogger Unregistering but no MBeans found matching 'org.apache.logging.log4j2:type=55494dde,component=Loggers,name=*,subtype=RingBuffer'
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde,component=StatusLogger
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde,component=ContextSelector
DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde,component=Appenders,name=DefaultConsole-2
Joan.
-----Original Message-----
From: joan.balaguero@ventusproxy.com <jo...@ventusproxy.com>
Sent: Thursday, January 25, 2024 1:56 PM
To: 'Log4J Users List' <lo...@logging.apache.org>
Subject: RE: Async logger not logging after upgrading tomcat, jdk and log4j
Hello,
Here is the trace when starting tomcat with '-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector':
https://gist.github.com/joanbalaguero/1fa286417bfc9dbd3ce75e043bd26f3d
It seems the async contexts are started, but maybe someone can see something wrong that makes the log does not work.
Thanks,
Joan.
---------------------------------------------------------------------
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: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by jo...@ventusproxy.com.
Hello,
Here is the trace when starting tomcat with '-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector':
https://gist.github.com/joanbalaguero/1fa286417bfc9dbd3ce75e043bd26f3d
It seems the async contexts are started, but maybe someone can see something wrong that makes the log does not work.
Thanks,
Joan.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by jo...@ventusproxy.com.
Hi Piotr,
I already did it ... no success.
Thanks,
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@gmail.com>
Sent: Thursday, January 25, 2024 1:20 PM
To: Log4J Users List <lo...@logging.apache.org>
Subject: Re: Async logger not logging after upgrading tomcat, jdk and log4j
Hi Joan,
On Thu, 25 Jan 2024 at 12:06, <jo...@ventusproxy.com> wrote:
> My application has been using async logging for years by setting this env variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncL
> oggerContextSelector
>
> Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the above variable set, nothing is logged. If I remove it then it starts to log again, but without async.
>
> Is there any change I'm missing regarding this async logging when moving to these new versions of tomcat, java and log4j?
Can you test with
`-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector`
since `Log4jContextSelector` is deprecated since 2.10?
Although it should have no influence on the context selector, if you were using `log4j-web`, did you switch to `log4j-jakarta-web`?
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, 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.
Trying log4j3 with java24 (virtual threads)
Posted by jo...@ventusproxy.com.
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: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Joan,
On Fri, 26 Jan 2024 at 13:33, <jo...@ventusproxy.com> wrote:
> Issue fixed. The problem was in the disruptor library, which we also migrated from 3.4.4 to 4.0.0. Downgrading again to 3.4.4. fixed the problem.
Thank you for sharing your solution with us. Since nobody was able to
diagnose this problem from your status logs, I opened issue #2250[1]
to add the correct log statements during the initialization of LMAX
Disruptor.
Note also, that the upcoming version 2.23.0 will support both LMAX
Disruptor 3.x and 4.x (cf. issue #1829[2]), so you'll be able to
upgrade to 4.x.
As far as version 3.x of Log4j is concerned, our upcoming 3.0.0-beta2
will feature a separate `log4j-async-logger` artifact with a
non-optional dependency on `com.lmax.disruptor:disruptor`[3]. We hope
to relieve users from the burden of upgrading the Disruptor library
themselves and rely on the transitive dependency in
`log4j-async-logger`.
Piotr
[1] https://github.com/apache/logging-log4j2/issues/2250
[2] https://github.com/apache/logging-log4j2/issues/1829
[3] https://github.com/apache/logging-log4j2/pull/2241
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by jo...@ventusproxy.com.
Hi,
Issue fixed. The problem was in the disruptor library, which we also migrated from 3.4.4 to 4.0.0. Downgrading again to 3.4.4. fixed the problem.
Regards,
Joan.
-----Original Message-----
From: Piotr P. Karwasz <pi...@gmail.com>
Sent: Thursday, January 25, 2024 1:20 PM
To: Log4J Users List <lo...@logging.apache.org>
Subject: Re: Async logger not logging after upgrading tomcat, jdk and log4j
Hi Joan,
On Thu, 25 Jan 2024 at 12:06, <jo...@ventusproxy.com> wrote:
> My application has been using async logging for years by setting this env variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncL
> oggerContextSelector
>
> Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the above variable set, nothing is logged. If I remove it then it starts to log again, but without async.
>
> Is there any change I'm missing regarding this async logging when moving to these new versions of tomcat, java and log4j?
Can you test with
`-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector`
since `Log4jContextSelector` is deprecated since 2.10?
Although it should have no influence on the context selector, if you were using `log4j-web`, did you switch to `log4j-jakarta-web`?
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: Async logger not logging after upgrading tomcat, jdk and log4j
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Joan,
On Thu, 25 Jan 2024 at 12:06, <jo...@ventusproxy.com> wrote:
> My application has been using async logging for years by setting this env variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector
>
> Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the above variable set, nothing is logged. If I remove it then it starts to log again, but without async.
>
> Is there any change I'm missing regarding this async logging when moving to these new versions of tomcat, java and log4j?
Can you test with
`-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector`
since `Log4jContextSelector` is deprecated since 2.10?
Although it should have no influence on the context selector, if you
were using `log4j-web`, did you switch to `log4j-jakarta-web`?
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org