Re: [RESULT] [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Piotr P. Karwasz]

Hi,

On Mon, 6 Nov 2023 at 22:51, Piotr P. Karwasz  wrote:
>  * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
>  * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
> mattsicker, rgoers, vy and me),

Sorry, I inverted the list of voters here: for `log4j-spring-boot`
everybody voted +1 (ggregory, grobmeier, mattsicker, rgoers, vy and
me). For the Java EE SMTP appender the only +1 are from ggregory,
grobmeier, vy and me.

Piotr

Re: [RESULT] [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Ralph Goers]

I also voted +1 on log4j-spring-boot. 

Ralph

> On Nov 6, 2023, at 2:51 PM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> On Mon, 30 Oct 2023 at 09:44, Piotr P. Karwasz  
> wrote:
>> 
>> This is a vote to deprecate the following `2.x` modules and features
>> and remove them from the `3.x` release:
>> 
>> * `log4j-cassandra`:
>> * CouchDB appender:
>> * `log4j-docker`
>> * GELF appender:
>> * Kafka appender:
>> * `log4j-kubernetes`:
>> * JeroMQ appender:
>> * JNDI-related features:
>> * `log4j-jpa`:
>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>> * `log4j-mongodb3`:
>> * `log4j-spring-boot`:
>> * Java EE SMTP appender:
>> * Jakarta EE SMTP appender:
>> * `log4j-taglib`:
>> 
>> Please cast votes for each module/feature separately on this mailing list:
>> 
>> [ ] +1,  drop the artifact/module,
>> [ ] +/-0
>> [ ] -1,  keep the artifact/module, because...
> 
> The following PMC have expressed their votes: Gary Gregory, Christian
> Grobmeier, Matt Sicker, Ralph Goers, Volkan Yazıcı and me.
> 
> The PMC decided to deprecate the following modules/features in 2.x and
> to remove them in 3.x:
> * `log4j-cassandra` (binding +1 from grobmeier, mattsicker, rgoers, vy and 
> me),
> * CouchDB appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
> * GELF appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
> * Kafka appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
> * jeroMQ appender (binding +1 from grobmeier, mattsicker, vy and me),
> * `log4j-jpa` (binding +1 from grobmeier, vy and me),
> * `log4j-mongodb3` (binding +1 from ggregory, grobmeier, mattsicker,
> rgoers, vy and me),
> * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
> * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
> mattsicker, rgoers, vy and me),
> * `log4j-taglib` (binding +1 from ggregory, grobmeier, mattsicker, vy and me),
> 
> Piotr

Re: [RESULT] [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Volkan Yazıcı]

this doesnt capture the account right for json and yaml layout. Gary only
wants to keep the xml layout:
https://lists.apache.org/thread/qdf5zrtqg294zj9voj6x7rlhsfln752p

On Mon, 6 Nov 2023 at 22:52, Piotr P. Karwasz 
wrote:

> Hi all,
>
> On Mon, 30 Oct 2023 at 09:44, Piotr P. Karwasz 
> wrote:
> >
> > This is a vote to deprecate the following `2.x` modules and features
> > and remove them from the `3.x` release:
> >
> >  * `log4j-cassandra`:
> >  * CouchDB appender:
> >  * `log4j-docker`
> >  * GELF appender:
> >  * Kafka appender:
> >  * `log4j-kubernetes`:
> >  * JeroMQ appender:
> >  * JNDI-related features:
> >  * `log4j-jpa`:
> >  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> >  * `log4j-mongodb3`:
> >  * `log4j-spring-boot`:
> >  * Java EE SMTP appender:
> >  * Jakarta EE SMTP appender:
> >  * `log4j-taglib`:
> >
> > Please cast votes for each module/feature separately on this mailing
> list:
> >
> > [ ] +1,  drop the artifact/module,
> > [ ] +/-0
> > [ ] -1,  keep the artifact/module, because...
>
> The following PMC have expressed their votes: Gary Gregory, Christian
> Grobmeier, Matt Sicker, Ralph Goers, Volkan Yazıcı and me.
>
> The PMC decided to deprecate the following modules/features in 2.x and
> to remove them in 3.x:
>  * `log4j-cassandra` (binding +1 from grobmeier, mattsicker, rgoers, vy
> and me),
>  * CouchDB appender (binding +1 from grobmeier, mattsicker, rgoers, vy and
> me),
>  * GELF appender (binding +1 from grobmeier, mattsicker, rgoers, vy and
> me),
>  * Kafka appender (binding +1 from grobmeier, mattsicker, rgoers, vy and
> me),
>  * jeroMQ appender (binding +1 from grobmeier, mattsicker, vy and me),
>  * `log4j-jpa` (binding +1 from grobmeier, vy and me),
>  * `log4j-mongodb3` (binding +1 from ggregory, grobmeier, mattsicker,
> rgoers, vy and me),
>  * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
>  * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
> mattsicker, rgoers, vy and me),
>  * `log4j-taglib` (binding +1 from ggregory, grobmeier, mattsicker, vy and
> me),
>
> Piotr
>

[RESULT] [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Piotr P. Karwasz]

Hi all,

On Mon, 30 Oct 2023 at 09:44, Piotr P. Karwasz  wrote:
>
> This is a vote to deprecate the following `2.x` modules and features
> and remove them from the `3.x` release:
>
>  * `log4j-cassandra`:
>  * CouchDB appender:
>  * `log4j-docker`
>  * GELF appender:
>  * Kafka appender:
>  * `log4j-kubernetes`:
>  * JeroMQ appender:
>  * JNDI-related features:
>  * `log4j-jpa`:
>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>  * `log4j-mongodb3`:
>  * `log4j-spring-boot`:
>  * Java EE SMTP appender:
>  * Jakarta EE SMTP appender:
>  * `log4j-taglib`:
>
> Please cast votes for each module/feature separately on this mailing list:
>
> [ ] +1,  drop the artifact/module,
> [ ] +/-0
> [ ] -1,  keep the artifact/module, because...

The following PMC have expressed their votes: Gary Gregory, Christian
Grobmeier, Matt Sicker, Ralph Goers, Volkan Yazıcı and me.

The PMC decided to deprecate the following modules/features in 2.x and
to remove them in 3.x:
 * `log4j-cassandra` (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * CouchDB appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * GELF appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * Kafka appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * jeroMQ appender (binding +1 from grobmeier, mattsicker, vy and me),
 * `log4j-jpa` (binding +1 from grobmeier, vy and me),
 * `log4j-mongodb3` (binding +1 from ggregory, grobmeier, mattsicker,
rgoers, vy and me),
 * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
 * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
mattsicker, rgoers, vy and me),
 * `log4j-taglib` (binding +1 from ggregory, grobmeier, mattsicker, vy and me),

Piotr

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary Gregory]

Hi Volkan,

I only care about XML.

Gary


On Fri, Nov 3, 2023, 3:27 PM Volkan Yazıcı  wrote:

> Gary, do you want to keep all Jackson modules or just XmlLayout?
>
> -- Forwarded message -
> From: Volkan Yazıcı 
> Date: Thu, 2 Nov 2023 at 16:43
> Subject: Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and
> removal in 3.x
> To: 
>
>
> On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
> wrote:
>
>> > On Nov 2, 2023, at 7:42 AM, Gary Gregory 
>> wrote:
>> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
>> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).
>
>
> Gary, do you only want to keep `XmlLayout` or all 3?
>

[Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Volkan Yazıcı]

Gary, do you want to keep all Jackson modules or just XmlLayout?

-- Forwarded message -
From: Volkan Yazıcı 
Date: Thu, 2 Nov 2023 at 16:43
Subject: Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and
removal in 3.x
To: 


On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
wrote:

> > On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).


Gary, do you only want to keep `XmlLayout` or all 3?

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary Gregory]

Yes but I'm not sure if that's the API I found way back when I needed to
create a MongoDB appender. At the time, the projects I found was not fully
baked and I did not think there was a sensible option for a JDBC for NoSQL.

Gary

On Fri, Nov 3, 2023, 1:50 PM Matt Sicker  wrote:

> Gary, have you ever heard of JNoSQL before?  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  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 
> > 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 
> wrote:
> >>>
> >>> My votes:
> >>>
> >>> On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >>>  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
> >>
> >>
>
>

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Matt Sicker]

Gary, have you ever heard of JNoSQL before?  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  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 
> 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  wrote:
>>> 
>>> My votes:
>>> 
>>> On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
>>>  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
>> 
>> 

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary Gregory]

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 
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  wrote:
> >
> > My votes:
> >
> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >  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
>
>

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Matt Sicker]

What’s great about JTL is that it generates valid YAML, too! YAML is a superset 
of JSON. :)

> On Nov 2, 2023, at 11:15 AM, Ralph Goers  wrote:
> 
> IMO JSONLayout should be deprecated for 2 reasons:
> 1. JTL is so much better
> 2. It doesn’t generate great JSON.
> 
> As for the YAMLLayout, I have no idea who would want that. If they did there 
> has got to be a better solution than using Jackson. To be honest, it would be 
> great if JTL could be generalized to handle all 3, but that may be asking too 
> much.
> 
> Ralph
> 
>> On Nov 2, 2023, at 8:43 AM, Volkan Yazıcı  wrote:
>> 
>> On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
>> wrote:
>> 
 On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
 On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
 -1: I want the ability to log to XML (narrow use-case, sure, but handy).
>> 
>> 
>> Gary, do you only want to keep `XmlLayout` or all 3?
> 

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Matt Sicker]

Votes below

> On Oct 30, 2023, at 3:44 AM, Piotr P. Karwasz  wrote:
> 
> This is a vote to deprecate the following `2.x` modules and features
> and remove them from the `3.x` release:
> 
> * `log4j-cassandra`:
+1 deprecate
> * CouchDB appender:
+1 deprecate
> * `log4j-docker`
-0
> * GELF appender:
+1 deprecate
> * Kafka appender:
+1 deprecate
> * `log4j-kubernetes`:
-0
> * JeroMQ appender:
+1 deprecate
> * JNDI-related features:
-0, would only deprecate if we deprecate the things that require it, too
> * `log4j-jpa`:
+0, sort of seems redundant with the JDBC plugins, but I’m not super familiar
> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
+1 deprecate
> * `log4j-mongodb3`:
+1 deprecate, this version of mongo is ancient
> * `log4j-spring-boot`:
+1 deprecate, Spring Boot 3 has better built-in support for this already
> * Java EE SMTP appender:
-0, all programs eventually learn how to send email, but it’s the old package 
name
> * Jakarta EE SMTP appender:
-1, all programs eventually learn how to send email, current API
> * `log4j-taglib`:
+1 deprecate

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Ralph Goers]

IMO JSONLayout should be deprecated for 2 reasons:
1. JTL is so much better
2. It doesn’t generate great JSON.

As for the YAMLLayout, I have no idea who would want that. If they did there 
has got to be a better solution than using Jackson. To be honest, it would be 
great if JTL could be generalized to handle all 3, but that may be asking too 
much.

Ralph

> On Nov 2, 2023, at 8:43 AM, Volkan Yazıcı  wrote:
> 
> On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
> wrote:
> 
>>> On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
>>> On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
 * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>> -1: I want the ability to log to XML (narrow use-case, sure, but handy).
> 
> 
> Gary, do you only want to keep `XmlLayout` or all 3?

[Discuss][VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Ralph Goers]

Gary,

As a reminder, a +1 vote means that the component will be marked deprecated in 
2.x and removed in 3.x.  This seems appropriate for log4j-spring-boot as users 
of Spring upgrading to Log4j 3.x will almost surely be on Spring Boot 3.

Ralph

> On Nov 2, 2023, at 8:55 AM, Piotr P. Karwasz  wrote:
> 
> Hi Gary,
> 
> On Thu, 2 Nov 2023 at 16:30, Gary D. Gregory  wrote:
>> On 2023/11/02 15:05:05 "Piotr P. Karwasz" wrote:
>>> On Thu, 2 Nov 2023 at 15:42, Gary Gregory  wrote:
> * `log4j-spring-boot`:
 -1: Spring seems too important.
>>> 
>>> Are you sure you want to _veto_ a module removal based on a feeling?
>>> `log4j-spring-boot` has 4 elements: a lookup, a property source, an
>>> arbiter and an improved version of `Log4j2LoggingSystem`.
>>> All these elements were submitted to Spring Boot by Ralph and included in 
>>> 3.x.
>>> So this module targets the users that don't want Spring Boot 3.x, but
>>> want Log4j 3.x.
>> 
>> I feel it is too big an ask to force people to migrate to 3.x which is not 
>> released.
> 
> I am not sure I am following. You don't want to force Log4j 3.x users
> to migrate to Spring Boot 3.x?
> I think the pressure to migrate to Spring Boot 3.x will be higher than
> the pressure to migrate to Log4j 3.x.
> 
> Piotr

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Piotr P. Karwasz]

Hi Gary,

On Thu, 2 Nov 2023 at 16:30, Gary D. Gregory  wrote:
> On 2023/11/02 15:05:05 "Piotr P. Karwasz" wrote:
> > On Thu, 2 Nov 2023 at 15:42, Gary Gregory  wrote:
> > > >  * `log4j-spring-boot`:
> > > -1: Spring seems too important.
> >
> > Are you sure you want to _veto_ a module removal based on a feeling?
> > `log4j-spring-boot` has 4 elements: a lookup, a property source, an
> > arbiter and an improved version of `Log4j2LoggingSystem`.
> > All these elements were submitted to Spring Boot by Ralph and included in 
> > 3.x.
> > So this module targets the users that don't want Spring Boot 3.x, but
> > want Log4j 3.x.
>
> I feel it is too big an ask to force people to migrate to 3.x which is not 
> released.

I am not sure I am following. You don't want to force Log4j 3.x users
to migrate to Spring Boot 3.x?
I think the pressure to migrate to Spring Boot 3.x will be higher than
the pressure to migrate to Log4j 3.x.

Piotr

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Volkan Yazıcı]

On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
wrote:

> > On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).


Gary, do you only want to keep `XmlLayout` or all 3?

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary D. Gregory]

On 2023/11/02 15:05:05 "Piotr P. Karwasz" wrote:
> Hi Gary,
> 
> On Thu, 2 Nov 2023 at 15:42, Gary Gregory  wrote:
> > >  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).
> 
> Does it really need to be Jackson? Jackson is optimized for JSON, we
> can easily write a SAX, StAX or JAXB appender in a couple of hours.

That was not the question asked by this VOTE. Also, smells or NIH and "famous 
last words" ;-)

> 
> > >  * `log4j-spring-boot`:
> > -1: Spring seems too important.
> 
> Are you sure you want to _veto_ a module removal based on a feeling?
> `log4j-spring-boot` has 4 elements: a lookup, a property source, an
> arbiter and an improved version of `Log4j2LoggingSystem`.
> All these elements were submitted to Spring Boot by Ralph and included in 3.x.
> So this module targets the users that don't want Spring Boot 3.x, but
> want Log4j 3.x.

I feel it is too big an ask to force people to migrate to 3.x which is not 
released.

I also feel ALL of this is premature until 3.x is out.

Gary

> 
> Piotr
> 

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Piotr P. Karwasz]

Hi Gary,

On Thu, 2 Nov 2023 at 15:42, Gary Gregory  wrote:
> >  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> -1: I want the ability to log to XML (narrow use-case, sure, but handy).

Does it really need to be Jackson? Jackson is optimized for JSON, we
can easily write a SAX, StAX or JAXB appender in a couple of hours.

> >  * `log4j-spring-boot`:
> -1: Spring seems too important.

Are you sure you want to _veto_ a module removal based on a feeling?
`log4j-spring-boot` has 4 elements: a lookup, a property source, an
arbiter and an improved version of `Log4j2LoggingSystem`.
All these elements were submitted to Spring Boot by Ralph and included in 3.x.
So this module targets the users that don't want Spring Boot 3.x, but
want Log4j 3.x.

Piotr

[Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Ralph Goers]

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  wrote:
> 
> My votes:
> 
> On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
>  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

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary Gregory]

My votes:

On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
 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

Re: [Discuss][VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Christian Grobmeier]

Hi,

On Tue, Oct 31, 2023, at 23:53, Ralph Goers wrote:
> Deprecation and moving to separate modules are not the same thing at 
> all. I would be +1 to moving everything on this list that isn’t 
> outright removed to separate repos. I have stated that several times.  

I am fully aware of that. This is about adding a deprecated label to 2.x 
components and schedule them for removal in 3.x. That why I quickly give my +1, 
because 3.x is still in alpha, and we can step back from this decision if 
needed.

> Gary is strongly against doing that.
>
> If you are somehow equating deprecation with moving to a separate repo 
> then you are voting on the wrong thing. This vote is basically on what 
> will be removed and no longer supported in 3.x.

No I am voting on the right thing. I am suggesting we are doing a separate vote 
to move out all JNDI related components to their own repo. I am aware Gary is 
opposed to this, but I am strongly in favor to such a move.

Reading my message, I see where this confusion comes from; sorry for that. I 
should have made my two points more clear.

Anyway, still voting +1 on deprecation for now

>
> Ralph
>
>> On Oct 31, 2023, at 2:00 PM, Christian Grobmeier  
>> wrote:
>> 
>> +1 to all - deprecation to me means we add a label that we plan to remove it 
>> in 3.x, but we are not removing it not. We can step back.
>> 
>> Many of those modules don't look as if they need to belong in the main repo. 
>> I can accept kubernetes/docker stuff, but not in the main repo.
>> 
>> I have a strong +1 on removing all JNDI features immediately, making them 
>> available for those poor souls in a separate repo. I opened another thread 
>> where I asked why we need this at all because it seems pointless to me. JNDI 
>> is also a hazardous word within this project.
>> 
>> About the rest I don't have strong feelings
>> 
>> On Mon, Oct 30, 2023, at 09:44, Piotr P. Karwasz wrote:
>>> This is a vote to deprecate the following `2.x` modules and features
>>> and remove them from the `3.x` release:
>>> 
>>> * `log4j-cassandra`:
>>> * CouchDB appender:
>>> * `log4j-docker`
>>> * GELF appender:
>>> * Kafka appender:
>>> * `log4j-kubernetes`:
>>> * JeroMQ appender:
>>> * JNDI-related features:
>>> * `log4j-jpa`:
>>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>> * `log4j-mongodb3`:
>>> * `log4j-spring-boot`:
>>> * Java EE SMTP appender:
>>> * Jakarta EE SMTP appender:
>>> * `log4j-taglib`:
>>> 
>>> 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

Re: [Discuss][VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Ralph Goers]

Rats. In my first sentence replace “modules” with “repos”.

Ralph

> On Oct 31, 2023, at 3:53 PM, Ralph Goers  wrote:
> 
> Christian,
> 
> Deprecation and moving to separate modules are not the same thing at all. I 
> would be +1 to moving everything on this list that isn’t outright removed to 
> separate repos. I have stated that several times.  Gary is strongly against 
> doing that.
> 
> If you are somehow equating deprecation with moving to a separate repo then 
> you are voting on the wrong thing. This vote is basically on what will be 
> removed and no longer supported in 3.x.
> 
> Ralph
> 
>> On Oct 31, 2023, at 2:00 PM, Christian Grobmeier  
>> wrote:
>> 
>> +1 to all - deprecation to me means we add a label that we plan to remove it 
>> in 3.x, but we are not removing it not. We can step back.
>> 
>> Many of those modules don't look as if they need to belong in the main repo. 
>> I can accept kubernetes/docker stuff, but not in the main repo.
>> 
>> I have a strong +1 on removing all JNDI features immediately, making them 
>> available for those poor souls in a separate repo. I opened another thread 
>> where I asked why we need this at all because it seems pointless to me. JNDI 
>> is also a hazardous word within this project.
>> 
>> About the rest I don't have strong feelings
>> 
>> On Mon, Oct 30, 2023, at 09:44, Piotr P. Karwasz wrote:
>>> This is a vote to deprecate the following `2.x` modules and features
>>> and remove them from the `3.x` release:
>>> 
>>> * `log4j-cassandra`:
>>> * CouchDB appender:
>>> * `log4j-docker`
>>> * GELF appender:
>>> * Kafka appender:
>>> * `log4j-kubernetes`:
>>> * JeroMQ appender:
>>> * JNDI-related features:
>>> * `log4j-jpa`:
>>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>> * `log4j-mongodb3`:
>>> * `log4j-spring-boot`:
>>> * Java EE SMTP appender:
>>> * Jakarta EE SMTP appender:
>>> * `log4j-taglib`:
>>> 
>>> 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
> 

[Discuss][VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Ralph Goers]

Christian,

Deprecation and moving to separate modules are not the same thing at all. I 
would be +1 to moving everything on this list that isn’t outright removed to 
separate repos. I have stated that several times.  Gary is strongly against 
doing that.

If you are somehow equating deprecation with moving to a separate repo then you 
are voting on the wrong thing. This vote is basically on what will be removed 
and no longer supported in 3.x.

Ralph

> On Oct 31, 2023, at 2:00 PM, Christian Grobmeier  wrote:
> 
> +1 to all - deprecation to me means we add a label that we plan to remove it 
> in 3.x, but we are not removing it not. We can step back.
> 
> Many of those modules don't look as if they need to belong in the main repo. 
> I can accept kubernetes/docker stuff, but not in the main repo.
> 
> I have a strong +1 on removing all JNDI features immediately, making them 
> available for those poor souls in a separate repo. I opened another thread 
> where I asked why we need this at all because it seems pointless to me. JNDI 
> is also a hazardous word within this project.
> 
> About the rest I don't have strong feelings
> 
> On Mon, Oct 30, 2023, at 09:44, Piotr P. Karwasz wrote:
>> This is a vote to deprecate the following `2.x` modules and features
>> and remove them from the `3.x` release:
>> 
>> * `log4j-cassandra`:
>> * CouchDB appender:
>> * `log4j-docker`
>> * GELF appender:
>> * Kafka appender:
>> * `log4j-kubernetes`:
>> * JeroMQ appender:
>> * JNDI-related features:
>> * `log4j-jpa`:
>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>> * `log4j-mongodb3`:
>> * `log4j-spring-boot`:
>> * Java EE SMTP appender:
>> * Jakarta EE SMTP appender:
>> * `log4j-taglib`:
>> 
>> 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

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Christian Grobmeier]

+1 to all - deprecation to me means we add a label that we plan to remove it in 
3.x, but we are not removing it not. We can step back.

Many of those modules don't look as if they need to belong in the main repo. I 
can accept kubernetes/docker stuff, but not in the main repo.

I have a strong +1 on removing all JNDI features immediately, making them 
available for those poor souls in a separate repo. I opened another thread 
where I asked why we need this at all because it seems pointless to me. JNDI is 
also a hazardous word within this project.

About the rest I don't have strong feelings

On Mon, Oct 30, 2023, at 09:44, Piotr P. Karwasz wrote:
> This is a vote to deprecate the following `2.x` modules and features
> and remove them from the `3.x` release:
>
>  * `log4j-cassandra`:
>  * CouchDB appender:
>  * `log4j-docker`
>  * GELF appender:
>  * Kafka appender:
>  * `log4j-kubernetes`:
>  * JeroMQ appender:
>  * JNDI-related features:
>  * `log4j-jpa`:
>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>  * `log4j-mongodb3`:
>  * `log4j-spring-boot`:
>  * Java EE SMTP appender:
>  * Jakarta EE SMTP appender:
>  * `log4j-taglib`:
>
> 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

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Ralph Goers]

Here are my votes:

> On Oct 30, 2023, at 1:44 AM, Piotr P. Karwasz  wrote:
> 
> This is a vote to deprecate the following `2.x` modules and features
> and remove them from the `3.x` release:
> 
> * `log4j-cassandra`:
+1
> * CouchDB appender:
+1
> * `log4j-docker`
-1 - Still useful and supportable
> * GELF appender:
+1 - JsonTemplateLayout replaces this
> * Kafka appender:
+1 (I have mixed feelings about this. It would obviously be useful but the 
version we support is ancient and doesn’t support many things one would want)
> * `log4j-kubernetes`:
-1 Still useful and supportable
> * JeroMQ appender:
+0 I’ve never used JeroMQ.
> * JNDI-related features:
-1 Unfortunately, JEE users require this.
> * `log4j-jpa`:
+0 I’ve never cared about logging to an RDBMS.
> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
+0 (We have no replacement for logging to XML or Yaml although I have no idea 
why one would want tot).
> * `log4j-mongodb3`:
+1
> * `log4j-spring-boot`:
+1 (Spring provides this in Spring 3 and users or that should use Log4j 3.x)
> * Java EE SMTP appender:
+0 
> * Jakarta EE SMTP appender:
+0
> * `log4j-taglib`:
+0 (I never understood the purpose of this).


Ralph

> 
> 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

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Volkan Yazıcı]

+1 (for all)

On Mon, Oct 30, 2023 at 9:45 AM Piotr P. Karwasz 
wrote:

> This is a vote to deprecate the following `2.x` modules and features
> and remove them from the `3.x` release:
>
>  * `log4j-cassandra`:
>  * CouchDB appender:
>  * `log4j-docker`
>  * GELF appender:
>  * Kafka appender:
>  * `log4j-kubernetes`:
>  * JeroMQ appender:
>  * JNDI-related features:
>  * `log4j-jpa`:
>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>  * `log4j-mongodb3`:
>  * `log4j-spring-boot`:
>  * Java EE SMTP appender:
>  * Jakarta EE SMTP appender:
>  * `log4j-taglib`:
>
> 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
>

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Piotr P. Karwasz]

Hi all,

On Mon, 30 Oct 2023 at 09:44, Piotr P. Karwasz  wrote:
>  * `log4j-cassandra`:
+1
>  * CouchDB appender:
+1
>  * `log4j-docker`
-0, the code looks good.
>  * GELF appender:
+1
>  * Kafka appender:
+1
>  * `log4j-kubernetes`:
-0, the code looks good.
>  * JeroMQ appender:
+1
>  * JNDI-related features:
+0, unfortunately some users need it.
>  * `log4j-jpa`:
+1
>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
+1
>  * `log4j-mongodb3`:
+1
>  * `log4j-spring-boot`:
+1
>  * Java EE SMTP appender:
+1
>  * Jakarta EE SMTP appender:
-1, many users don't have a big log-crunching infrastructure. I
consider configuring an SMTP appender to send WARN/ERROR messages via
e-mail as a good practice to encourage in this case.
>  * `log4j-taglib`:
+1

Piotr

[VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Piotr P. Karwasz]

This is a vote to deprecate the following `2.x` modules and features
and remove them from the `3.x` release:

 * `log4j-cassandra`:
 * CouchDB appender:
 * `log4j-docker`
 * GELF appender:
 * Kafka appender:
 * `log4j-kubernetes`:
 * JeroMQ appender:
 * JNDI-related features:
 * `log4j-jpa`:
 * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
 * `log4j-mongodb3`:
 * `log4j-spring-boot`:
 * Java EE SMTP appender:
 * Jakarta EE SMTP appender:
 * `log4j-taglib`:

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