Log4j2 Rolling appender - fileName “sliding” according to pattern

Question

I am looking for rollover strategy where current log ( active output target in manual 's terminology) file name is not fixed but specified by a pattern, or - more precisely - same pattern as in filePattern attribute.

I want to achieve daily rollover where today's log is, say, log-2015-05-05.log and on midnight framework just stops writing it and starts writing into log-2015-05-06.log . However, AFAIK, current configuration allows only

<RollingFile name="ROLFILE"
    fileName="log.log"
    filePattern="log-%d{yyyy-MM-dd}.log"
>

Specifying same value into fileName attribute doesn't work (leads to file with sensitive characters literally interpreted). I noticed no example or SO question with such a dynamic value of fileName . Note the fileName="log-${date:yyyy-MM-dd}.log" doesn't solve problem since expression is evaluated only at startup and events are still sent into file even if their timestamp doesn't match the expression.

I am migrating from Log4j 1.2 to Log4j 2.2. In old version, required behavior was possible using

<appender name="ROLFILE" class="org.apache.log4j.rolling.RollingFileAppender">
    <rollingPolicy class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
        <param name="FileNamePattern" value="log-%d{yyyy-MM-dd}.log" />
    </rollingPolicy>
    ...

I prefer to preserve current way since some log analyzing tools rely on it. Is it possible in Log4j2? Thanks.

Answer 1

Note sure if this works, but you can try using a double $$ in the date lookup. This allows the variable to be resolved at runtime.

<RollingFile name="ROLFILE"
    fileName="log-$${date:yyyy-MM-dd}.log"
    filePattern="oldlog-%d{yyyy-MM-dd}.log"
>

You may need to be careful to ensure that the active output target file name is different from the after-rollover file name. (I used 'oldlog' in the snippet above.)

Answer 2

Finally, I wrote my own rollover strategy which generates different set of rollover actions. Instead renaming active file the active file name is simply replaced inside RollingFileManager . Yes, it's ugly reflection hack and also appender must be initialized with fileName constant corresponding with current date and having same pattern, eg

<RollingFile name="ROLFILE"
    fileName="log-${date:yyyy-MM-dd}.log"
    filePattern="log-%d{yyyy-MM-dd}.log"
>
    <SlidingFilenameRolloverStrategy />
    ...

yet for me this solution is worth doing it despite these small drawbacks. (Initial fileName stays forever as a key in AbstractManager registry MAP even if in manager itself it has been changed - seems it doesn't mind, I also tried replacing manager in registry for new one but it's impossible to collect all parameters necessary for its construction.)

I hope this hack shouldn't have been so ugly if RollingFileManager API made it possible normal way. I got some hope seeing this javadoc but framework AFAIK never utilizes this field, let alone for mutating RollingFileAppender .

Answer 3

I think it would work just fine using:

 fileName="log-${date:yyyy-MM-dd}.log"
 filePattern="log-%d{yyyy-MM-dd}.log"

I use it with log4j2 version 2.5

Answer 4

This has been implemented in Log4j 2.8 (see issue LOG4J2-1101 ).

Currently it only works with a RollingFile appender by omitting the filename parameter and using a DirectWriteRolloverStrategy .

Also, this feature seems to have some issues with the TimeBasedTriggeringPolicy (the first rollover doesn't happen so every logfile is offset by one interval); CronTriggeringPolicy works properly.

Example config:

<RollingRandomAccessFile name="MyLogger"
    filePattern="logs/application.%d{yyyy-MM-dd}.log">
    <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
    <Policies>
        <CronTriggeringPolicy schedule="0 * * * * ?" evaluateOnStartup="true"/>
    </Policies>
    <DirectWriteRolloverStrategy/>
</RollingRandomAccessFile>

Support for RollingRandomAccessFile appender is requested in issue LOG4J2-1878 .

Edit: Changed to CronTriggeringPolicy policy after finding TimeBasedTriggeringPolicy had issues.