[
https://issues.apache.org/jira/browse/LOG4J2-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889534#comment-17889534
]
Volkan Yazici commented on LOG4J2-3691:
---------------------------------------
{quote}
Admin users (special role) could add appenders and loggers, persistently change
log-levels of both, etc. We primarily use rolling-file appenders so they could
modify maxFiles or the logfile rollover size, etc.
...
installation-specific log4j configuration (in external directory)
...
we primarily only use RollingFileAppender, DefaultRolloverStrategy,
PatternLayout, and SizeBasedTriggeringPolicy. Although we don't restrict
anything - customer projects can configure as they wish.
{quote}
[~JWT007], if your common configuration is pretty much the same, but only
varies on `maxFiles`, `logfile`, etc. what you can also consider implementing
is:
* Inject `maxFiles`, `logfile`, etc. via a custom `PropertySource` and allow
changing this `PS` in the admin UI. You can trigger a `Log4j#reconfigure()`
when the `PS` is updated, and so on.
* For more customization, accept a fully-blown Log4j configuration in a
`<textarea>`, upload this `log4j-admin-override.xml` to _the external
directory_, include it in the composite configuration, and
`Log4j#reconfigure()`.
> Documentation: CompositeTriggeringPolicy - nested <Policies> element?
> ---------------------------------------------------------------------
>
> Key: LOG4J2-3691
> URL: https://issues.apache.org/jira/browse/LOG4J2-3691
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Documentation
> Affects Versions: 2.24.0
> Reporter: Jeff Thomas
> Priority: Minor
>
> According to my JetBrains AI Assistant :):
> "According to the Log4j 2 configuration guidelines, nesting a {{Policies}}
> element within another {{Policies}} element is not supported. Each
> {{RollingFile}} appender should have one {{Policies}} element, which in turn,
> directly contains the individual policies."
> Example:
> {code:java}
> <RollingFile name="FILE"
> fileName="app.log"
> filePattern="app.%d{yyyy-MM-dd}.%i.log">
> <JsonTemplateLayout/>
> <Policies>
> <OnStartupTriggeringPolicy/>
> <Policies>
> <SizeBasedTriggeringPolicy/>
> <TimeBasedTriggeringPolicy/>
> </Policies>
> </Policies>
> </RollingFile> {code}
> I could not find an explicit statement regarding this in the new Log4j 2.x
> documentation.
> Also in the code of the `CompositeTriggeringPolicy` class it seems that there
> is no validation check to ensure that this does not happen.
> If this is in fact, undesirable maybe the documentation should state this and
> also enforce it in code (or alternatively aggregate the policies - flatten
> them to the top-level).
> Side note: the documentation and implementation don't mention adding multiple
> policies of the same type to a composite-policy (i.e. two
> "CronTriggeringPolicy" elements) - whether this is supported or actively
> discouraged.
> NOTE: The same question could be applied to the `CompositeFilter`constructor
> not checking if one of the provided filters is also a `CompositeFilter`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
