ppkarwasz commented on issue #3368:
URL:
https://github.com/apache/logging-log4j2/issues/3368#issuecomment-2589122422
> 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
API 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?
Basically we don't consider those classes as part of the API, but we don't
introduce breaking changes in it either. :wink:
Sure, if we were to write Log4j 2 today, most of the Log4j plugins
(`FileAppender`, etc.) would be internal classes.
> For example, this will throw NPEs (trying to represent an undefined
onResult/onMismatchResult).
>
> ```
> var filterBuilder =
> configBuilder.newFilter("BurstFilter",
> (Filter.Result) null,
> (Filter.Result) null);
> ```
This is a known bug (#2791 and
[LOG4J2-3453](https://issues.apache.org/jira/browse/LOG4J2-3453)). In general
the Configuration Builder API has many bugs such as this, because it is rarely
used. Its main usage is the Java properties configuration format that nobody on
the dev team uses.
Thanks for auditing it.
--
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
