[
https://issues.apache.org/jira/browse/LOG4J2-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889189#comment-17889189
]
Jeff Thomas commented on LOG4J2-3691:
-------------------------------------
Hi [~ppitonak] thanks for the feedback! :)
In my implementation, the only @Plugin override is in fact the
XMLConfigurationFactory to generate my lightweight configuration beans and use
those to create a Configuration. As mentioned above, it was not possible for
me to provide custom @Pluign implementations for the actual Log4j configuration
components. But I will try and take a look at the log4j-docgen.
The `toBuilder()` method sounds interesting :) I hope something happens there!
It would probably only refect the interpreted configuration and not the
original XML representation right? By that I mean some builders return `null`
if the element is misconfigured or assume defaults.
> 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)
