[
https://issues.apache.org/jira/browse/LOG4J2-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889626#comment-17889626
]
Jeff Thomas commented on LOG4J2-3691:
-------------------------------------
Hi [~vy] - thanks for the suggestions :)
We have *many* appenders and also project-specific appenders that customer
projects define outside of our control - so there is unfortunately no one-size
fits all for maxFiles etc.
The full-XML editing is how we *used* to do it... but #1 the admin users don't
want to edit XML :/ and #2 if we write the full-blown XML to the external
directory we "freeze" all product changes to those appenders/loggers which have
not been intentionally changed on the project side.... the external config
would override all changes to the defaults. With the composite-configuration
we are *hoping* to only have config in the external config which really
extends/modifies the defaults. So, instead of 50 Appenders only 4 for example.
We just today had the problem where we in our last major update switched from
Log4j 1.x to 2.x and in the splitting of the configuration into different
hierarchical config files renamed our appenders to be consistent - i.e.
"RootAppender" instead of "root". The default "RootLogger" now references
"RootAppender"
So our customer migrating to the new version took his old Log4j config and
copy/pastes schwuppdiwupp in the external config with "RootLogger" also having
a ref to the old "root" appender - and lo and behold suddenly every log message
is now being logged 2x. :/
> 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)
