Add Log4j2 rolling policy configuration #47260
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
spring-projects-issues
added
the
status: waiting-for-triage
philwebb
added
the
for: team-meeting
hojooo
force-pushed
the
log4j2-rolling-policy
branch
from
66fcaf7 to
b5d3b84
Compare
hojooo
force-pushed
the
log4j2-rolling-policy
branch
from
936ec72 to
05f8bb4
Compare
Member
|
@hojooo can you please rebase this PR to @ppkarwasz would you have a min to review this one please? I am wondering, in particular, about |
snicoll
added
the
status: waiting-for-feedback
Contributor
Author
|
@snicoll Got it, thanks. I’ll update the PR shortly. |
spring-projects-issues
added
status: feedback-provided
Signed-off-by: hojooo <ghwn5833@gmail.com>
Log4j2: Introduce SpringBootTriggeringPolicy and wire plugin discovery
- Add SpringBootTriggeringPolicy plugin supporting size, time, size-and-time, and cron strategies
- Read rolling strategy parameters from LOG4J2_ROLLINGPOLICY_* system properties (fallback to attributes)
- Register Boot plugin package in Log4J2LoggingSystem to ensure plugin discovery
- Use SpringBootTriggeringPolicy under a top-level Policies wrapper in log4j2-file.xml
Signed-off-by: hojooo <ghwn5833@gmail.com>
Log4j2: Add property-driven rolling strategy support and metadata
- Introduce rolling policy properties: strategy, time-based.interval, time-based.modulate, cron.schedule
- Extend Log4j2RollingPolicySystemProperty with STRATEGY, TIME_INTERVAL, TIME_MODULATE, CRON_SCHEDULE
- Propagate new properties in Log4j2LoggingSystemProperties (with deprecated fallback guarded for null)
- Document new properties in configuration metadata
- Update Log4j2LoggingSystemPropertiesTests to assert new system properties mappingAdd Log4j2 rolling policy configuration support
Signed-off-by: hojooo <ghwn5833@gmail.com>
Tests: Initialize with packaged file config and unwrap composite policy
- Initialize with classpath:org/springframework/boot/logging/log4j2/log4j2-file.xml to validate file-based rolling
- Unwrap CompositeTriggeringPolicy to locate nested SpringBootTriggeringPolicy and assert its delegate
- Keep assertions for time, size-and-time, and cron strategies
Signed-off-by: hojooo <ghwn5833@gmail.com>
Refactor Builder import path
Signed-off-by: hojooo <ghwn5833@gmail.com>
add clean-history-on-start and total-size-cap property in log4j2-file.xml
Signed-off-by: hojooo <ghwn5833@gmail.com>
refactor indent
Signed-off-by: hojooo <ghwn5833@gmail.com>
Refactor Log4j2LoggingSystemPropertiesTests to verify System.setProperty path
Signed-off-by: hojooo <ghwn5833@gmail.com>
Add Rolling Policy
Signed-off-by: hojooo <ghwn5833@gmail.com>
hojooo
force-pushed
the
log4j2-rolling-policy
branch
from
2e0bb46 to
ec926ad
Compare
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
snicoll
added
status: waiting-for-feedback
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
Member
|
@hojooo can you please stop pushing one commit at a time like that? Every time you do, it sends a notification to everyone watching this repo, which adds quite a bit of noise. Please build locally and push once you're ready. |
Contributor
Author
|
@snicoll Thanks for the heads-up, and sorry for the noise I caused. I didn’t realize each small commit was sending notifications to everyone. I’ll make sure to build and test locally and then push in larger batches once things are ready. |
spring-projects-issues
added
status: feedback-provided
ppkarwasz
reviewed
Dec 2, 2025
Comment on lines
56
to
60
| private final TriggeringPolicy delegate; | ||
|
|
||
| private SpringBootTriggeringPolicy(TriggeringPolicy delegate) { | ||
| this.delegate = delegate; | ||
| } |
Contributor
There was a problem hiding this comment.
There is no need to implement a wrapper for a TriggeringPolicy. You can return the appropriate triggering policy directly from your factory method:
public abstract class SpringBootTriggeringPolicy implements TriggeringPolicy {
private SpringBootTriggeringPolicy() {
// no instantiation
}
public static TriggeringPolicy createPolicy(@PluginAttribute("strategy") @Nullable String strategy,
@PluginAttribute("maxFileSize") @Nullable String maxFileSize,
@PluginAttribute("timeInterval") @Nullable Integer timeInterval,
@PluginAttribute("timeModulate") @Nullable Boolean timeModulate,
@PluginAttribute("cronExpression") @Nullable String cronExpression,
@PluginConfiguration Configuration configuration) {
...
}
}Factory methods can return whatever they want (see MongoDbProvider), although there is a small limitation in the injector that assumes they return the same type as the plugin type, which is why SpringBootTriggeringPolicy needs to implement TriggeringPolicy.
Contributor
Author
There was a problem hiding this comment.
Thank you for the feedback! I agree this is a much cleaner approach. The wrapper pattern was adding unnecessary complexity when the factory can simply return the standard Log4j2 policies directly
Comment on lines
111
to
122
| @PluginBuilderFactory | ||
| public static SpringBootTriggeringPolicyBuilder newBuilder() { | ||
| return new SpringBootTriggeringPolicyBuilder(); | ||
| } | ||
|
|
||
| @PluginFactory | ||
| public static SpringBootTriggeringPolicy createPolicy(@PluginAttribute("strategy") @Nullable String strategy, | ||
| @PluginAttribute("maxFileSize") @Nullable String maxFileSize, | ||
| @PluginAttribute("timeInterval") @Nullable Integer timeInterval, | ||
| @PluginAttribute("timeModulate") @Nullable Boolean timeModulate, | ||
| @PluginAttribute("cronExpression") @Nullable String cronExpression, | ||
| @PluginConfiguration Configuration configuration) { |
Contributor
There was a problem hiding this comment.
There is no need for both a factory method and a builder. Since the builder is easier to maintain than the factory method, you should leave just the builder.
Comment on lines
45
to
46
| cleanHistoryOnStart="${sys:LOG4J2_ROLLINGPOLICY_CLEAN_HISTORY_ON_START:-false}" | ||
| totalSizeCap="${sys:LOG4J2_ROLLINGPOLICY_TOTAL_SIZE_CAP:-0}"/> |
Contributor
There was a problem hiding this comment.
The attributes cleanHistoryOnStart and totalSizeCap do not exist, see the DefaultRolloverStrategy documentation and the automatically generated list of configuration attributes. You would need to implement them in a custom rollover strategy:
- If you want to rollover at each JVM startup, you can use
OnStartupTriggeringPolicy, - If you want a limit on the total size of archived files, you need to configure the appropriate
Deleteactions.
Contributor
Author
There was a problem hiding this comment.
Thank you for the clarification. I've removed these non-existent attributes from DefaultRolloverStrategy.
I’ve removed those non-existent attributes from DefaultRolloverStrategy, so the configuration is now:
<DefaultRolloverStrategy max="${sys:LOG4J2_ROLLINGPOLICY_MAX_HISTORY:-7}"/>
To keep this change focused, I’m not wiring in OnStartupTriggeringPolicy or Delete actions yet.
If we need startup-based rollover or a total size cap in the future, we can follow up with a custom rollover strategy and Delete actions in a separate change.
Signed-off-by: hojooo <ghwn5833@gmail.com>
Signed-off-by: hojooo <ghwn5833@gmail.com>
snicoll
pushed a commit
to snicoll/spring-boot
that referenced
this pull request
Dec 10, 2025
See spring-projectsgh-47260 Signed-off-by: hojooo <ghwn5833@gmail.com>
snicoll
added a commit
to snicoll/spring-boot
that referenced
this pull request
Dec 10, 2025
snicoll
added
type: enhancement
Member
|
I am trying things a bit in a sample and with a size-based policy I am getting: @ppkarwasz is that a known issue? Can you please review |
Contributor
It wasn’t a known issue until now 😉. It looks like this happens when the Would you mind reporting this to our issue tracker?
Sure |
Member
|
Thanks very much, I've created apache/logging-log4j2#4001
This is our config It's the default that's applied in Spring Boot so if you have any suggestion to improve it, it is most welcome. |
ppkarwasz
reviewed
Dec 12, 2025
| </Policies> | ||
| <Policies> | ||
| <SpringBootTriggeringPolicy strategy="${sys:LOG4J2_ROLLINGPOLICY_STRATEGY:-size}" | ||
| maxFileSize="${sys:LOG4J2_ROLLINGPOLICY_MAX_FILE_SIZE:-10MB}" |
Contributor
There was a problem hiding this comment.
Log4j2 already supports configurable lookups, so using a Java system property (sys:) here seems unnecessary.
The Log4j2 Spring lookup reads values directly from the Spring Environment, avoiding additional logic.
This could be simplified to:
${spring:logging.log4j2.rollingpolicy.max-file-size}
A default can still be provided inline:
${spring:logging.log4j2.rollingpolicy.max-file-size:-10MB}
or via a <Property> element in the configuration file:
<Properties>
<Property name="logging.log4j2.rollingpolicy.max-file-size" value="10MB"/>
</Properties>
Member
There was a problem hiding this comment.
We don't want to read that value from the Environment. Our integration sets system properties using a configurable logic, so I'll keep that as it is
...g-boot/src/main/java/org/springframework/boot/logging/log4j2/SpringBootTriggeringPolicy.java
Show resolved
Hide resolved
...g-boot/src/main/java/org/springframework/boot/logging/log4j2/SpringBootTriggeringPolicy.java
Show resolved
Hide resolved
Comment on lines
+150
to
+153
| SpringBootTriggeringPolicyBuilder setStrategy(@Nullable String strategy) { | ||
| this.strategy = strategy; | ||
| return this; | ||
| } |
Contributor
There was a problem hiding this comment.
As @snicoll remarked, a package-private setter is not very useful.
Log4j Core injects configuration attributes into the element with the @PluginAttribute annotation: in this case the private fields.
Member
There was a problem hiding this comment.
OK. How do I test this? I am a bit confused where this is used as this code maps those values from the environment and, for that, we don't need the attributes.
Contributor
There was a problem hiding this comment.
I think it is worth testing the final effect that Environment variables have on the Log4j Core context.
It should be rather straightforward to retrieve the TriggeringPolicy from the LoggerContext returned by Log4J2LoggingSystem:
LoggerContext context = ...
Appender appender = context.getConfiguration().getAppender("File");
assertThat(appender).isInstanceOf(RollingFileAppender.class);
RollingFileAppender rollingFileAppender = (RollingFileAppender) appender;
TriggeringPolicy triggeringPolicy = rollingFileAppender.getTriggeringPolicy();If everything is wired right:
Environmentproperties will set up Java System properties,- Java System properties will be expanded in the
log4j2-file.xmlconfiguration file, - Log4j Core will use them to create the right
TriggeringPolicy.
Member
There was a problem hiding this comment.
That's not my question. How do I test something that would be set the PluginAttribute. Looking at how it's being used with our system properties-based arrangement, I don't see how/where the plugin attribute can be set. I've actually remove the @PluginAttribute-fields and it works fine but I am getting an error on startup:
ERROR SpringBootTriggeringPolicy contains invalid attributes "cronExpression", "timeModulate", "timeInterval", "maxFileSize", "strategy"
...src/main/java/org/springframework/boot/logging/log4j2/Log4j2RollingPolicySystemProperty.java
Show resolved
Hide resolved
...oot/src/main/java/org/springframework/boot/logging/log4j2/Log4j2LoggingSystemProperties.java
Show resolved
Hide resolved
...g-boot/src/main/java/org/springframework/boot/logging/log4j2/SpringBootTriggeringPolicy.java
Show resolved
Hide resolved
Member
|
@hojooo please don't proceed with the feedback as I have already modified the PR quite a bit. I'll take over. |
Contributor
I think this could be improved a bit: lookups This configuration should be better: <RollingFile name="File"
fileName="${sys:LOG_FILE}"
filePattern="${sys:LOG_PATH}/%d{yyyy-MM}/app-%d{yyyy-MM-dd-HH}-%i.log.gz"> |
Member
|
As part of this PR, we'd like to harmonize the default format to |
snicoll
pushed a commit
to snicoll/spring-boot
that referenced
this pull request
Dec 16, 2025
See spring-projectsgh-47260 Signed-off-by: hojooo <ghwn5833@gmail.com>
snicoll
added a commit
to snicoll/spring-boot
that referenced
this pull request
Dec 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello! Log4j2 does not support rolling policies. So this PR adds basic rolling policy configuration property support for Log4j2. It introduces Log4j2 specific properties equivalent to the existing
logging.logback.rollingpolicy.*properties, enabling consistent logging configuration through application.properties across different logging implementations.And advanced rolling strategy support to the Log4j2 rolling policy configuration. It introduces the
SpringBootTriggeringPolicyplugin to enable various rolling strategies and strategy-specific detailed configuration through application.properties.1. Standardized Log4j2 Rolling Policy Properties
We've added standard properties for Log4j2, similar to the existing
logging.logback.rollingpolicy.*properties. Users can now easily control the rolling policy using the following attributes inapplication.properties:2. Advanced Rolling Strategy
A custom Log4j2 plugin,
SpringBootTriggeringPolicy, has been introduced to support various advanced rolling strategies beyond simple size-based rolling.size(default): Rolls files based on their size.time: Rolls files based on a time interval.size-and-time: Rolls when both size and time conditions are met.cron: Rolls based on a cron expression schedule.