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

Reply via email to