JWT007 commented on issue #3368: URL: https://github.com/apache/logging-log4j2/issues/3368#issuecomment-2573834639
I am surprised to hear that these should *never* be accessed programmatically? We have been doing this for years to create dynamic runtime-only appenders and loggers - since Log4j 1.x. Since Log4j 2.x we have a CompositeConfiguration with a nestted custom runtime-configuration for these runtime only service-appenders/loggers. The *new* Log4j 2.x docs also clearly state "Log4j Core can be configured programmatically too." The warning you are referring to is probably this one: "We strongly advise against programmatically modifying components of a configuration! This section will explain what it is, and why you should avoid it." - but this would not be directly relevant to calling the builder methods. Unfortunately in our case we have an old legacy monolilth which provided admin functions to add/remove/update loggers/appenders - functionality the users don't want to give up :( - and since the Log4j configuration objects cannot be used to recreate an XML file from an existing configuration - we have had to get ... creative. :/ Also the Log4j Plugin concept sort of breaks down in many spots because many other configuration classes are final , have private attributes, or have package-private functionality, (i.e. providing an alternate "BurstFilter" implementation - trivial example). O_o -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
