Hi Jay,
On 23.01.2025 06:15, Jay Katariya wrote:
Before I start the discussion here, I want to mention I am a Log4j newbie
contributor, and don't know feature requests etc work, and what is a good
feature vs what is not a good feature to take into account.
The main question you have to ask yourself is: are you willing to
support the feature for 5 or 10 years? How many users will the feature
have? A great examples of the maintenance problems you can encounter is
the NetRexxC task[1] in Apache Ant. Nobody is using it, its dependencies
are not available on Maven Central, but the Apache Ant team has been
maintaining it for around 25 years.
Note that as a rule we don't drop features. If possible we add a
configuration option to disable a feature and (possibly) disable the
feature by default. There is however a thin line between features and
bugs, so the bug reported in LOG4J2-905[2] was initially classified as
feature, but ended being one of worst bugs of all times.
The problem with many features is that they might initially look great,
but they can age poorly. The user that requested them might realize
after a couple of months that there is a better and more standard way to
achieve the same result. This is why currently we follow this procedure:
1. Unless there is a consensus that a feature will be a popular one,
additional Log4j components are created as personal/company projects
first. Personally I also have one project in this phase too[3]. Feel
free to ask other Log4j committers to review the code and mention the
component in our documentation. For legal reasons the component must be
in a "Third-party components" section like we did for lookups[4]. We
should probably also announce these plugins on our social media.
2. If you see that the project becomes popular (GitHub stars, issue
reports, etc.) submit it as PR to Log4j. In my experience if a code is
not used enough, it is buggy. An issue report or feature request is an
indication that someone tested your code (maybe even in production).
Some companies have a policy against single-maintainer projects, for
example they refused to use Eduard's Log4j plugin descriptor merger[4]
until it became an official Log4j module.
Piotr
[1] https://ant.apache.org/manual/Tasks/netrexxc.html
[2] https://issues.apache.org/jira/browse/LOG4J2-905
[3] https://oss.copernik.eu/#ramp-up
[4] https://logging.apache.org/log4j/2.x/manual/lookups.html#third-party
[4]
https://github.com/edwgiz/maven-shaded-log4j-transformer?tab=readme-ov-file
