[ 
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 
"CronTriggeringPolicy" elements) - 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).

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.


> 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.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to