[logback-dev] [JIRA] Created: (LBCORE-242) log rollover should be configurable using %d multiple times in file name pattern

[Thomas Corte (JIRA)]

log rollover should be configurable using %d multiple times in file name pattern
--------------------------------------------------------------------------------

                 Key: LBCORE-242
                 URL: http://jira.qos.ch/browse/LBCORE-242
             Project: logback-core
          Issue Type: Improvement
          Components: Rolling
    Affects Versions: 1.0.0
            Reporter: Thomas Corte
            Assignee: Logback dev list


Trying to configure a log rollover with logs being *rolled daily* and put into a directory named "yyyy-MM", i.e. one folder for each *month* containing that month's logs, I'm using the following appender config:

{noformat}
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>app.log</file>

    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- rollover every minute -->
      <fileNamePattern%d{yyyy-MM}/app.%d{yyyy-MM-dd}.log</fileNamePattern>
    </rollingPolicy>

    <encoder>
      <pattern>%d{"yyyy-MM-dd HH:mm:ss,SSS"} [%thread] %-5level %logger{36} - %msg%n%xEx</pattern>
    </encoder>
  </appender>
{noformat}

However, it seems as if the current logback implementation merely considers the first %d specification, which leads to a log rotation only once per month instead of the desired once per day frequency.

I figure this is because via %d, the log rotation frequency and the file name pattern are somewhat tied together and seemingly can't be specified independently.

It would be nice if either multiple %d specifiers would be supported, with an option to specify which one should be considered for the rollover period.
Even better, it might be a good idea to support the rollover period to be specified separately and independently from the file name pattern; arguably, using the file name patterns for both is somewhat convenient, but violates the principle of "separation of concerns".


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira