[
https://issues.apache.org/jira/browse/LOG4J2-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889196#comment-17889196
]
Piotr Karwasz commented on LOG4J2-3691:
---------------------------------------
{quote}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.{quote}
I am afraid nothing will happen automatically, since our backlog of new
features is enough for a lifetime. If you find the idea useful, you should
start a thread on [dev@logging mailing
list|https://logging.apache.org/support.html#discussions-maintainer].
Personally I would like to see the project go into that direction, but I don't
have the time to work on it now. From what I understand you are starting a big
migration task from Log4j 1 to Log4j 2. Contributing some of that work back to
the Log4j Project might save you some time. Not all new features are accepted
in the Log4j codebase, but the `toBuilder()` feature probably would be accepted.
PS: Any configuration file that comes from a runtime configuration, will only
contained the resolved value of the {{${...}}} property substitution
placeholders. Maybe a better way to get the current configuration is to get the
original configuration file through JMX or
[Configuration.getConfigurationSource()|https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/config/Configuration.html#getConfigurationSource()].
> 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)
