[jira] [Comment Edited] (LOG4J2-2457) RollingRandomAccessFileManager ignores new file patterns from programmatic reconfiguration

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

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

Ralph Goers edited comment on LOG4J2-2457 at 4/18/20, 7:26 AM:
---------------------------------------------------------------

Yes. FileExtension is an enum that is assigned in the RollingFileManager's constructor. I am reluctant to change this. Dynamically changing the file pattern was never intended when it was written and changing all the variables in RollingFileManager that updateData changes independently means that these values could be in various combinations if a rollover occurs while the update is taking place as they aren't all performed in one atomic operation. Furthermore, it seems very odd to me that you would want to change your file pattern to stop or start compressing files while the application is running as that could have operational consequences.

Finally, I believe this issue should be closed simply because the issue that was raised in the problem description was resolved.


was (Author: ralph.goers@dslextreme.com):
Yes. FileExtension is an enum that is assigned in the RollingFileManager's constructor. I am reluctant to change this. Dynamically changing the file pattern was never intended when it was written and changing all the variables in RollingFileManager that updateData changes independently means that these values could be in various combinations if a rollover occurs while the update is taking place as they aren't all performed in one atomic operation. Furthermore, it seems very odd to me that you would want to change your file pattern to stop or start compressing files while the application is running as that could have operational consequences.

> RollingRandomAccessFileManager ignores new file patterns from programmatic reconfiguration
> ------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-2457
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2457
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Appenders, Configurators
>    Affects Versions: 2.11.1
>            Reporter: Heiko Schwanke
>            Priority: Major
>             Fix For: 3.0.0, 2.11.2
>
>         Attachments: testcase.zip
>
>
> I use the Composite Configuration feature with two configuration files and set the System-Property "log4j.configurationFile" programmatically.
>  
> {code:java}
> System.setProperty("log4j.configurationFile", "log4j2.xml,log4j2-test-rotategz.xml");
> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
> ctx.reconfigure();
> {code}
>  
> The first config file defines an appender
>  
> {noformat}
> <RollingRandomAccessFile name="MyRollingFile" fileName="c:/temp/my.log" filePattern="c:/temp/my.log-%d{yyyy-MM-dd_HH-mm-ss}">{noformat}
>  
> and the second overwrites it with a different file pattern (.gz)
>  
> {noformat}
> <RollingRandomAccessFile name="MyRollingFile" fileName="c:/temp/my.log" filePattern="c:/temp/my.log-%d{yyyy-MM-dd_HH-mm-ss}.gz">{noformat}
>  
> As expected when i run my application the file rotation happens uncompressed until the programmatic reconfiguration.
> But after the programmatic reconfiguration the rotated files are still uncompressed.
> The following code is responsible for this behaviour:
>  
> {code:java}
> org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.updateData(Object)
> public void updateData(final Object data) {
>   final FactoryData factoryData = (FactoryData) data;
>   this.setRolloverStrategy(factoryData.getRolloverStrategy());
>   this.setTriggeringPolicy(factoryData.getTriggeringPolicy());
> }
> {code}
>  
> Looking at the parent class, i can see that patterns are updated too:
> {code:java}
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.updateData(Object)
> public void updateData(final Object data) {
>   final FactoryData factoryData = (FactoryData) data;
>   setRolloverStrategy(factoryData.getRolloverStrategy());
>   setTriggeringPolicy(factoryData.getTriggeringPolicy());
>   setPatternProcessor(new PatternProcessor(factoryData.getPattern(), getPatternProcessor()));
> }
> {code}
>  
> If i do the same in RollingRandomAccessFileManager everything works as expected.
> Please take note of the attached testcase, which contains all resources needed to reproduce easily.
> I would really appreciate, if you could investigate and fix this issue.
> Thank you so much in advance.
> Best regards
> Heiko



--
This message was sent by Atlassian Jira
(v8.3.4#803005)