[jira] [Commented] (LOG4J2-3582) Unexpected appender attribute after programmatically configuring two separate Configuration objects

["Ralph Goers (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17585676#comment-17585676 ] 

Ralph Goers commented on LOG4J2-3582:
-------------------------------------

This is working correctly. 

Most Appenders in Log4j2 have AppenderManagers where most of the real work happens. This is done so that when reconfiguration happens logging can continue writing to the prior configuration while the new one is installed without the need to block logging. If the old configuration references the same manager as the new configuration the manager is simply reused and any changed parameters are ignored. The way Log4j determines whether the managers are the same is by comparing the "name" parameter passed to AbstractManager.getManager(). In the case of the File Appenders the name field contains the file name. 

The only way to get around this would be to add a configuration that doesn't log to the file, thus causing the Manager to stop, and then reconfigure again. Of course, while this is happening any events logged would not go to the target file.

> Unexpected appender attribute after programmatically configuring two separate Configuration objects
> ---------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-3582
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3582
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Configurators
>            Reporter: Awais Chishti
>            Priority: Blocker
>
> Expected output from the code below:
> {quote}{{Got buffer size from second configuration: 7777, expected: 7777}}
> {quote}
> Actual output from the code below:
> {quote}{{Got buffer size from second configuration: 1234, expected: 7777}}
> {quote}
> Code:
> {code:java}
> package com.chishtia.mre;
> import org.apache.logging.log4j.Level;
> import org.apache.logging.log4j.core.Appender;
> import org.apache.logging.log4j.core.appender.RollingFileAppender;
> import org.apache.logging.log4j.core.appender.rolling.RollingFileManager;
> import org.apache.logging.log4j.core.appender.rolling.TimeBasedTriggeringPolicy;
> import org.apache.logging.log4j.core.config.Configuration;
> import org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder;
> import org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilderFactory;
> import org.apache.logging.log4j.core.config.builder.api.AppenderComponentBuilder;
> import org.apache.logging.log4j.core.config.builder.api.RootLoggerComponentBuilder;
> import org.apache.logging.log4j.core.config.builder.impl.BuiltConfiguration;
> /**
>  * Class to test log4j2 configuration state persistence
>  */
> public class Log4j2PersistentConfigurationMRE {
>     private static final String APPENDER_NAME = "someAppenderName";
>     private static Configuration getConfigurationWithBufferSize(final int bufferSize) {
>         // Initialize config
>         final ConfigurationBuilder<BuiltConfiguration> builder = ConfigurationBuilderFactory.newConfigurationBuilder();
>         builder.setConfigurationName("TestConfig");
>         // Add appenders
>         final AppenderComponentBuilder appenderBuilder = builder.newAppender(APPENDER_NAME, "RollingFile");
>         appenderBuilder.addComponent(builder.newComponent("TimeBasedTriggeringPolicy"));
>         appenderBuilder.addAttribute("filePattern", "example.log.%d{yyyy-MM-dd}");
>         appenderBuilder.addAttribute("bufferedIO", true);
>         appenderBuilder.addAttribute("bufferSize", bufferSize);
>         builder.add(appenderBuilder);
>         // Add root logger
>         final RootLoggerComponentBuilder rootLoggerBuilder = builder.newRootLogger(Level.INFO);
>         rootLoggerBuilder.add(builder.newAppenderRef(APPENDER_NAME));
>         builder.add(rootLoggerBuilder);
>         // Build
>         return builder.build();
>     }
>     private static void log4j2MREDemo() {
>         final Configuration firstConfiguration = getConfigurationWithBufferSize(1234);
>         final Configuration secondConfiguration = getConfigurationWithBufferSize(7777);
>         final Appender appender = secondConfiguration.getAppenders().get(APPENDER_NAME);
>         final RollingFileAppender rollingFileAppender = (RollingFileAppender) appender;
>         final RollingFileManager rollingFileManager = rollingFileAppender.getManager();
>         System.out.println("Got buffer size from second configuration: " +
>                            rollingFileManager.getBufferSize() +
>                            ", expected: 7777");
>     }
>     public static void main(final String[] args) {
>         log4j2MREDemo();
>     }
> }
> {code}
> TL;DR: It seems that the BufferSize appender attribute is not correctly set by ConfigurationBuilder::build() after its first invocation, and that the attribute set in the first invocation persists.
> Q: Is this expected behavior? If yes then what workaround will let me rebuild configurations without the previous state persisting?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)