[
https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15006731#comment-15006731
]
Remko Popma commented on LOG4J2-435:
------------------------------------
Robert, thank you for a lot of thoughtful feedback! Let me go over your points
one by one.
*ISO8601 Duration*
I started out supporting years and months but threw that version out and
reverted to a Java 8-like Duration design without years or months. The problem
is that different months are different length. So all of a sudden the starting
point of the Duration becomes important. Supporting months/years also means the
implementation needs to remember the format; just tracking the number of
seconds is not enough. This would be significantly more work for hardly any
gain: I suspect most users want to clean up daily, perhaps every 7 days or
maybe every 30 days but probably not more infrequent, so larger units are not
that useful.
About the format: if users want to specify the full ISO8601 notation they can.
"P3dT12h" is interpreted correctly. However, in addition I also want to support
the simpler "30d" format because it is shorter and IMO more intuitive for users.
*Logical Grouping*
You are correct that the Delete may be configured to target different files
than those created by the rollover. I do not think this is a problem. My
intention was that the grouping expresses the _timing_ of the action rather
than the target files. So when nested in a DefaultRolloverStrategy, Delete
would be triggered by a rollover, whereas when Delete is nested in a Schedule
element (something that Ralph is working on), then it would be triggered by the
scheduler.
*Total File Size/Total File Count/Ordering*
Thanks for raising this! I had not considered these use cases. I agree that
ordering becomes important here and I had not considered that until now. I need
to think about this but I would like to support this.
About lastModified time: the {{java.nio.file}} API supports _custom_ file
systems which may not support lastModified time, but for "real" file systems I
think we can rely on this being supported and use this for ordering. That said,
a file list is an interesting idea. Are you proposing that users specify this
list in configuration? Could you give a simple example of what such a
configuration would look like?
> 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
