Re: Trying log4j3 with java24 (virtual threads)

--------------wkkaNBIuwcWLrRiBg5JV02Xh
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Joan,

On 28.01.2025 14:58, [email protected] 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

--------------wkkaNBIuwcWLrRiBg5JV02Xh--