[
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: [email protected]):
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)
