[
https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037914#comment-15037914
]
Paul Benedict edited comment on LOG4J2-435 at 12/3/15 3:33 PM:
---------------------------------------------------------------
It's a very interesting idea to use scripting. There is precedent for this
choice: Spring Expression Language and Java Unified Expression Language. Have
you guys just considered taking advantage of JUEL since most of your use cases
are in an EE container? (I am also pretty sure JUEL implementations can be used
outside the container too.) The {{javax.servlet.jsp.el}} package contains the
interface to pop in expressions for evaluation. If you guys provided a standard
{{LogStatusContext}} where the date, size, and other attributes could be
accessed, you could remove all the {{IfXXX}} variant tags and allow people to
directly write expressions.
Short example:
Presume that {{filename}}, {{daysOld}}, {{fileSizeGB}}, and {{fileCount}} are
context objects injected into the evaluator.
{code:xml}
<Delete basePath="${baseDir}/archives" maxDepth="2" condition="filename ~=
'*/app-*.log.gz' and daysOld >= 30 and (fileSizeGB >= 100 or fileCount >= 10)">
{code}
This to me is much more palatable than "tag soup" configuration. My point is to
drive expressions straight into your action/command tags. That's declarative,
straightforward, and easy to maintain.
was (Author: paul4christ79):
It's a very interesting idea to use scripting. There is precedent for this
choice: Spring Expression Language and Java Unified Expression Language. Have
you guys just considered taking advantage of JUEL since most of your use cases
are in an EE container? The {{javax.servlet.jsp.el}} package contains the
interface to pop in expressions for evaluation. If you guys provided a standard
{{LogStatusContext}} where the date, size, and other attributes could be
accessed, you could remove all the {{IfXXX}} variant tags and allow people to
directly write expressions.
Short example:
Presume that {{filename}}, {{daysOld}}, {{fileSizeGB}}, and {{fileCount}} are
context objects injected into the evaluator.
{code:xml}
<Delete basePath="${baseDir}/archives" maxDepth="2" condition="filename ~=
'*/app-*.log.gz' and daysOld >= 30 and (fileSizeGB >= 100 or fileCount >= 10)">
{code}
This to me is much more palatable than "tag soup" configuration. My point is to
drive expressions straight into your action/command tags. That's declarative,
straightforward, and easy to maintain.
> 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
