You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "Piotr P. Karwasz" <pi...@gmail.com> on 2023/09/28 07:35:03 UTC
Log4j module deprecation
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log4j module deprecation
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi all,
On Thu, 28 Sept 2023 at 09:35, Piotr P. Karwasz <pi...@gmail.com> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log4j module deprecation
Posted by Volkan Yazıcı <vo...@yazi.ci>.
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 <wc...@sonic.net> 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ı" <vo...@yazi.ci> wrote:
> >I have cross-posted this to GitHub Discussions
> ><https://github.com/apache/logging-log4j2/discussions/1822> too. Feel
> >free
> >to participate there, if that is of your preference.
> >
> >
> >On Thu, Sep 28, 2023 at 9:35 AM Piotr P. Karwasz
> ><pi...@gmail.com>
> >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-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log4j module deprecation
Posted by Wayne Cannon <wc...@sonic.net>.
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ı" <vo...@yazi.ci> wrote:
>I have cross-posted this to GitHub Discussions
><https://github.com/apache/logging-log4j2/discussions/1822> too. Feel
>free
>to participate there, if that is of your preference.
>
>
>On Thu, Sep 28, 2023 at 9:35 AM Piotr P. Karwasz
><pi...@gmail.com>
>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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
Re: Log4j module deprecation
Posted by Volkan Yazıcı <vo...@yazi.ci>.
I have cross-posted this to GitHub Discussions
<https://github.com/apache/logging-log4j2/discussions/1822> too. Feel free
to participate there, if that is of your preference.
On Thu, Sep 28, 2023 at 9:35 AM Piotr P. Karwasz <pi...@gmail.com>
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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: Log4j module deprecation
Posted by Christian Grobmeier <gr...@apache.org>.
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 <gr...@apache.org> 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 <pi...@gmail.com> 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-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log4j module deprecation
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <gr...@apache.org> 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 <pi...@gmail.com> 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-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log4j module deprecation
Posted by Christian Grobmeier <gr...@apache.org>.
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 <pi...@gmail.com> 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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log4j module deprecation
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <pi...@gmail.com> 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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [ANNOUNCE] Log4j module deprecation
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
On Mon, 6 Nov 2023 at 23:14, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> In order to concentrate our limited resources on the remaining modules,
> the PMC decided to deprecate the following modules/features in 2.x and
> to remove them in 3.x:
> * `log4j-cassandra`,
> * CouchDB appender,
> * GELF appender,
> * Kafka appender,
> * jeroMQ appender,
> * `log4j-jpa`,
> * `log4j-mongodb3`,
> * `log4j-spring-boot`,
> * Java EE SMTP appender,
> * `log4j-taglib`.
Correction: this list should also include JsonLayout (replaced by
JsonTemplateLayout) and YamlLayout.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
[ANNOUNCE] Log4j module deprecation
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
In order to concentrate our limited resources on the remaining modules,
the PMC decided to deprecate the following modules/features in 2.x and
to remove them in 3.x:
* `log4j-cassandra`,
* CouchDB appender,
* GELF appender,
* Kafka appender,
* jeroMQ appender,
* `log4j-jpa`,
* `log4j-mongodb3`,
* `log4j-spring-boot`,
* Java EE SMTP appender,
* `log4j-taglib`.
Each of these modules either has a valid (and maintained) third-party
alternative or its usage has been deemed irrelevant.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log4j module deprecation
Posted by Matt Sicker <ma...@musigma.org>.
* 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 <pi...@gmail.com> 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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org