It seems to me that this would only work if a) there exists a stable API/ABI for log4j and b) sufficient demand for the appenders exists. If a stable API/ABI doesn't exist, then the new maintainers would be on the hook for any changes that log4j made, which seems unreasonable to me.
-Robert Middleton On Tue, Jun 7, 2022 at 2:40 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi, > > On Tue, 7 Jun 2022 at 20:17, Matt Sicker <boa...@gmail.com> wrote: > > * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?) > > I would try EclipseLink, since Hibernate made their choice a long time ago. > > > * JMS appender (could go to ActiveMQ or Jakarta) > > An in-house collaboration with ActiveMQ seems more realistic. > > > * SMTP appender -> makybe Jakarta? > > Jakarta Mail has a stable API, we can keep this one. > > > 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. > > I would settle for a list of maintainers from those projects that are > willing to help, whenever they decide on breaking an API or to advise > which version should be supported and which one can be dropped. > > Regarding `log4j-appserver`, the Jetty part is obsolete (does not work > with Jetty 10) and the Tomcat part could be migrated to Tomcat. It's > only one class, but there is also an old PR of mine that I closed in > order not to pollu^wenrich Log4j2 with new external dependencies. > > Piotr
