Re: Deprecating modules in 2.x

[Volkan Yazıcı]

I would be in favor of deprecating the following modules in `2.x` and
dropping them starting from `3.0.0`:

   1. `log4j-jndi` (available only in `main`) – nobody should use JNDI
   anyway
   2. `log4j-layout-jackson*` – `JsonTemplateLayout` succeeds `JsonLayout`,
   I doubt if anybody is using `XmlLayout`, nobody should use `YamlLayout`
   anyway
   3. `log4j-gelf` (available only in `main`) – JTL offers the same
   functionality, we just need to add a `CompressingLayout` (see LOG4J2-3023)
   and a resolver template (i.e., `gelf.json`)
   4. `log4j-jms` (available only in `main`)
   5. `log4j-csv` (available only in `main`)
   6. `log4j-jeromq`
   7. `log4j-cassandra`
   8. `log4j-smtp`
   9. `log4j-jakarta-smtp`
   10. `log4j-couchdb`
   11. `log4j-taglib`
   12. `log4j-mongodb3`
   13. `log4j-spring*` – we should try to upstream these to Spring Boot,
   otherwise to their own `apache/logging-*` repository
   14. `log4j-jdbc`
   15. `log4j-kafka` – we should either hand this out to the community or,
   if not rewrite, revamp it. In its current state
   
,
   it doesn't appear to be of production-grade quality.

For the records, Romain Manni-Bucau created LOG4J2-1650
 for a similar "diet".
That was in 2016, since then things got sadly worse.

We don't need to have a very strong consensus. As long as we have a
proposal draft that everybody _roughly_ agrees on, we can announce this in
every public medium we can think of (`dev@community`, `log4j-user@logging`,
`dev@logging`, ASF planet, Twitter, etc.) and decide on the actual "cut"
based on the feedback received.

I don't want to derail the conversation at this stage, though I need to
admit I have my reservations regarding the "please don't drop it because my
employer uses it" argument. We can, preferably after the public feedback
deadline, talk about it.


On Sat, Sep 9, 2023 at 9:16 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> In a Slack discussion Volkan proposed (among other things) to:
>
>  * raise the Java requirements in 3.x to Java 17. It is the same
> requirement as Spring Boot 3.x has, so I don't see a reason to lower
> the bar. Besides Java 21 will be an LTS.
>  * deprecate some modules in 2.x and drop them in 3.0.x, restore them
> if a user requests it in 3.1.x.
>
> While the number of downloads is not the only criterium (a big company
> with an internal Maven repo counts 1, a student's project that tries
> multiple version counts more), these are the stats for last month:
>
>  1  log4j-bom 35178445
>  2  log4j-api 30598923
>  3  log4j-core15567816
>  4  log4j-to-slf4j14036879
>  5  log4j-slf4j-impl   8675173
>  6  log4j-1.2-api  3454601
>  7  log4j-jul  2120049
>  8  log4j-web  1964937
>  9  log4j-layout-template-json 1760437
> 10  log4j-slf4j2-impl  1013605
> 11  log4j-jcl   566636
> 12  log4j-appserver 245029
> 13  log4j-iostreams 209990
> 14  log4j-spring-boot87578
> 15  log4j-spring-cloud-config-client 38332
> 16  log4j-jakarta-web37351
> 17  log4j-jpl20295
> 18  log4j-flume-ng   14055
> 19  log4j-taglib 13989
> 20  log4j-couchdb12781
> 21  log4j-mongodb44623
> 22  log4j-kubernetes  2618
> 23  log4j-jpa 1252
> 24  log4j-mongodb31143
> 25  log4j-docker  1122
> 26  log4j-cassandra898
> 27  log4j-jakarta-smtp 741
> 28  log4j-jdbc-dbcp2   708
> 29  log4j-to-jul   297
>
> I propose to have a bar at 100k, so we keep everything up to
> `log4j-iostreams` + some modules under the line that are deemed
> important.
>
> I would keep `log4j-to-jul`, mainly because it is a third
> implementation of the Log4j API and I used it at work, when I didn't
> get the permission to use Log4j Core. NB: the `2.x` version of
> `log4j-to-jul` will still work with the `3.x` version of `log4j-api`,
> but it might require a modularized version to be fully compatible.
>
> The stats of `log4j-appserver` are unexpected. I guess the Jetty 9.x
> support drives it (Jetty 9.x reached EOL) more than the Tomcat
> support. So we could even deprecate this one and create a
> `log4j-tomcat` module or drop it entirely (I will pick up the Tomcat
> part in my `eu.copernik` modules).
>
> Piotr
>
> PS: The downloads of the 3.x modules split from `log4j-core` are not
> that great either. In the 

Re: Deprecating modules in 2.x

[Gary Gregory]

FWIW, I need all JDBC modules.

Gary

On Mon, Sep 11, 2023 at 4:00 AM Volkan Yazıcı  wrote:
>
> I would be in favor of deprecating the following modules in `2.x` and
> dropping them starting from `3.0.0`:
>
>1. `log4j-jndi` (available only in `main`) – nobody should use JNDI
>anyway
>2. `log4j-layout-jackson*` – `JsonTemplateLayout` succeeds `JsonLayout`,
>I doubt if anybody is using `XmlLayout`, nobody should use `YamlLayout`
>anyway
>3. `log4j-gelf` (available only in `main`) – JTL offers the same
>functionality, we just need to add a `CompressingLayout` (see LOG4J2-3023)
>and a resolver template (i.e., `gelf.json`)
>4. `log4j-jms` (available only in `main`)
>5. `log4j-csv` (available only in `main`)
>6. `log4j-jeromq`
>7. `log4j-cassandra`
>8. `log4j-smtp`
>9. `log4j-jakarta-smtp`
>10. `log4j-couchdb`
>11. `log4j-taglib`
>12. `log4j-mongodb3`
>13. `log4j-spring*` – we should try to upstream these to Spring Boot,
>otherwise to their own `apache/logging-*` repository
>14. `log4j-jdbc`
>15. `log4j-kafka` – we should either hand this out to the community or,
>if not rewrite, revamp it. In its current state
>
> ,
>it doesn't appear to be of production-grade quality.
>
> For the records, Romain Manni-Bucau created LOG4J2-1650
>  for a similar "diet".
> That was in 2016, since then things got sadly worse.
>
> We don't need to have a very strong consensus. As long as we have a
> proposal draft that everybody _roughly_ agrees on, we can announce this in
> every public medium we can think of (`dev@community`, `log4j-user@logging`,
> `dev@logging`, ASF planet, Twitter, etc.) and decide on the actual "cut"
> based on the feedback received.
>
> I don't want to derail the conversation at this stage, though I need to
> admit I have my reservations regarding the "please don't drop it because my
> employer uses it" argument. We can, preferably after the public feedback
> deadline, talk about it.
>
>
> On Sat, Sep 9, 2023 at 9:16 AM Piotr P. Karwasz 
> wrote:
>
> > Hi all,
> >
> > In a Slack discussion Volkan proposed (among other things) to:
> >
> >  * raise the Java requirements in 3.x to Java 17. It is the same
> > requirement as Spring Boot 3.x has, so I don't see a reason to lower
> > the bar. Besides Java 21 will be an LTS.
> >  * deprecate some modules in 2.x and drop them in 3.0.x, restore them
> > if a user requests it in 3.1.x.
> >
> > While the number of downloads is not the only criterium (a big company
> > with an internal Maven repo counts 1, a student's project that tries
> > multiple version counts more), these are the stats for last month:
> >
> >  1  log4j-bom 35178445
> >  2  log4j-api 30598923
> >  3  log4j-core15567816
> >  4  log4j-to-slf4j14036879
> >  5  log4j-slf4j-impl   8675173
> >  6  log4j-1.2-api  3454601
> >  7  log4j-jul  2120049
> >  8  log4j-web  1964937
> >  9  log4j-layout-template-json 1760437
> > 10  log4j-slf4j2-impl  1013605
> > 11  log4j-jcl   566636
> > 12  log4j-appserver 245029
> > 13  log4j-iostreams 209990
> > 14  log4j-spring-boot87578
> > 15  log4j-spring-cloud-config-client 38332
> > 16  log4j-jakarta-web37351
> > 17  log4j-jpl20295
> > 18  log4j-flume-ng   14055
> > 19  log4j-taglib 13989
> > 20  log4j-couchdb12781
> > 21  log4j-mongodb44623
> > 22  log4j-kubernetes  2618
> > 23  log4j-jpa 1252
> > 24  log4j-mongodb31143
> > 25  log4j-docker  1122
> > 26  log4j-cassandra898
> > 27  log4j-jakarta-smtp 741
> > 28  log4j-jdbc-dbcp2   708
> > 29  log4j-to-jul   297
> >
> > I propose to have a bar at 100k, so we keep everything up to
> > `log4j-iostreams` + some modules under the line that are deemed
> > important.
> >
> > I would keep `log4j-to-jul`, mainly because it is a third
> > implementation of the Log4j API and I used it at work, when I didn't
> > get the permission to use Log4j Core. NB: the `2.x` version of
> > `log4j-to-jul` will still work with the `3.x` version of `log4j-api`,
> > but it might require a modularized version to be fully compatible.
> >
> > The stats of `log4j-appserver` are unexpected. I guess the Jetty 9.x
> > support drives it (Jetty 9.x reached EOL) more 

Re: Deprecating modules in 2.x

[Gary Gregory]

We also use the CSV module (but only in some of our tests.)

Gary

On Mon, Sep 11, 2023 at 7:07 AM Gary Gregory  wrote:
>
> FWIW, I need all JDBC modules.
>
> Gary
>
> On Mon, Sep 11, 2023 at 4:00 AM Volkan Yazıcı  wrote:
> >
> > I would be in favor of deprecating the following modules in `2.x` and
> > dropping them starting from `3.0.0`:
> >
> >1. `log4j-jndi` (available only in `main`) – nobody should use JNDI
> >anyway
> >2. `log4j-layout-jackson*` – `JsonTemplateLayout` succeeds `JsonLayout`,
> >I doubt if anybody is using `XmlLayout`, nobody should use `YamlLayout`
> >anyway
> >3. `log4j-gelf` (available only in `main`) – JTL offers the same
> >functionality, we just need to add a `CompressingLayout` (see 
> > LOG4J2-3023)
> >and a resolver template (i.e., `gelf.json`)
> >4. `log4j-jms` (available only in `main`)
> >5. `log4j-csv` (available only in `main`)
> >6. `log4j-jeromq`
> >7. `log4j-cassandra`
> >8. `log4j-smtp`
> >9. `log4j-jakarta-smtp`
> >10. `log4j-couchdb`
> >11. `log4j-taglib`
> >12. `log4j-mongodb3`
> >13. `log4j-spring*` – we should try to upstream these to Spring Boot,
> >otherwise to their own `apache/logging-*` repository
> >14. `log4j-jdbc`
> >15. `log4j-kafka` – we should either hand this out to the community or,
> >if not rewrite, revamp it. In its current state
> >
> > ,
> >it doesn't appear to be of production-grade quality.
> >
> > For the records, Romain Manni-Bucau created LOG4J2-1650
> >  for a similar "diet".
> > That was in 2016, since then things got sadly worse.
> >
> > We don't need to have a very strong consensus. As long as we have a
> > proposal draft that everybody _roughly_ agrees on, we can announce this in
> > every public medium we can think of (`dev@community`, `log4j-user@logging`,
> > `dev@logging`, ASF planet, Twitter, etc.) and decide on the actual "cut"
> > based on the feedback received.
> >
> > I don't want to derail the conversation at this stage, though I need to
> > admit I have my reservations regarding the "please don't drop it because my
> > employer uses it" argument. We can, preferably after the public feedback
> > deadline, talk about it.
> >
> >
> > On Sat, Sep 9, 2023 at 9:16 AM Piotr P. Karwasz 
> > wrote:
> >
> > > Hi all,
> > >
> > > In a Slack discussion Volkan proposed (among other things) to:
> > >
> > >  * raise the Java requirements in 3.x to Java 17. It is the same
> > > requirement as Spring Boot 3.x has, so I don't see a reason to lower
> > > the bar. Besides Java 21 will be an LTS.
> > >  * deprecate some modules in 2.x and drop them in 3.0.x, restore them
> > > if a user requests it in 3.1.x.
> > >
> > > While the number of downloads is not the only criterium (a big company
> > > with an internal Maven repo counts 1, a student's project that tries
> > > multiple version counts more), these are the stats for last month:
> > >
> > >  1  log4j-bom 35178445
> > >  2  log4j-api 30598923
> > >  3  log4j-core15567816
> > >  4  log4j-to-slf4j14036879
> > >  5  log4j-slf4j-impl   8675173
> > >  6  log4j-1.2-api  3454601
> > >  7  log4j-jul  2120049
> > >  8  log4j-web  1964937
> > >  9  log4j-layout-template-json 1760437
> > > 10  log4j-slf4j2-impl  1013605
> > > 11  log4j-jcl   566636
> > > 12  log4j-appserver 245029
> > > 13  log4j-iostreams 209990
> > > 14  log4j-spring-boot87578
> > > 15  log4j-spring-cloud-config-client 38332
> > > 16  log4j-jakarta-web37351
> > > 17  log4j-jpl20295
> > > 18  log4j-flume-ng   14055
> > > 19  log4j-taglib 13989
> > > 20  log4j-couchdb12781
> > > 21  log4j-mongodb44623
> > > 22  log4j-kubernetes  2618
> > > 23  log4j-jpa 1252
> > > 24  log4j-mongodb31143
> > > 25  log4j-docker  1122
> > > 26  log4j-cassandra898
> > > 27  log4j-jakarta-smtp 741
> > > 28  log4j-jdbc-dbcp2   708
> > > 29  log4j-to-jul   297
> > >
> > > I propose to have a bar at 100k, so we keep everything up to
> > > `log4j-iostreams` + some modules under the line that are deemed
> > > important.
> > >
> > > I would keep `log4j-to-jul`, mainly because it is a third
> > > implementation of the Log4j API and I used it at work, when I didn't
> > > g

Re: Deprecating modules in 2.x

[Piotr P. Karwasz]

Hi Volkan,

On Mon, 11 Sept 2023 at 10:00, Volkan Yazıcı  wrote:
>
> I would be in favor of deprecating the following modules in `2.x` and
> dropping them starting from `3.0.0`:
>
>1. `log4j-jndi` (available only in `main`) – nobody should use JNDI
>anyway
>2. `log4j-layout-jackson*` – `JsonTemplateLayout` succeeds `JsonLayout`,
>I doubt if anybody is using `XmlLayout`, nobody should use `YamlLayout`
>anyway
>3. `log4j-gelf` (available only in `main`) – JTL offers the same
>functionality, we just need to add a `CompressingLayout` (see LOG4J2-3023)
>and a resolver template (i.e., `gelf.json`)
>4. `log4j-jms` (available only in `main`)
>5. `log4j-csv` (available only in `main`)
>6. `log4j-jeromq`
>7. `log4j-cassandra`
>8. `log4j-smtp`
>9. `log4j-jakarta-smtp`
>10. `log4j-couchdb`
>11. `log4j-taglib`
>12. `log4j-mongodb3`
>13. `log4j-spring*` – we should try to upstream these to Spring Boot,
>otherwise to their own `apache/logging-*` repository
>14. `log4j-jdbc`
>15. `log4j-kafka` – we should either hand this out to the community or,
>if not rewrite, revamp it. In its current state
>
> ,
>it doesn't appear to be of production-grade quality.

What about `kubernetes`, `docker` and `jpa`. Are these omissions intentional?

> I don't want to derail the conversation at this stage, though I need to
> admit I have my reservations regarding the "please don't drop it because my
> employer uses it" argument. We can, preferably after the public feedback
> deadline, talk about it.

Our employers are the Open Source equivalent of paying customers. If I
am not mistaken they allowed you to work on Log4j at one time or
another.
When Gary says "please don't drop..." I take it as a declaration that
he'll handle the issues filed against these modules (and he does do
it).

Piotr

Re: [VOTE] Release Apache Logging Parent 10.0.0 (RC4)

[Gary Gregory]

I don't think a parent pom requires busy work like a format vote.

See the board thread (if you have proper PMC access):
https://lists.apache.org/thread/k15gco2snsf9dsfkznp6289msn4vroq8
See my comment here
https://lists.apache.org/thread/fc6c0mvpjn4y6sw0kymqm3vjr4kr8obw

Gary

On Fri, Sep 8, 2023 at 10:09 AM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Logging Parent 10.0.0 (RC4).
>
> Source repository: https://github.com/apache/logging-parent
> Commit: 2af643f84ada9a05e08229d077c6fafee2fed732
> Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1168
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Please download, test, and cast your votes on this mailing list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
>
> # RC3..RC4 changes[1]
>
> - Fixed `revision` and BOM flattening
>
> [1] 
> https://github.com/apache/logging-parent/compare/9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce..2af643f84ada9a05e08229d077c6fafee2fed732
>
> # RC2..RC3 changes[2]
>
> - Fixed plugin definitions
>
> [2] 
> https://github.com/apache/logging-parent/compare/24a4b9bc706ed978f36c28c114e289547c4a71ad..9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce
>
> # RC1..RC2 changes[3]
>
> - Set version to `10.0.0` (requested by Matt & Ralph)
> - Fix SVN path in `generate-email.sh` (requested by Gary)
> - Split the distribution into `src` and `bin` parts (requested by Gary)
> - Automate `revision` property update in `pom.xml` in CI (requested by Ralph)
> - Automate changelog release in CI (requested by Ralph)
>
> [3] 
> https://github.com/apache/logging-parent/compare/3dd83461faa058690a5ed821ee81dfc2d744ec7c..24a4b9bc706ed978f36c28c114e289547c4a71ad
>
> # Remarks
>
> - `logging-parent` doesn't contain any binary artifacts, it is a
>   `pom.xml` with some reusable CI workflow YAMLs.
> - One can reproduce the very same distribution by checking
>   out the commit and running
>   `./mvnw -P distribution -DattachmentCount=0 -DattachmentFilepathPattern=x`
>
> # Release Notes
>
> This minor release contains various improvements that we expect to
> relieve the load on `pom.xml` and GitHub Actions workflows of
> Maven-based projects we parent. This is of particular importance while
> managing and cutting releases from multiple repositories.
> See `README.adoc` for the complete list of features and their usage.
>
> See this[3] `log4j-tools` GitHub Actions workflow run demonstrating a
> successful release cut using a SNAPSHOT version of this
> `logging-parent` release. All preparations (release notes, source and
> binary distributions, vote & announcement emails, etc.) are staged to
> both Nexus and SVN and waiting the release manager to proceed.
>
> [4] https://github.com/apache/logging-log4j-tools/actions/runs/6122466478
>
> ## Changes
>
> ### Added
>
> * Added `changelog-export` profile to easily export changelogs
>   to Markdown files
> * Added `changelog-release` profile to easily move
>   `src/changelog/.?.x.x` contents to their associated release directory
> * Added `deploy` profile to ease the Maven `deploy` goal
> * Added `distribution` profile to easily create a distribution file
>   containing Git-tracked sources, release notes, binary
>   attachments, `NOTICE.txt`, etc.
> * Documented release instructions (i.e., `RELEASING.md`)
> * Added `release` profile to share common release-specific
>   Maven configuration
> * Added reusable GitHub Actions workflows to share CI boilerplate
>   for other repositories
> * Switched to using `log4j-changelog-maven-plugin` for managing
>   changelog and release notes
>
> ### Changed
>
> * Switched to semantic versioning (old version: `9`,
>   new version: `10.0.0`)

Re: [VOTE] Release Apache Logging Parent 10.0.0 (RC4)

[Matt Sicker]

+1

> On Sep 8, 2023, at 9:07 AM, Volkan Yazıcı  wrote:
> 
> This is a vote to release the Apache Logging Parent 10.0.0 (RC4).
> 
> Source repository: https://github.com/apache/logging-parent
> Commit: 2af643f84ada9a05e08229d077c6fafee2fed732
> Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1168
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
> 
> Please download, test, and cast your votes on this mailing list.
> 
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
> 
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
> 
> # RC3..RC4 changes[1]
> 
> - Fixed `revision` and BOM flattening
> 
> [1] 
> https://github.com/apache/logging-parent/compare/9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce..2af643f84ada9a05e08229d077c6fafee2fed732
> 
> # RC2..RC3 changes[2]
> 
> - Fixed plugin definitions
> 
> [2] 
> https://github.com/apache/logging-parent/compare/24a4b9bc706ed978f36c28c114e289547c4a71ad..9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce
> 
> # RC1..RC2 changes[3]
> 
> - Set version to `10.0.0` (requested by Matt & Ralph)
> - Fix SVN path in `generate-email.sh` (requested by Gary)
> - Split the distribution into `src` and `bin` parts (requested by Gary)
> - Automate `revision` property update in `pom.xml` in CI (requested by Ralph)
> - Automate changelog release in CI (requested by Ralph)
> 
> [3] 
> https://github.com/apache/logging-parent/compare/3dd83461faa058690a5ed821ee81dfc2d744ec7c..24a4b9bc706ed978f36c28c114e289547c4a71ad
> 
> # Remarks
> 
> - `logging-parent` doesn't contain any binary artifacts, it is a
>  `pom.xml` with some reusable CI workflow YAMLs.
> - One can reproduce the very same distribution by checking
>  out the commit and running
>  `./mvnw -P distribution -DattachmentCount=0 -DattachmentFilepathPattern=x`
> 
> # Release Notes
> 
> This minor release contains various improvements that we expect to
> relieve the load on `pom.xml` and GitHub Actions workflows of
> Maven-based projects we parent. This is of particular importance while
> managing and cutting releases from multiple repositories.
> See `README.adoc` for the complete list of features and their usage.
> 
> See this[3] `log4j-tools` GitHub Actions workflow run demonstrating a
> successful release cut using a SNAPSHOT version of this
> `logging-parent` release. All preparations (release notes, source and
> binary distributions, vote & announcement emails, etc.) are staged to
> both Nexus and SVN and waiting the release manager to proceed.
> 
> [4] https://github.com/apache/logging-log4j-tools/actions/runs/6122466478
> 
> ## Changes
> 
> ### Added
> 
> * Added `changelog-export` profile to easily export changelogs
>  to Markdown files
> * Added `changelog-release` profile to easily move
>  `src/changelog/.?.x.x` contents to their associated release directory
> * Added `deploy` profile to ease the Maven `deploy` goal
> * Added `distribution` profile to easily create a distribution file
>  containing Git-tracked sources, release notes, binary
>  attachments, `NOTICE.txt`, etc.
> * Documented release instructions (i.e., `RELEASING.md`)
> * Added `release` profile to share common release-specific
>  Maven configuration
> * Added reusable GitHub Actions workflows to share CI boilerplate
>  for other repositories
> * Switched to using `log4j-changelog-maven-plugin` for managing
>  changelog and release notes
> 
> ### Changed
> 
> * Switched to semantic versioning (old version: `9`,
>  new version: `10.0.0`)

Re: Deprecating modules in 2.x

[Matt Sicker]

The Kubernetes and Docker plugins are for additional lookup variables, though 
based on how I’ve used Kubernetes at least (like via Kustomize, Helm, 
Spinnaker, and general YAML template tooling), I’ve relied mostly on binding 
anything relevant from the manifest into environment variables.

> On Sep 11, 2023, at 6:10 AM, Piotr P. Karwasz  wrote:
> 
> Hi Volkan,
> 
> On Mon, 11 Sept 2023 at 10:00, Volkan Yazıcı  > wrote:
>> 
>> I would be in favor of deprecating the following modules in `2.x` and
>> dropping them starting from `3.0.0`:
>> 
>>   1. `log4j-jndi` (available only in `main`) – nobody should use JNDI
>>   anyway
>>   2. `log4j-layout-jackson*` – `JsonTemplateLayout` succeeds `JsonLayout`,
>>   I doubt if anybody is using `XmlLayout`, nobody should use `YamlLayout`
>>   anyway
>>   3. `log4j-gelf` (available only in `main`) – JTL offers the same
>>   functionality, we just need to add a `CompressingLayout` (see LOG4J2-3023)
>>   and a resolver template (i.e., `gelf.json`)
>>   4. `log4j-jms` (available only in `main`)
>>   5. `log4j-csv` (available only in `main`)
>>   6. `log4j-jeromq`
>>   7. `log4j-cassandra`
>>   8. `log4j-smtp`
>>   9. `log4j-jakarta-smtp`
>>   10. `log4j-couchdb`
>>   11. `log4j-taglib`
>>   12. `log4j-mongodb3`
>>   13. `log4j-spring*` – we should try to upstream these to Spring Boot,
>>   otherwise to their own `apache/logging-*` repository
>>   14. `log4j-jdbc`
>>   15. `log4j-kafka` – we should either hand this out to the community or,
>>   if not rewrite, revamp it. In its current state
>>   
>> ,
>>   it doesn't appear to be of production-grade quality.
> 
> What about `kubernetes`, `docker` and `jpa`. Are these omissions intentional?
> 
>> I don't want to derail the conversation at this stage, though I need to
>> admit I have my reservations regarding the "please don't drop it because my
>> employer uses it" argument. We can, preferably after the public feedback
>> deadline, talk about it.
> 
> Our employers are the Open Source equivalent of paying customers. If I
> am not mistaken they allowed you to work on Log4j at one time or
> another.
> When Gary says "please don't drop..." I take it as a declaration that
> he'll handle the issues filed against these modules (and he does do
> it).
> 
> Piotr

Re: Deprecating modules in 2.x

[Ralph Goers]

I wrote the Docker and Kubernetes stuff for anyone who wants to bypass writing 
to the console and still have the environment variables captured. 

Ralph

> On Sep 11, 2023, at 9:40 AM, Matt Sicker  wrote:
> 
> The Kubernetes and Docker plugins are for additional lookup variables, though 
> based on how I’ve used Kubernetes at least (like via Kustomize, Helm, 
> Spinnaker, and general YAML template tooling), I’ve relied mostly on binding 
> anything relevant from the manifest into environment variables.
> 
>> On Sep 11, 2023, at 6:10 AM, Piotr P. Karwasz  
>> wrote:
>> 
>> Hi Volkan,
>> 
>> On Mon, 11 Sept 2023 at 10:00, Volkan Yazıcı > > wrote:
>>> 
>>> I would be in favor of deprecating the following modules in `2.x` and
>>> dropping them starting from `3.0.0`:
>>> 
>>>  1. `log4j-jndi` (available only in `main`) – nobody should use JNDI
>>>  anyway
>>>  2. `log4j-layout-jackson*` – `JsonTemplateLayout` succeeds `JsonLayout`,
>>>  I doubt if anybody is using `XmlLayout`, nobody should use `YamlLayout`
>>>  anyway
>>>  3. `log4j-gelf` (available only in `main`) – JTL offers the same
>>>  functionality, we just need to add a `CompressingLayout` (see LOG4J2-3023)
>>>  and a resolver template (i.e., `gelf.json`)
>>>  4. `log4j-jms` (available only in `main`)
>>>  5. `log4j-csv` (available only in `main`)
>>>  6. `log4j-jeromq`
>>>  7. `log4j-cassandra`
>>>  8. `log4j-smtp`
>>>  9. `log4j-jakarta-smtp`
>>>  10. `log4j-couchdb`
>>>  11. `log4j-taglib`
>>>  12. `log4j-mongodb3`
>>>  13. `log4j-spring*` – we should try to upstream these to Spring Boot,
>>>  otherwise to their own `apache/logging-*` repository
>>>  14. `log4j-jdbc`
>>>  15. `log4j-kafka` – we should either hand this out to the community or,
>>>  if not rewrite, revamp it. In its current state
>>>  
>>> ,
>>>  it doesn't appear to be of production-grade quality.
>> 
>> What about `kubernetes`, `docker` and `jpa`. Are these omissions intentional?
>> 
>>> I don't want to derail the conversation at this stage, though I need to
>>> admit I have my reservations regarding the "please don't drop it because my
>>> employer uses it" argument. We can, preferably after the public feedback
>>> deadline, talk about it.
>> 
>> Our employers are the Open Source equivalent of paying customers. If I
>> am not mistaken they allowed you to work on Log4j at one time or
>> another.
>> When Gary says "please don't drop..." I take it as a declaration that
>> he'll handle the issues filed against these modules (and he does do
>> it).
>> 
>> Piotr
> 

Re: [VOTE] Release Apache Logging Parent 10.0.0 (RC4)

[Christian Grobmeier]

+1


On Fri, Sep 8, 2023, at 16:07, Volkan Yazıcı wrote:
> This is a vote to release the Apache Logging Parent 10.0.0 (RC4).
>
> Source repository: https://github.com/apache/logging-parent
> Commit: 2af643f84ada9a05e08229d077c6fafee2fed732
> Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1168
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Please download, test, and cast your votes on this mailing list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
>
> # RC3..RC4 changes[1]
>
> - Fixed `revision` and BOM flattening
>
> [1] 
> https://github.com/apache/logging-parent/compare/9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce..2af643f84ada9a05e08229d077c6fafee2fed732
>
> # RC2..RC3 changes[2]
>
> - Fixed plugin definitions
>
> [2] 
> https://github.com/apache/logging-parent/compare/24a4b9bc706ed978f36c28c114e289547c4a71ad..9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce
>
> # RC1..RC2 changes[3]
>
> - Set version to `10.0.0` (requested by Matt & Ralph)
> - Fix SVN path in `generate-email.sh` (requested by Gary)
> - Split the distribution into `src` and `bin` parts (requested by Gary)
> - Automate `revision` property update in `pom.xml` in CI (requested by Ralph)
> - Automate changelog release in CI (requested by Ralph)
>
> [3] 
> https://github.com/apache/logging-parent/compare/3dd83461faa058690a5ed821ee81dfc2d744ec7c..24a4b9bc706ed978f36c28c114e289547c4a71ad
>
> # Remarks
>
> - `logging-parent` doesn't contain any binary artifacts, it is a
>   `pom.xml` with some reusable CI workflow YAMLs.
> - One can reproduce the very same distribution by checking
>   out the commit and running
>   `./mvnw -P distribution -DattachmentCount=0 -DattachmentFilepathPattern=x`
>
> # Release Notes
>
> This minor release contains various improvements that we expect to
> relieve the load on `pom.xml` and GitHub Actions workflows of
> Maven-based projects we parent. This is of particular importance while
> managing and cutting releases from multiple repositories.
> See `README.adoc` for the complete list of features and their usage.
>
> See this[3] `log4j-tools` GitHub Actions workflow run demonstrating a
> successful release cut using a SNAPSHOT version of this
> `logging-parent` release. All preparations (release notes, source and
> binary distributions, vote & announcement emails, etc.) are staged to
> both Nexus and SVN and waiting the release manager to proceed.
>
> [4] https://github.com/apache/logging-log4j-tools/actions/runs/6122466478
>
> ## Changes
>
> ### Added
>
> * Added `changelog-export` profile to easily export changelogs
>   to Markdown files
> * Added `changelog-release` profile to easily move
>   `src/changelog/.?.x.x` contents to their associated release directory
> * Added `deploy` profile to ease the Maven `deploy` goal
> * Added `distribution` profile to easily create a distribution file
>   containing Git-tracked sources, release notes, binary
>   attachments, `NOTICE.txt`, etc.
> * Documented release instructions (i.e., `RELEASING.md`)
> * Added `release` profile to share common release-specific
>   Maven configuration
> * Added reusable GitHub Actions workflows to share CI boilerplate
>   for other repositories
> * Switched to using `log4j-changelog-maven-plugin` for managing
>   changelog and release notes
>
> ### Changed
>
> * Switched to semantic versioning (old version: `9`,
>   new version: `10.0.0`)

Re: Framework for integration tests

[Matt Sicker]

Testcontainers is really neat, but it does require Docker, so I’m not sure how 
to best use it in CI (particularly outside Linux). Arquillian is a classic 
option that’s been around for as long as I’ve been using Java for server-side 
anything, though I never really figured out how to use it (it seems similar to 
Pax Exam, both of which confuse me). Finding how to reuse Maven modules in 
these test projects is the tricky part in my experience, though maybe that’s 
fairly easy to do these days.

> On Sep 10, 2023, at 2:51 PM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> During the discussion about splitting the main repo Ralph raised the
> problem that we don't have reliable integration tests.
> 
> Sure, most of our unit tests actually check the entire lifecycle of a
> logger context (which I think is a waste of testing time by the way),
> but these are single classloader Java SE deployments. What we don't
> test is:
> 
> * how Log4j behaves in real world deployments: application servers,
> servlet containers, Spring Boot applications, OSGI containers. Yes, we
> have **some** tests inside containers, especially for OSGI, but the
> bootstrap procedure is very different from what real containers use.
> E.g. when we programmatically load `log4j-api` and `log4j-core` in our
> tests, everything works fine, but our users report that this does not
> work in an Eclipse RCP application,
> * how different components work together: e.g. is it possible to log
> both to Cassandra and Flume?
> 
> I have looked a little bit around, what integration testing frameworks
> are out there:
> 
> 1. Development on PAX Exam[1] (OSGI testing + some servlet testing)
> has as far as I can tell stopped,
> 2. There is a new OSGI Test[2] project, but I didn't test what it actually 
> does,
> 3. Arquillian seems the most promising one with many container
> implementations[5] available, although we would need probably right
> some Log4j specific ones: e.g. a managed Tomcat container with Log4j
> artifacts in the right places,
> 4. Matt mentioned some time ago Testcontainers[6] that would allow us
> to test components against Docker images.
> 
> AFAIK, the first three create an appropriate deployable artifact (OSGI
> bundle, WAR file) from our test class and deploy it to a container. I
> am not sure how Testcontainers work.
> 
> Do you have any experience with these frameworks? Would it be useful
> to add a separate integration tests repo? Or just a Maven module? Or
> perhaps should we just add tests to the existing Maven modules?
> 
> Piotr
> 
> [1] https://github.com/ops4j/org.ops4j.pax.exam2
> [2] https://github.com/osgi/osgi-test
> [3] http://arquillian.org/
> [5] https://github.com/orgs/arquillian/repositories?q=arquillian-container
> [6] https://testcontainers.com/modules/

Re: [log4j] Moving JMX GUI to its own repo

[Matt Sicker]

I’d be alright with this. Considering the fact that we’d rather use JFR in 3.x 
for metrics-related stuff, offloading JMX stuff makes sense (especially a 
JConsole extension like this).

> On Sep 8, 2023, at 5:00 AM, Volkan Yazıcı  wrote:
> 
> I have created a dedicated repository for the `log4j-jmx-gui` module:
> `logging-log4j-jmx-gui`
> .
> 
>   - Git history is preserved
>   - Compiler is upgraded to Java 17 (still targeting Java 8)
>   - `README.adoc` created
>   - Docs are moved to `doc/manual.adoc`
>   - `log4j-changelog` integration added
>   - `pom.xml` is revamped
> 
> The complete list of changes can be found by comparing the `HEAD` against
> ae00f014
> 
> .
> 
> *I will release this (in a separate VOTE thread) as version `0.21.0` and
> remove the module from `logging-log4j2` repository.* Thoughts? Objections?
> 
> Note that this is *not* an attempt to move to multi-repo!