What I mean is this: When I want to work with a DB-like thing from Java, I look 1st for a JDBC driver, when there is no FOSS option, I have to use a DB-specifc API, for example MongoDB. Granted Cassandra is NoSQL doc store but there are commercial JDBC drivers IIRC.
All of this to say that I feel it is nice for us to support non-JDBC stores when there are no FOSS JDBC drivers available for that datastore type. 2. I got it backward then, thank you for explaining it again. +1 to remove in 3.0 but keep in 2.x. Gary On Thu, Nov 2, 2023, 11:04 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Gary, a couple of comments: > > 1. I don’t understand what “there is no official JDBC access” has to do > with Cassandra or CouchDB. Could you please elaborate? > 2. The functionality in log4j-spring-boot is directly incorporated into > Spring 3 due to a PR I submitted. So with Spring Boot 3 log4j-spring-boot > should NOT be included. Since Log4j 3.x (at least in my mind) goes hand in > hand with Spring Boot 3 then removing log4j-spring-boot in 3.x makes sense. > > Ralph > > > On Nov 2, 2023, at 7:42 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > My votes: > > > > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz > > <piotr.karw...@gmail.com> wrote: > >> > >> This is a vote to deprecate the following `2.x` modules and features > >> and remove them from the `3.x` release: > >> > >> * `log4j-cassandra`: > > -0: Prefer keeping since there is no official JDBC access that I know > > of but I have not looked for a while. > > > >> * CouchDB appended: > > -0: Prefer keeping since there is no official JDBC access that I know > > of but I have not looked for a while. > > > >> * `log4j-docker` > > -1 Docker seems too important. > > > >> * GELF appended: > > +0 > > > >> * Kafka appended: > > -0: Prefer keeping since there is no official JMS access that I know > > of but I have not looked for a while. > > > >> * `log4j-kubernetes`: > > -1: This should match what we do with Docker. > > > >> * JeroMQ appender: > > -0: Prefer keeping since there is no official JMS access that I know > > of but I have not looked for a while. > > > >> * JNDI-related features: > > -1: Needed in enterprise environments, OK to split out in a separate > > Maven module. > > > >> * `log4j-jpa`: > > -0: JDBC Appender is good enough for me. Use-case seems narrow except > > for a JPA shop. > > > >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout) > > -1: I want the ability to log to XML (narrow use-case, sure, but handy). > > > >> * `log4j-mongodb3`: > > +1: I use mongodb4 > > > >> * `log4j-spring-boot`: > > -1: Spring seems too important. > > > >> * Java EE SMTP appended: > > +1: Use the Jakarta version. > > > >> * Jakarta EE SMTP appended: > > -1: Handy, sometimes. > > > >> * `log4j-taglib`: > > +1, never used it. > > > > Gary > > > >> > >> Please cast votes for each module/feature separately on this mailing > list: > >> > >> [ ] +1, drop the artifact/module, > >> [ ] +/-0 > >> [ ] -1, keep the artifact/module, because... > >> > >> This vote is open for 168 hours (i.e. one week) and each deprecation > >> will pass unless getting a net negative vote count. All votes are > >> welcome, but only the Logging Services PMC votes are officially > >> counted. > >> > >> Piotr > >
