I would be in favor of deprecating the following modules in `2.x` and dropping them starting from `3.0.0`:
1. `log4j-jndi` (available only in `main`) – nobody should use JNDI anyway 2. `log4j-layout-jackson*` – `JsonTemplateLayout` succeeds `JsonLayout`, I doubt if anybody is using `XmlLayout`, nobody should use `YamlLayout` anyway 3. `log4j-gelf` (available only in `main`) – JTL offers the same functionality, we just need to add a `CompressingLayout` (see LOG4J2-3023) and a resolver template (i.e., `gelf.json`) 4. `log4j-jms` (available only in `main`) 5. `log4j-csv` (available only in `main`) 6. `log4j-jeromq` 7. `log4j-cassandra` 8. `log4j-smtp` 9. `log4j-jakarta-smtp` 10. `log4j-couchdb` 11. `log4j-taglib` 12. `log4j-mongodb3` 13. `log4j-spring*` – we should try to upstream these to Spring Boot, otherwise to their own `apache/logging-*` repository 14. `log4j-jdbc` 15. `log4j-kafka` – we should either hand this out to the community or, if not rewrite, revamp it. In its current state <https://issues.apache.org/jira/browse/LOG4J2-3173?filter=-2&jql=project%20%3D%20%22Log4j%202%22%20AND%20status%20%3D%20Open%20AND%20text%20~%20kafka>, it doesn't appear to be of production-grade quality. For the records, Romain Manni-Bucau created LOG4J2-1650 <https://issues.apache.org/jira/browse/LOG4J2-1650> for a similar "diet". That was in 2016, since then things got sadly worse. We don't need to have a very strong consensus. As long as we have a proposal draft that everybody _roughly_ agrees on, we can announce this in every public medium we can think of (`dev@community`, `log4j-user@logging`, `dev@logging`, ASF planet, Twitter, etc.) and decide on the actual "cut" based on the feedback received. I don't want to derail the conversation at this stage, though I need to admit I have my reservations regarding the "please don't drop it because my employer uses it" argument. We can, preferably after the public feedback deadline, talk about it. On Sat, Sep 9, 2023 at 9:16 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi all, > > In a Slack discussion Volkan proposed (among other things) to: > > * raise the Java requirements in 3.x to Java 17. It is the same > requirement as Spring Boot 3.x has, so I don't see a reason to lower > the bar. Besides Java 21 will be an LTS. > * deprecate some modules in 2.x and drop them in 3.0.x, restore them > if a user requests it in 3.1.x. > > While the number of downloads is not the only criterium (a big company > with an internal Maven repo counts 1, a student's project that tries > multiple version counts more), these are the stats for last month: > > 1 log4j-bom 35178445 > 2 log4j-api 30598923 > 3 log4j-core 15567816 > 4 log4j-to-slf4j 14036879 > 5 log4j-slf4j-impl 8675173 > 6 log4j-1.2-api 3454601 > 7 log4j-jul 2120049 > 8 log4j-web 1964937 > 9 log4j-layout-template-json 1760437 > 10 log4j-slf4j2-impl 1013605 > 11 log4j-jcl 566636 > 12 log4j-appserver 245029 > 13 log4j-iostreams 209990 > 14 log4j-spring-boot 87578 > 15 log4j-spring-cloud-config-client 38332 > 16 log4j-jakarta-web 37351 > 17 log4j-jpl 20295 > 18 log4j-flume-ng 14055 > 19 log4j-taglib 13989 > 20 log4j-couchdb 12781 > 21 log4j-mongodb4 4623 > 22 log4j-kubernetes 2618 > 23 log4j-jpa 1252 > 24 log4j-mongodb3 1143 > 25 log4j-docker 1122 > 26 log4j-cassandra 898 > 27 log4j-jakarta-smtp 741 > 28 log4j-jdbc-dbcp2 708 > 29 log4j-to-jul 297 > > I propose to have a bar at 100k, so we keep everything up to > `log4j-iostreams` + some modules under the line that are deemed > important. > > I would keep `log4j-to-jul`, mainly because it is a third > implementation of the Log4j API and I used it at work, when I didn't > get the permission to use Log4j Core. NB: the `2.x` version of > `log4j-to-jul` will still work with the `3.x` version of `log4j-api`, > but it might require a modularized version to be fully compatible. > > The stats of `log4j-appserver` are unexpected. I guess the Jetty 9.x > support drives it (Jetty 9.x reached EOL) more than the Tomcat > support. So we could even deprecate this one and create a > `log4j-tomcat` module or drop it entirely (I will pick up the Tomcat > part in my `eu.copernik` modules). > > Piotr > > PS: The downloads of the 3.x modules split from `log4j-core` are not > that great either. In the third column I renormalize them so that > `log4j-core` has 15M downloads: > log4j-core 78627 15567816 > 1 log4j-jdbc 55 10890 > 2 log4j-layout-jackson 55 10890 > 3 log4j-jndi 44 8712 > 4 log4j-script 44 8712 > 5 log4j-kafka 40 7920 > 6 log4j-jms 39 7722 > 7 log4j-csv 38 7524 > 8 log4j-jeromq 37 7326 > 9 log4j-smtp 37 7326 > 10 log4j-layout-jackson-json 33 6534 > 11 log4j-layout-jackson-xml 30 5940 > 12 log4j-layout-jackson-yaml 24 4752 >
