It has been my plan to create a PR for Spring to move the Spring Boot support there. They already provide support for Log4j2, it is just deficient.
I have no plans to move the Flume Appender to the Flume project. However, I do plan to move it to its own Log4j repo in 3.x. I would suggest the same thing happen to many of these other components. Other projects taking ownership of them is very unlikely to happen. Ralph > On Jun 10, 2022, at 5:51 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > Would any of those projects be willing to maintain a Log4j-related > component that was born and raised in the Log4j land? I think that is > pretty wishful thinking, though feel free to give it a try. I support any > initiative that would lower the maintenance burden without hindering the > development of Log4j. Does anybody volunteer to raise this subject in the > associated mailing lists? > > I am not concerned about the `log4j-core` API stability, I think we do a > good job there. > >> ... if the upstream projects don't want them, then those modules get > EOL'd and removed for 3.x > > Umm... I don't think that is a nice way to treat our existing users. (Ralph > would disagree anyway. In fact, I am surprised he hasn't reacted yet.) I > would rather move these to separate repositories and maintain them there. > For those interested in this route, please start another thread. For > inspiration, see my earlier posts > <https://lists.apache.org/thread/8rflqfctmpd79h11o78zkfymtn6g9sds>. > > On Tue, Jun 7, 2022 at 8:17 PM Matt Sicker <boa...@gmail.com> wrote: > >> Hey all, >> >> I was wondering if you'd all be on board for 3.x to try and move some >> of our 3rd party integration plugins to their respective projects >> rather than maintaining them here. For example, all the networked >> appender plugins and other plugins that typically require a third >> party client library or driver would be more appropriately located >> with their respective dependencies. A concrete example would be moving >> the Flume appender to Apache Flume once they're finished with 1.10.0 >> which is under review right now. While we'd keep releasing this >> appender in 2.x, come 3.x, we'd be able to point to the official Flume >> plugin instead. The same idea could apply to numerous plugins such as: >> >> * Cassandra appender -> Apache Cassandra >> * Flume appender -> Apache Flume >> * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?) >> * JMS appender (could go to ActiveMQ or Jakarta) >> * Kafka appender -> Apache Kafka >> * MongoDB appenders -> MongoDB? >> * CouchDB appenders -> Apache CouchDB >> * SMTP appender -> makybe Jakarta? >> * ZeroMQ appender -> ZeroMQ project? >> * Spring integration stuff -> Spring project >> * Liquibase binding -> Liquibase >> >> I imagine it makes some sense to continue publishing our -web and >> -appserver modules as they're more specific to hooking log4j-core into >> those things, but I'm open to other ideas there. >> >> For any plugins we're trying to move, if the upstream projects don't >> want them, then those modules get EOL'd and removed for 3.x. >>
