vy commented on issue #3368: URL: https://github.com/apache/logging-log4j2/issues/3368#issuecomment-2577536744
> 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. :/ @JWT007, why do you have to do that by programmatically accessing the components, directly? If you have the initial, say, XML configuration, you can update the XML with the changed appends/loggers, feed it again to `Configurator.reconfigure()`. This way you will only be manipulating configuration files – the only API Log4j Core supports (besides Log4j API, obviously), AFAICT. > The choice is between binary compatibility between major releases and type safety. @ppkarwasz, Configuration Builder API (aka. the glorified DOM builder) is as type-safe as XML/YAML/JSON/Properties configurations files. I don't think type-safety is a tie breaker here. If it would be, we would have seen users asking for a type-safe logging configuration, and we don't. There is life-cycle related magic happening when a component gets realized from a configuration. Programmatically making that happen is walking on a minefield. I think the problem mostly emanates from a disagreement between maintainers on what is the API boundary for Log4j Core. For sure everyone agrees that the configuration file format is one such API – we shouldn't break it. What else? Shall we make `FileAppender` public too? Some users, even though they represent a tiny fraction of the total, will certainly find that helpful. But why do we stop there? What about `FileManager`, `AbstractManager`, and `OutputStreamManager` too? Those are handy too! My point is, if we want to accept `FileAppender` as a programmatically consumable public API of Log4j Core, we need to involve dozens and dozens more auxiliary support classes into that batch. This not only explodes the maintenance responsibility, severely hinders the evolution of the project. Mistakes will not be able to decently get corrected due to backward compatibility concerns. Since Log4j was invented at a time JPMS did not exist, now we treat everything public in Log4j Core as an A PI surface. It is at such a bad level, some maintainers even insist we should include test modules (e.g., `log4j-core-test`) in that group too. Can you pause for a second an try to grasp the API surface supported by 2 F/OSS developers in their spare time? In overall, I don't know if Log4j 3, 4, 5, etc. will support `org.apache.logging.log4j.core.util.Builder`. Though I know they all will support the XML configuration file you have today. -- 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
