[ 
https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005532#comment-15005532
 ] 

Remko Popma edited comment on LOG4J2-435 at 11/15/15 11:33 AM:
---------------------------------------------------------------

(Following up on my previous comment)

"File" will be confused with the FileAppender, so I am changing it to 
"FileNameFilter". For consistency I will also rename LastModified to 
LastModifiedFilter.
----
Integration of custom actions with RollingFileAppender is probably best done in 
the {{DefaultRolloverStrategy}}, since that class is responsible for creating 
the rename and compress actions.

Custom actions nested in a <DefaultRolloverStrategy> element will be executed 
asynchronously after the rename actions.

Example configuration putting it all together:
{code}
<RollingFile name="RollingFile" fileName="${sys:user.home}/logs/app.log"
             
filePattern="${sys:user.home}/logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz">
  <PatternLayout>
    <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
  </PatternLayout>
  <Policies>
    <TimeBasedTriggeringPolicy />
    <SizeBasedTriggeringPolicy size="250 MB"/>
  </Policies>
  <DefaultRolloverStrategy stopCustomActionsOnError="true">
    <!-- custom action executed asynchronously after the rollover -->
    <Delete basePath="${sys:user.home}/logs" maxDepth="2" followLinks="false">
      <And>
        <FileNameFilter path="*/app-*.log.gz" /> <!-- delete only files 
matching this pattern -->
        <LastModifiedFilter duration="7d" /> <!-- delete if 7 days or older -->
      </And>
    </Delete> 
  </DefaultRolloverStrategy>
</RollingFile>
{code}

If no objections I will commit this to master tomorrow.

Question:
Now that we will make Actions a public API and document how users can provide 
custom filters and custom actions, is the current package still the best name? 
At the moment Actions are only used internally as "helper" classes for a 
rollover, so until now the 
{{org.apache.logging.log4j.core.appender.rolling.action}} package was 
appropriate, but now that Actions are becoming first-class citizens, I propose 
we rename this package to {{org.apache.logging.log4j.core.action}}. Thoughts?


was (Author: rem...@yahoo.com):
(Following up on my previous comment)

Integration of custom actions with RollingFileAppender is probably best done in 
the {{DefaultRolloverStrategy}}, since that class is responsible for creating 
the rename and compress actions.

Custom actions nested in a <DefaultRolloverStrategy> element will be executed 
asynchronously after the rename actions.

Example configuration putting it all together:
{code}
<RollingFile name="RollingFile" fileName="${sys:user.home}/logs/app.log"
             
filePattern="${sys:user.home}/logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz">
  <PatternLayout>
    <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
  </PatternLayout>
  <Policies>
    <TimeBasedTriggeringPolicy />
    <SizeBasedTriggeringPolicy size="250 MB"/>
  </Policies>
  <DefaultRolloverStrategy stopCustomActionsOnError="true">
    <!-- custom action executed asynchronously after the rollover -->
    <Delete basePath="${sys:user.home}/logs" maxDepth="2" followLinks="false">
      <And>
        <File path="*/app-*.log.gz" /> <!-- delete only files matching this 
pattern -->
        <LastModified duration="7d" /> <!-- delete if 7 days or older -->
      </And>
    </Delete> 
  </DefaultRolloverStrategy>
</RollingFile>
{code}

If no objections I will commit this to master tomorrow.

Question:
Now that we will make Actions a public API and document how users can provide 
custom filters and custom actions, is the current package still the best name? 
At the moment Actions are only used internally as "helper" classes for a 
rollover, so until now the 
{{org.apache.logging.log4j.core.appender.rolling.action}} package was 
appropriate, but now that Actions are becoming first-class citizens, I propose 
we rename this package to {{org.apache.logging.log4j.core.action}}. Thoughts?

> Feature request: auto-delete older log files 
> ---------------------------------------------
>
>                 Key: LOG4J2-435
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-435
>             Project: Log4j 2
>          Issue Type: Improvement
>            Reporter: Arkin Yetis
>            Assignee: Remko Popma
>              Labels: Rollover
>             Fix For: 2.5
>
>         Attachments: LimitingRolloverStrategy.java, SizeParser.java
>
>
> Original description:
> {quote}
> DefaultRolloverStrategy max attribute only applies if you have a %i in the 
> file pattern. This request is to enhance DefaultRolloverStrategy or another 
> appropriate component to allow a max number of files limit to apply across 
> days/months/years when a filePattern includes a date pattern.
> {quote}
> ----
> One of the most requested features is to add the ability to Log4j to "clean 
> up" older log files.  This usually means deleting these files, although it 
> could also mean moving them to a different location, or some combination of 
> these. 
> Users have different requirements for selecting the files to clean up. A 
> common request is the ability to keep the last X number of log files. This 
> works well if rollover is only date based but may give undesired results with 
> size based rollover. 
> Another factor to consider is that the directory containing the log files may 
> contain the log files for multiple appenders, or even files unrelated to 
> logging. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to