Hi,
Same error with 3.0.0-alpha1
Joan.
-----Original Message-----
From: joan.balagu...@ventusproxy.com <joan.balagu...@ventusproxy.com>
Sent: Tuesday, January 28, 2025 5:24 PM
To: 'Log4J Users List' <log4j-user@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.balagu...@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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
