[
https://issues.apache.org/jira/browse/LOG4J2-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Thomas updated LOG4J2-3691:
--------------------------------
Description:
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
"CronTriggeringPolicies") - whether this is supported or actively discouraged.
was:
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).
> 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
> "CronTriggeringPolicies") - whether this is supported or actively discouraged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
