ppkarwasz commented on issue #3368: URL: https://github.com/apache/logging-log4j2/issues/3368#issuecomment-2575647116
> I am surprised to hear that these should _never_ be accessed programmatically? The opinions on this matter diverge in the PMC. We **agree** that the best way to modify a configuration is to create a new one and replace the old one. This prevents subtle bugs like adding an appender to a running configuration without previously starting it. We **do not** agree, which is the best way to create a new configuration: - @vy prefers to use the [Configuration Builder API](https://logging.apache.org/log4j/2.x/manual/customconfig.html#ConfigurationBuilder), which has the advantage of being equivalent to the file configuration. Since we didn't change the configuration format in 3.x, your code will be binary compatible with Log4j Core 3 too. If we remove some configuration attributes in 3.x, your code will still work, although the values of the attributes will be ignored (and cause warnings). - Personally I prefer to directly instantiate the plugins using the `Builder` classes, since it allows to provide the attributes in a type safe way instead of using `String`s as in the Configuration Builder API. This approach however needs code changes to migrate to Log4j Core 3, e.g. due to #1206. The choice is between binary compatibility between major releases and type safety. -- 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
