Add Log4j2 rolling policy configuration

[hojooo]

Summary

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 SpringBootTriggeringPolicy plugin to enable various rolling strategies and strategy-specific detailed configuration through application.properties.

Changes

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 in application.properties:

# Basic rolling policy configuration (file size, history, etc.)
logging.log4j2.rollingpolicy.max-file-size=10MB
logging.log4j2.rollingpolicy.max-history=7
logging.log4j2.rollingpolicy.total-size-cap=1GB
logging.log4j2.rollingpolicy.clean-history-on-start=false

# Rolled file name pattern configuration
logging.log4j2.rollingpolicy.file-name-pattern=${LOG_FILE}.%d{yyyy-MM-dd}.%i.gz

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.

Implementation

1. Property Standardization Implementation

• Log4j2RollingPolicySystemProperty: An enum was implemented to map Spring Environment properties to system properties that Log4j2 can recognize (e.g., max-file-size -> LOG4J2_ROLLINGPOLICY_MAX_FILE_SIZE).
• Log4j2LoggingSystemProperties: This class handles the automatic conversion of Spring's DataSize type to bytes and ensures backward compatibility with deprecated properties like logging.file.max-size.
• log4j2-file.xml: The configuration file was updated to reference the newly defined system properties using the ${sys:PROPERTY_NAME} syntax.

2. Advanced Rolling Strategy Implementation

• SpringBootTriggeringPolicy Plugin: A custom TriggeringPolicy was implemented using Log4j2's @Plugin annotation. Based on the strategy property, this plugin internally selects and delegates to the appropriate policy (e.g., SizeBasedTriggeringPolicy, TimeBasedTriggeringPolicy).
• log4j2-file.xml Update: The <Policies> block was modified to use SpringBootTriggeringPolicy, with its parameters (maxFileSize, timeInterval, cronExpression, etc.) configured via system properties.

[snicoll]

@hojooo can you please rebase this PR to main and squash everything in one commit? Once you're done, running the build to make sure it passes would be appreciated.

@ppkarwasz would you have a min to review this one please? I am wondering, in particular, about SpringBootTriggeringPolicy that has to do quite a bit that looks unrelated to what a plugin should do (lifecycle management, etc).

[hojooo]

@snicoll Got it, thanks. I’ll update the PR shortly.

[snicoll]

@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.

[hojooo]

@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.

[ppkarwasz]

@snicoll,

From a Log4j point of view, this PR looks overall correct, although it could be simplified and there are some smaller issues.

[ppkarwasz]

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.

[hojooo]

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

[ppkarwasz]

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.

[ppkarwasz]

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 Delete actions.

[hojooo]

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.