Gary, have you ever heard of JNoSQL before? <http://www.jnosql.org/> It’s basically a JDBC-like effort to create a generic NoSQL API. Been around for a few years at least, and I had considered adding an appender for this back when I learned about it, but I think this was by the point where I stopped making proof of concept appenders. — Matt Sicker
> On Nov 3, 2023, at 09:08, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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 >> >>
