I created the docker and Kubernetes modules. Originally my employer used them when sending data directly via TCP to a forwarder. However, we ran into reliability issues with the forwarder when doing that so we switched to writing to the console, despite benchmarks showing it is slower. But for anyone implementing something that avoids those issues this would be very relevant. By archiving this we are basically telling users that they cannot use it any more since it will no longer be supported. For that reason I am not in favor of that for these two components.
Ralph > On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > Hi all, > > We always strive to only release industrial-strength components. > > Following an internal discussion and looking at statistics from > several sources, the PMC plans to deprecate in the 2.x version several > components for removal in 3.x. > > We know that statistics are not everything and that is why we would > like to hear your opinion on these modules. The discussion will be > open for a month, after which the PMC will announce a definitive list > of deprecations. > > ## `log4j-cassandra`: > We support Cassandra 3.x. This release will reach end-of-life when > 4.2.x is released[1]. Since the stats show marginal usage of the > module, there should be no `log4j-cassandra4`. > > ## CouchDB appender: > It is even less used than Cassandra according to the stats. > > ## `log4j-docker` > Seldom used and standard practice is generally to log to the > console and let the Docker environment add the data. > > ## GELF appender: > It is mostly superseded by `JsonTemplateLayout`. > > ## Kafka appender: > It contains several critical bug reports neither the PMC, nor the > community is willing to deal with. > > ## `log4j-kubernetes`: > Seldom used and standard practice is generally to log to the > console and let the Docker environment add the data. > > ## JeroMQ appender: > Since version 2.6 it had only one PR/bug report and it was from > PAX Logging maintainer. There is an alternative from a ZeroMQ > maintainer[2], Fabrice Bacchella, that provides important features > like encryption or choice of socket type. > > ## JNDI-related features: > JNDI is an old technology from the times of ponies and unicorns, > when nobody cared about security. The Error Prone team decided to mark > JNDI usage as error by default[3]. > > ## `log4j-jpa`: > Has marginal downloads and requires a migration to Jakarta EE. I > think that `log4j-jdbc` (which is also seldom used) provides a good > alternative for SQL databases, > > ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout) > We already provide `JsonTemplateLayout`; `XmlLayout` is seldom > used and `YamlLayout` as far as we know is not be used at all. > > ## `log4j-mongodb3`: > Support for MongoDB 3.x ended two years ago. > > ## `log4j-spring-boot`: > Its features are included in Spring Boot 3.x. > > ## SMTP appender: > Its usage is at the bottom of the stats. > > ## `log4j-taglib` > Also needs a Jakarta version, but it is based on a legacy > technology that is currently seldom used. > > Waiting to hear your opinions, > Piotr > > [1] > https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html > [2] https://github.com/fbacchella/loghublog4j2 > [3] https://errorprone.info/bugpattern/BanJNDI > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
