[
https://issues.apache.org/jira/browse/LOG4J2-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889162#comment-17889162
]
Jeff Thomas edited comment on LOG4J2-3691 at 10/14/24 10:16 AM:
----------------------------------------------------------------
Hi [~pkarwasz] , ok thanks for the clarification :) if it is allowed then there
is no problem (unfortunately the AI is not perfect yet).
I am not really having a problem - I created the ticket to *possible* point out
a discrepancy/omission.
A little backstory. Our application has a web-client which historically with
Log4j 1.x permitted changing the XML server-configuration on the fly -
rewriting and reloading it.
With Log4j 2.x this became more difficult.
* Not all XML attributes are discoverable in the runtime Log4j core
configuration objects
** some fields are simply private with no public API to query them
** some attributes have been merged used to create other objects but are not
stored in their "original" form and cannot be queried
** in other cases, invalid values in the original configuration are silently
logged (no exceptions) and replaced with default values - so it is not possible
to get the original values.
* Additionally we are taking advantage of the composite configuration now to
provide a hierarchy of log4j configuration sources
Apparantly our admin users love this functionality and don't want to go without
it :)
So to retain the functionality in our application of being able to change the
persistent XML configuration I am trying to create simple holder-beans for the
configuration read from the XML (reading them from a custom
XMLConfigurationFactory) and using a "toLog4jConfiguration" method to generate
a valid Configuration at runtime. (Hopefully that makes sense). This should
allow me to query the original XML values, modify them, and reserialize from my
light-weight configuration back to XML and also regenerate a valid
Configuration at any time from this structure.
Its a lot of "wrapper" code around the Log4j Configuration but I couldn't come
up with any other good way to fulfill the requirement - (and I hope it doesn't
break too much when Log4j 3.x rolls around) :/
Also with this approach, I *hope* I am adhering to the warning about directly
editing the configuraton directly. Instead I regenerate a new configuration on
demand and refresh everything.
{quote}"{*}We strongly advise against programmatically modifying components of
a configuration!{*}."
{quote}
As a result, I am looking very closely at the Log4j configuration classes and
their documentation - so this question came up for me and in case it was an
error or should be documented more precisely I created the ticket.
I did have one other *thought* about the Log4j Plugin concept... apparently it
should be possible to for example create a custom *Plugin* for a _Logger_ with
a lower *@Order* and override the default functionality; however since all the
configuration objects are final there is no real use-case there - so I can't
just provide a custom _Logger_ implementation which keeps all the original
attributes as provided to the Builders as I cannot extend the base-logger.
Plus in some builders the attributes are conflated to other objects before
being passed to the constructors.
was (Author: jwt007):
Hi [~pkarwasz] , ok thanks for the clarification :) if it is allowed then there
is no problem (unfortunately the AI is not perfect yet).
I am not really having a problem - I created the ticket to *possible* point out
a discrepancy/omission.
A little backstory. Our application has a web-client which historically with
Log4j 1.x permitted changing the XML server-configuration on the fly -
rewriting and reloading it.
With Log4j 2.x this became more difficult.
* Not all XML attributes are discoverable in the runtime Log4j core
configuration objects
** some fields are simply private with no public API to query them
** some attributes have been merged used to create other objects but are not
stored in their "original" form and cannot be queried
** in other cases, invalid values in the original configuration are silently
logged (no exceptions) and replaced with default values - so it is not possible
to get the original values.
* Additionally we are taking advantage of the composite configuration now to
provide a hierarchy of log4j configuration sources
Apparantly our admin users love this functionality and don't want to go without
it :)
So to retain the functionality in our application of being able to change the
persistent XML configuration I am trying to create simple holder-beans for the
configuration read from the XML (reading them from a custom
XMLConfigurationFactory) and using a "toLog4jConfiguration" method to generate
a valid Configuration at runtime. (Hopefully that makes sense). This should
allow me to query the original XML values, modify them, and reserialize from my
light-weight configuration back to XML and also regenerate a valid
Configuration at any time from this structure.
Its a lot of "wrapper" code around the Log4j Configuration but I couldn't come
up with any other good way to fulfill the requirement - (and I hope it doesn't
break too much when Log4j 3.x rolls around) :/
Also with this approach, I *hope* I am adhering to the warning about directly
editing the configuraton directly. Instead I regenerate a new configuration on
demand and refresh everything.
{quote}"{*}We strongly advise against programmatically modifying components of
a configuration!{*}."
{quote}
As a result, I am looking very closely at the Log4j configuration classes and
their documentation - so this question came up for me and in case it was an
error or should be documented more precisely I created the ticket.
> 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)
