Re: Log4j module deprecation

[Piotr P. Karwasz]

Hi all,

On Thu, 28 Sept 2023 at 09:35, Piotr P. Karwasz  wrote:
> We know that statistics are not everything and that is why we would
> like to hear your opinion on these modules. The discussion will be
> open for a month, after which the PMC will announce a definitive list
> of deprecations.

It has been more than a month since I sent the announcement. I'll
prepare an e-mail and submit it to `dev` for a vote.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j module deprecation

[Christian Grobmeier]

On Fri, Sep 29, 2023, at 21:40, Ralph Goers wrote:
> I believe I shared my misgivings to these two modules since this was 
> first brought up. I may not have said I am -1 but I definitely never 
> said “go for it”.

I see. Well, I got a different impression when re-reading the discussion, I was 
also thinking this deprecation plan stands.
The text was shared before it was sent here, too. I would have expected a -1 at 
least then.

Btw, I was responding to you because yours was the last e-mail in my client only

>
>
> Ralph
>
>> On Sep 29, 2023, at 5:36 AM, Christian Grobmeier  
>> wrote:
>> 
>> From an observer of this discussion:
>> 
>> And I was thinking we have had this discussion over at dev@. I am surprised 
>> we have seen something which I understood as agreement and then, when we 
>> tell the users about our plans, we reopen this discussion.
>> 
>> This must be very frustrating for Piotr who collected all the feedback, 
>> crafted that message and even shared it, and is now faced with the situation 
>> when he tells a wider audience that we basically tell him to start over.
>> 
>> On the technical note, I feel we have too many modules only few people would 
>> use. We should clean up and create a place for those modules.
>> 
>> Unfortunately I don’t know these modules so I can’t tell, but the way we had 
>> this discussion is extremely frustrating. We should continue on dev@ (again)
>> 
>> On Thu, Sep 28, 2023, at 22:15, Ralph Goers wrote:
>>> I created the docker and Kubernetes modules. Originally my employer 
>>> used them when sending data directly via TCP to a forwarder. However, 
>>> we ran into reliability issues with the forwarder when doing that so we 
>>> switched to writing to the console, despite benchmarks showing it is 
>>> slower. But for anyone implementing something that avoids those issues 
>>> this would be very relevant.  By archiving this we are basically 
>>> telling users that they cannot use it any more since it will no longer 
>>> be supported. For that reason I am not in favor of that for these two 
>>> components.
>>> 
>>> Ralph
>>> 
 On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
 wrote:
 
 Hi all,
 
 We always strive to only release industrial-strength components.
 
 Following an internal discussion and looking at statistics from
 several sources, the PMC plans to deprecate in the 2.x version several
 components for removal in 3.x.
 
 We know that statistics are not everything and that is why we would
 like to hear your opinion on these modules. The discussion will be
 open for a month, after which the PMC will announce a definitive list
 of deprecations.
 
 ## `log4j-cassandra`:
   We support Cassandra 3.x. This release will reach end-of-life when
 4.2.x is released[1]. Since the stats show marginal usage of the
 module, there should be no `log4j-cassandra4`.
 
 ## CouchDB appender:
  It is even less used than Cassandra according to the stats.
 
 ## `log4j-docker`
   Seldom used and standard practice is generally to log to the
 console and let the Docker environment add the data.
 
 ## GELF appender:
   It is mostly superseded by `JsonTemplateLayout`.
 
 ## Kafka appender:
   It contains several critical bug reports neither the PMC, nor the
 community is willing to deal with.
 
 ## `log4j-kubernetes`:
   Seldom used and standard practice is generally to log to the
 console and let the Docker environment add the data.
 
 ## JeroMQ appender:
   Since version 2.6 it had only one PR/bug report and it was from
 PAX Logging maintainer. There is an alternative from a ZeroMQ
 maintainer[2], Fabrice Bacchella, that provides important features
 like encryption or choice of socket type.
 
 ## JNDI-related features:
   JNDI is an old technology from the times of ponies and unicorns,
 when nobody cared about security. The Error Prone team decided to mark
 JNDI usage as error by default[3].
 
 ## `log4j-jpa`:
   Has marginal downloads and requires a migration to Jakarta EE. I
 think that `log4j-jdbc` (which is also seldom used) provides a good
 alternative for SQL databases,
 
 ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
   We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
 used and `YamlLayout` as far as we know is not be used at all.
 
 ## `log4j-mongodb3`:
   Support for MongoDB 3.x ended two years ago.
 
 ## `log4j-spring-boot`:
   Its features are included in Spring Boot 3.x.
 
 ## SMTP appender:
   Its usage is at the bottom of the stats.
 
 ## `log4j-taglib`
   Also needs a Jakarta version, but it is based on a legacy
 technology that is currently seldom used.
 
 Waiting to hear your opinions,
 Piotr
 
 [1] 
 

Re: Log4j module deprecation

[Ralph Goers]

I believe I shared my misgivings to these two modules since this was first 
brought up. I may not have said I am -1 but I definitely never said “go for it”.


Ralph

> On Sep 29, 2023, at 5:36 AM, Christian Grobmeier  wrote:
> 
> From an observer of this discussion:
> 
> And I was thinking we have had this discussion over at dev@. I am surprised 
> we have seen something which I understood as agreement and then, when we tell 
> the users about our plans, we reopen this discussion.
> 
> This must be very frustrating for Piotr who collected all the feedback, 
> crafted that message and even shared it, and is now faced with the situation 
> when he tells a wider audience that we basically tell him to start over.
> 
> On the technical note, I feel we have too many modules only few people would 
> use. We should clean up and create a place for those modules.
> 
> Unfortunately I don’t know these modules so I can’t tell, but the way we had 
> this discussion is extremely frustrating. We should continue on dev@ (again)
> 
> On Thu, Sep 28, 2023, at 22:15, Ralph Goers wrote:
>> I created the docker and Kubernetes modules. Originally my employer 
>> used them when sending data directly via TCP to a forwarder. However, 
>> we ran into reliability issues with the forwarder when doing that so we 
>> switched to writing to the console, despite benchmarks showing it is 
>> slower. But for anyone implementing something that avoids those issues 
>> this would be very relevant.  By archiving this we are basically 
>> telling users that they cannot use it any more since it will no longer 
>> be supported. For that reason I am not in favor of that for these two 
>> components.
>> 
>> Ralph
>> 
>>> On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> We always strive to only release industrial-strength components.
>>> 
>>> Following an internal discussion and looking at statistics from
>>> several sources, the PMC plans to deprecate in the 2.x version several
>>> components for removal in 3.x.
>>> 
>>> We know that statistics are not everything and that is why we would
>>> like to hear your opinion on these modules. The discussion will be
>>> open for a month, after which the PMC will announce a definitive list
>>> of deprecations.
>>> 
>>> ## `log4j-cassandra`:
>>>   We support Cassandra 3.x. This release will reach end-of-life when
>>> 4.2.x is released[1]. Since the stats show marginal usage of the
>>> module, there should be no `log4j-cassandra4`.
>>> 
>>> ## CouchDB appender:
>>>  It is even less used than Cassandra according to the stats.
>>> 
>>> ## `log4j-docker`
>>>   Seldom used and standard practice is generally to log to the
>>> console and let the Docker environment add the data.
>>> 
>>> ## GELF appender:
>>>   It is mostly superseded by `JsonTemplateLayout`.
>>> 
>>> ## Kafka appender:
>>>   It contains several critical bug reports neither the PMC, nor the
>>> community is willing to deal with.
>>> 
>>> ## `log4j-kubernetes`:
>>>   Seldom used and standard practice is generally to log to the
>>> console and let the Docker environment add the data.
>>> 
>>> ## JeroMQ appender:
>>>   Since version 2.6 it had only one PR/bug report and it was from
>>> PAX Logging maintainer. There is an alternative from a ZeroMQ
>>> maintainer[2], Fabrice Bacchella, that provides important features
>>> like encryption or choice of socket type.
>>> 
>>> ## JNDI-related features:
>>>   JNDI is an old technology from the times of ponies and unicorns,
>>> when nobody cared about security. The Error Prone team decided to mark
>>> JNDI usage as error by default[3].
>>> 
>>> ## `log4j-jpa`:
>>>   Has marginal downloads and requires a migration to Jakarta EE. I
>>> think that `log4j-jdbc` (which is also seldom used) provides a good
>>> alternative for SQL databases,
>>> 
>>> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>>   We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
>>> used and `YamlLayout` as far as we know is not be used at all.
>>> 
>>> ## `log4j-mongodb3`:
>>>   Support for MongoDB 3.x ended two years ago.
>>> 
>>> ## `log4j-spring-boot`:
>>>   Its features are included in Spring Boot 3.x.
>>> 
>>> ## SMTP appender:
>>>   Its usage is at the bottom of the stats.
>>> 
>>> ## `log4j-taglib`
>>>   Also needs a Jakarta version, but it is based on a legacy
>>> technology that is currently seldom used.
>>> 
>>> Waiting to hear your opinions,
>>> Piotr
>>> 
>>> [1] 
>>> https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
>>> [2] https://github.com/fbacchella/loghublog4j2
>>> [3] https://errorprone.info/bugpattern/BanJNDI
>>> 
>>> -
>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>> 
>> 
>> 
>> -
>> To 

Re: Log4j module deprecation

[Christian Grobmeier]

>From an observer of this discussion:

And I was thinking we have had this discussion over at dev@. I am surprised we 
have seen something which I understood as agreement and then, when we tell the 
users about our plans, we reopen this discussion.

This must be very frustrating for Piotr who collected all the feedback, crafted 
that message and even shared it, and is now faced with the situation when he 
tells a wider audience that we basically tell him to start over.

On the technical note, I feel we have too many modules only few people would 
use. We should clean up and create a place for those modules.

Unfortunately I don’t know these modules so I can’t tell, but the way we had 
this discussion is extremely frustrating. We should continue on dev@ (again)

On Thu, Sep 28, 2023, at 22:15, Ralph Goers wrote:
> I created the docker and Kubernetes modules. Originally my employer 
> used them when sending data directly via TCP to a forwarder. However, 
> we ran into reliability issues with the forwarder when doing that so we 
> switched to writing to the console, despite benchmarks showing it is 
> slower. But for anyone implementing something that avoids those issues 
> this would be very relevant.  By archiving this we are basically 
> telling users that they cannot use it any more since it will no longer 
> be supported. For that reason I am not in favor of that for these two 
> components.
>
> Ralph
>
>> On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
>> wrote:
>> 
>> Hi all,
>> 
>> We always strive to only release industrial-strength components.
>> 
>> Following an internal discussion and looking at statistics from
>> several sources, the PMC plans to deprecate in the 2.x version several
>> components for removal in 3.x.
>> 
>> We know that statistics are not everything and that is why we would
>> like to hear your opinion on these modules. The discussion will be
>> open for a month, after which the PMC will announce a definitive list
>> of deprecations.
>> 
>> ## `log4j-cassandra`:
>>We support Cassandra 3.x. This release will reach end-of-life when
>> 4.2.x is released[1]. Since the stats show marginal usage of the
>> module, there should be no `log4j-cassandra4`.
>> 
>> ## CouchDB appender:
>>   It is even less used than Cassandra according to the stats.
>> 
>> ## `log4j-docker`
>>Seldom used and standard practice is generally to log to the
>> console and let the Docker environment add the data.
>> 
>> ## GELF appender:
>>It is mostly superseded by `JsonTemplateLayout`.
>> 
>> ## Kafka appender:
>>It contains several critical bug reports neither the PMC, nor the
>> community is willing to deal with.
>> 
>> ## `log4j-kubernetes`:
>>Seldom used and standard practice is generally to log to the
>> console and let the Docker environment add the data.
>> 
>> ## JeroMQ appender:
>>Since version 2.6 it had only one PR/bug report and it was from
>> PAX Logging maintainer. There is an alternative from a ZeroMQ
>> maintainer[2], Fabrice Bacchella, that provides important features
>> like encryption or choice of socket type.
>> 
>> ## JNDI-related features:
>>JNDI is an old technology from the times of ponies and unicorns,
>> when nobody cared about security. The Error Prone team decided to mark
>> JNDI usage as error by default[3].
>> 
>> ## `log4j-jpa`:
>>Has marginal downloads and requires a migration to Jakarta EE. I
>> think that `log4j-jdbc` (which is also seldom used) provides a good
>> alternative for SQL databases,
>> 
>> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
>> used and `YamlLayout` as far as we know is not be used at all.
>> 
>> ## `log4j-mongodb3`:
>>Support for MongoDB 3.x ended two years ago.
>> 
>> ## `log4j-spring-boot`:
>>Its features are included in Spring Boot 3.x.
>> 
>> ## SMTP appender:
>>Its usage is at the bottom of the stats.
>> 
>> ## `log4j-taglib`
>>Also needs a Jakarta version, but it is based on a legacy
>> technology that is currently seldom used.
>> 
>> Waiting to hear your opinions,
>> Piotr
>> 
>> [1] 
>> https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
>> [2] https://github.com/fbacchella/loghublog4j2
>> [3] https://errorprone.info/bugpattern/BanJNDI
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j module deprecation

[Ralph Goers]

I created the docker and Kubernetes modules. Originally my employer used them 
when sending data directly via TCP to a forwarder. However, we ran into 
reliability issues with the forwarder when doing that so we switched to writing 
to the console, despite benchmarks showing it is slower. But for anyone 
implementing something that avoids those issues this would be very relevant.  
By archiving this we are basically telling users that they cannot use it any 
more since it will no longer be supported. For that reason I am not in favor of 
that for these two components.

Ralph

> On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
> wrote:
> 
> Hi all,
> 
> We always strive to only release industrial-strength components.
> 
> Following an internal discussion and looking at statistics from
> several sources, the PMC plans to deprecate in the 2.x version several
> components for removal in 3.x.
> 
> We know that statistics are not everything and that is why we would
> like to hear your opinion on these modules. The discussion will be
> open for a month, after which the PMC will announce a definitive list
> of deprecations.
> 
> ## `log4j-cassandra`:
>We support Cassandra 3.x. This release will reach end-of-life when
> 4.2.x is released[1]. Since the stats show marginal usage of the
> module, there should be no `log4j-cassandra4`.
> 
> ## CouchDB appender:
>   It is even less used than Cassandra according to the stats.
> 
> ## `log4j-docker`
>Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
> 
> ## GELF appender:
>It is mostly superseded by `JsonTemplateLayout`.
> 
> ## Kafka appender:
>It contains several critical bug reports neither the PMC, nor the
> community is willing to deal with.
> 
> ## `log4j-kubernetes`:
>Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
> 
> ## JeroMQ appender:
>Since version 2.6 it had only one PR/bug report and it was from
> PAX Logging maintainer. There is an alternative from a ZeroMQ
> maintainer[2], Fabrice Bacchella, that provides important features
> like encryption or choice of socket type.
> 
> ## JNDI-related features:
>JNDI is an old technology from the times of ponies and unicorns,
> when nobody cared about security. The Error Prone team decided to mark
> JNDI usage as error by default[3].
> 
> ## `log4j-jpa`:
>Has marginal downloads and requires a migration to Jakarta EE. I
> think that `log4j-jdbc` (which is also seldom used) provides a good
> alternative for SQL databases,
> 
> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
> used and `YamlLayout` as far as we know is not be used at all.
> 
> ## `log4j-mongodb3`:
>Support for MongoDB 3.x ended two years ago.
> 
> ## `log4j-spring-boot`:
>Its features are included in Spring Boot 3.x.
> 
> ## SMTP appender:
>Its usage is at the bottom of the stats.
> 
> ## `log4j-taglib`
>Also needs a Jakarta version, but it is based on a legacy
> technology that is currently seldom used.
> 
> Waiting to hear your opinions,
> Piotr
> 
> [1] 
> https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
> [2] https://github.com/fbacchella/loghublog4j2
> [3] https://errorprone.info/bugpattern/BanJNDI
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j module deprecation

[Matt Sicker]

* For the Cassandra appender, I’m ok with deprecation. I had added this plugin 
a while back partly as a demo to show how to write plugins and for some 
consulting-related use cases, but I haven’t used this in quite some time as I’d 
lean toward some form of queue middleware between logs and a Cassandra sink.
* For the Kafka appender, while I like this appender due to the potential for 
supporting asynchronous appender APIs, this is another thing that I’d also end 
up separating in practice, but that’s mainly due to moving that piece of a 
logging pipeline into a log collector of some sort (e.g., via Fluentbit)
* Same with the ZeroMQ appender. While I love ZeroMQ as a library and general 
piece of tech, it works best with more end-to-end code; I’m not sure how useful 
it is to have only one end implemented here. At best, this plugin is more of a 
sample.
* The SMTP appender, on the other hand, seems like a potentially useful one to 
continue supporting. After all, all software eventually learns how to send 
email!
* JNDI stuff seems like it could be useful for proprietary software 
integration. While I haven’t dealt with JNDI for this in several years, it was 
common to use JNDI to get references to various resources in a Java EE server 
to the various proprietary modules you’ve configured there (like message 
queues, database connections, other resource connections, and so forth)

I don’t have much to say about the others.

> On Sep 28, 2023, at 2:35 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> We always strive to only release industrial-strength components.
> 
> Following an internal discussion and looking at statistics from
> several sources, the PMC plans to deprecate in the 2.x version several
> components for removal in 3.x.
> 
> We know that statistics are not everything and that is why we would
> like to hear your opinion on these modules. The discussion will be
> open for a month, after which the PMC will announce a definitive list
> of deprecations.
> 
> ## `log4j-cassandra`:
>We support Cassandra 3.x. This release will reach end-of-life when
> 4.2.x is released[1]. Since the stats show marginal usage of the
> module, there should be no `log4j-cassandra4`.
> 
> ## CouchDB appender:
>   It is even less used than Cassandra according to the stats.
> 
> ## `log4j-docker`
>Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
> 
> ## GELF appender:
>It is mostly superseded by `JsonTemplateLayout`.
> 
> ## Kafka appender:
>It contains several critical bug reports neither the PMC, nor the
> community is willing to deal with.
> 
> ## `log4j-kubernetes`:
>Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
> 
> ## JeroMQ appender:
>Since version 2.6 it had only one PR/bug report and it was from
> PAX Logging maintainer. There is an alternative from a ZeroMQ
> maintainer[2], Fabrice Bacchella, that provides important features
> like encryption or choice of socket type.
> 
> ## JNDI-related features:
>JNDI is an old technology from the times of ponies and unicorns,
> when nobody cared about security. The Error Prone team decided to mark
> JNDI usage as error by default[3].
> 
> ## `log4j-jpa`:
>Has marginal downloads and requires a migration to Jakarta EE. I
> think that `log4j-jdbc` (which is also seldom used) provides a good
> alternative for SQL databases,
> 
> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
> used and `YamlLayout` as far as we know is not be used at all.
> 
> ## `log4j-mongodb3`:
>Support for MongoDB 3.x ended two years ago.
> 
> ## `log4j-spring-boot`:
>Its features are included in Spring Boot 3.x.
> 
> ## SMTP appender:
>Its usage is at the bottom of the stats.
> 
> ## `log4j-taglib`
>Also needs a Jakarta version, but it is based on a legacy
> technology that is currently seldom used.
> 
> Waiting to hear your opinions,
> Piotr
> 
> [1] 
> https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
> [2] https://github.com/fbacchella/loghublog4j2
> [3] https://errorprone.info/bugpattern/BanJNDI
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j module deprecation

[Volkan Yazıcı]

Thanks so much for the feedback Wayne, we really appreciate it. I
couldn't follow what you mean with "Java wrappers". Could you
elaborate on it, please? Could you give some concrete examples? What
was missing? What did you implement? What does it have to do with JNDI
and logging?

On Thu, Sep 28, 2023 at 2:39 PM Wayne Cannon  wrote:
>
> Volkan,
>
> A vote to retain JNDI-related features.
>
> Although I don't use JNDI regularly, I have used it several times in the last 
> decade for a Fortune 100 company to create Java wrappers when commercial 
> libraries don't provide a Java interface -- most recently for a commercial 
> product using one of the most popular license-management packages in use 
> today.
>
> ⁣--Wayne
>
> On Sep 28, 2023, 02:05, at 02:05, "Volkan Yazıcı"  wrote:
> >I have cross-posted this to GitHub Discussions
> > too. Feel
> >free
> >to participate there, if that is of your preference.
> >
> >
> >On Thu, Sep 28, 2023 at 9:35 AM Piotr P. Karwasz
> >
> >wrote:
> >
> >> Hi all,
> >>
> >> We always strive to only release industrial-strength components.
> >>
> >> Following an internal discussion and looking at statistics from
> >> several sources, the PMC plans to deprecate in the 2.x version
> >several
> >> components for removal in 3.x.
> >>
> >> We know that statistics are not everything and that is why we would
> >> like to hear your opinion on these modules. The discussion will be
> >> open for a month, after which the PMC will announce a definitive list
> >> of deprecations.
> >>
> >> ## `log4j-cassandra`:
> >> We support Cassandra 3.x. This release will reach end-of-life
> >when
> >> 4.2.x is released[1]. Since the stats show marginal usage of the
> >> module, there should be no `log4j-cassandra4`.
> >>
> >> ## CouchDB appender:
> >>It is even less used than Cassandra according to the stats.
> >>
> >> ## `log4j-docker`
> >> Seldom used and standard practice is generally to log to the
> >> console and let the Docker environment add the data.
> >>
> >> ## GELF appender:
> >> It is mostly superseded by `JsonTemplateLayout`.
> >>
> >> ## Kafka appender:
> >> It contains several critical bug reports neither the PMC, nor the
> >> community is willing to deal with.
> >>
> >> ## `log4j-kubernetes`:
> >> Seldom used and standard practice is generally to log to the
> >> console and let the Docker environment add the data.
> >>
> >> ## JeroMQ appender:
> >> Since version 2.6 it had only one PR/bug report and it was from
> >> PAX Logging maintainer. There is an alternative from a ZeroMQ
> >> maintainer[2], Fabrice Bacchella, that provides important features
> >> like encryption or choice of socket type.
> >>
> >> ## JNDI-related features:
> >> JNDI is an old technology from the times of ponies and unicorns,
> >> when nobody cared about security. The Error Prone team decided to
> >mark
> >> JNDI usage as error by default[3].
> >>
> >> ## `log4j-jpa`:
> >> Has marginal downloads and requires a migration to Jakarta EE. I
> >> think that `log4j-jdbc` (which is also seldom used) provides a good
> >> alternative for SQL databases,
> >>
> >> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> >> We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
> >> used and `YamlLayout` as far as we know is not be used at all.
> >>
> >> ## `log4j-mongodb3`:
> >> Support for MongoDB 3.x ended two years ago.
> >>
> >> ## `log4j-spring-boot`:
> >> Its features are included in Spring Boot 3.x.
> >>
> >> ## SMTP appender:
> >> Its usage is at the bottom of the stats.
> >>
> >> ## `log4j-taglib`
> >> Also needs a Jakarta version, but it is based on a legacy
> >> technology that is currently seldom used.
> >>
> >> Waiting to hear your opinions,
> >> Piotr
> >>
> >> [1]
> >>
> >https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
> >> [2] https://github.com/fbacchella/loghublog4j2
> >> [3] https://errorprone.info/bugpattern/BanJNDI
> >>
> >> -
> >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>
> >>

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j module deprecation

[Wayne Cannon]

Volkan,

A vote to retain JNDI-related features.

Although I don't use JNDI regularly, I have used it several times in the last 
decade for a Fortune 100 company to create Java wrappers when commercial 
libraries don't provide a Java interface -- most recently for a commercial 
product using one of the most popular license-management packages in use today.

⁣--Wayne​

On Sep 28, 2023, 02:05, at 02:05, "Volkan Yazıcı"  wrote:
>I have cross-posted this to GitHub Discussions
> too. Feel
>free
>to participate there, if that is of your preference.
>
>
>On Thu, Sep 28, 2023 at 9:35 AM Piotr P. Karwasz
>
>wrote:
>
>> Hi all,
>>
>> We always strive to only release industrial-strength components.
>>
>> Following an internal discussion and looking at statistics from
>> several sources, the PMC plans to deprecate in the 2.x version
>several
>> components for removal in 3.x.
>>
>> We know that statistics are not everything and that is why we would
>> like to hear your opinion on these modules. The discussion will be
>> open for a month, after which the PMC will announce a definitive list
>> of deprecations.
>>
>> ## `log4j-cassandra`:
>> We support Cassandra 3.x. This release will reach end-of-life
>when
>> 4.2.x is released[1]. Since the stats show marginal usage of the
>> module, there should be no `log4j-cassandra4`.
>>
>> ## CouchDB appender:
>>It is even less used than Cassandra according to the stats.
>>
>> ## `log4j-docker`
>> Seldom used and standard practice is generally to log to the
>> console and let the Docker environment add the data.
>>
>> ## GELF appender:
>> It is mostly superseded by `JsonTemplateLayout`.
>>
>> ## Kafka appender:
>> It contains several critical bug reports neither the PMC, nor the
>> community is willing to deal with.
>>
>> ## `log4j-kubernetes`:
>> Seldom used and standard practice is generally to log to the
>> console and let the Docker environment add the data.
>>
>> ## JeroMQ appender:
>> Since version 2.6 it had only one PR/bug report and it was from
>> PAX Logging maintainer. There is an alternative from a ZeroMQ
>> maintainer[2], Fabrice Bacchella, that provides important features
>> like encryption or choice of socket type.
>>
>> ## JNDI-related features:
>> JNDI is an old technology from the times of ponies and unicorns,
>> when nobody cared about security. The Error Prone team decided to
>mark
>> JNDI usage as error by default[3].
>>
>> ## `log4j-jpa`:
>> Has marginal downloads and requires a migration to Jakarta EE. I
>> think that `log4j-jdbc` (which is also seldom used) provides a good
>> alternative for SQL databases,
>>
>> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>> We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
>> used and `YamlLayout` as far as we know is not be used at all.
>>
>> ## `log4j-mongodb3`:
>> Support for MongoDB 3.x ended two years ago.
>>
>> ## `log4j-spring-boot`:
>> Its features are included in Spring Boot 3.x.
>>
>> ## SMTP appender:
>> Its usage is at the bottom of the stats.
>>
>> ## `log4j-taglib`
>> Also needs a Jakarta version, but it is based on a legacy
>> technology that is currently seldom used.
>>
>> Waiting to hear your opinions,
>> Piotr
>>
>> [1]
>>
>https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
>> [2] https://github.com/fbacchella/loghublog4j2
>> [3] https://errorprone.info/bugpattern/BanJNDI
>>
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>
>>

Re: Log4j module deprecation

[Volkan Yazıcı]

I have cross-posted this to GitHub Discussions
 too. Feel free
to participate there, if that is of your preference.


On Thu, Sep 28, 2023 at 9:35 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> We always strive to only release industrial-strength components.
>
> Following an internal discussion and looking at statistics from
> several sources, the PMC plans to deprecate in the 2.x version several
> components for removal in 3.x.
>
> We know that statistics are not everything and that is why we would
> like to hear your opinion on these modules. The discussion will be
> open for a month, after which the PMC will announce a definitive list
> of deprecations.
>
> ## `log4j-cassandra`:
> We support Cassandra 3.x. This release will reach end-of-life when
> 4.2.x is released[1]. Since the stats show marginal usage of the
> module, there should be no `log4j-cassandra4`.
>
> ## CouchDB appender:
>It is even less used than Cassandra according to the stats.
>
> ## `log4j-docker`
> Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
>
> ## GELF appender:
> It is mostly superseded by `JsonTemplateLayout`.
>
> ## Kafka appender:
> It contains several critical bug reports neither the PMC, nor the
> community is willing to deal with.
>
> ## `log4j-kubernetes`:
> Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
>
> ## JeroMQ appender:
> Since version 2.6 it had only one PR/bug report and it was from
> PAX Logging maintainer. There is an alternative from a ZeroMQ
> maintainer[2], Fabrice Bacchella, that provides important features
> like encryption or choice of socket type.
>
> ## JNDI-related features:
> JNDI is an old technology from the times of ponies and unicorns,
> when nobody cared about security. The Error Prone team decided to mark
> JNDI usage as error by default[3].
>
> ## `log4j-jpa`:
> Has marginal downloads and requires a migration to Jakarta EE. I
> think that `log4j-jdbc` (which is also seldom used) provides a good
> alternative for SQL databases,
>
> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
> used and `YamlLayout` as far as we know is not be used at all.
>
> ## `log4j-mongodb3`:
> Support for MongoDB 3.x ended two years ago.
>
> ## `log4j-spring-boot`:
> Its features are included in Spring Boot 3.x.
>
> ## SMTP appender:
> Its usage is at the bottom of the stats.
>
> ## `log4j-taglib`
> Also needs a Jakarta version, but it is based on a legacy
> technology that is currently seldom used.
>
> Waiting to hear your opinions,
> Piotr
>
> [1]
> https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
> [2] https://github.com/fbacchella/loghublog4j2
> [3] https://errorprone.info/bugpattern/BanJNDI
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>