[
https://issues.apache.org/jira/browse/LOG4J2-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889193#comment-17889193
]
Jeff Thomas commented on LOG4J2-3691:
-------------------------------------
[~vy] -
We have a Client UI (Angular) which allows administration of multiple Tomcat
Instances (Applications).
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.
We have several applications which build on and extend each other - and can be
extended by customer projects - this works (for better or worse) via WAR
overlays so we end up with a hierarchy of Log4j configurations.
i.e. a composite configuration:
* product default generic log4j configuration (in WAR)
* product application-specific log4j configuration (in WAR)
* project-specific log4j configuration (in WAR)
* installation-specific log4j configuration (in external directory)
Changing an appender or logger would result in the new configuration being
written to the external directory and reloaded.
Previously the use-case was easier since there was no composite configuration
and the XML file in the external directory was complete and the only
configuration source (master). So we could just replace an XML element and
reload. However, this led to massive duplication in the configurations and the
problem of distributing new "product" configuration to "project" external
configuration.
There is a lot of Log4j functionality which we do not use heavily (or at all) -
we primarily only use RollingFileAppender, DefaultRolloverStrategy,
PatternLayout, and SizeBasedTriggeringPolicy. Although we don't restrict
anything - customer projects can configure as they wish.
(As a side note: we are also introducing Spring into the mix to provide a
central configuration @Service for the logging which should manage these
different configurations and provide a single-point of access for these admin
actions - previously everything was done over singletons.)
> 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)
