[log4cxx] Release time?
It's been a bit over 6 months since the last release, is it time for a new release? There aren't many new features that would impact a lot of people, but a good number of maintenance fixes. -Robert Middleton
Re: [log4j] Unstable tests on Windows
The GH CI builds on every push (as opposed to commi) IIRC. Gary On Mon, Nov 20, 2023, 9:34 AM Ralph Goers wrote: > Gary uses Windows as his development OS. He is probably the only one of us > who does. So he inevitably finds these issues before the rest of us. > > I don’t know if the CI has a build that runs on Windows for every commit. > > Ralph > > > On Nov 20, 2023, at 6:12 AM, Robert Middleton > wrote: > > > > Are the tests run on Windows through Github workflows? It doesn't > > look like it to me. > > > > If you need access to a Windows machine, you can download a > > development VM straight from Microsoft: > > > https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ > > > > -Robert Middleton > > > > On Mon, Nov 20, 2023 at 7:40 AM Apache > wrote: > >> > >> In my experience they never get fixed. To be honest, when I was doing > the releases I would have these failures investigated to determine if it > was a trait problem vs a problem in the code being released. If it was the > latter I would cancel the vote. The only time tests should be disabled is > if we know it is a problem in the test but can’t figure out how to fix it. > >> > >> I also don’t ever recall Gary ever having more than one or two tests > fail in a run. > >> > >> Ralph > >> > >>> On Nov 20, 2023, at 5:00 AM, Volkan Yazıcı wrote: > >>> > >>> I am not asking to disable Windows tests. I am asking to disable tests > >>> and only those tests that have a failure rate on Windows higher than, > >>> say, 30%. To be precise, I think there are 2-3 of them dealing with > >>> network sockets and rolling file appenders. I am not talking about > >>> dozens or such. > >>> > >>> After disabling them, we can create a ticket referencing them. So that > >>> interested parties can fix them. > >>> > On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz > wrote: > > Hi Volkan, > > > On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı wrote: > > > > As Gary (the only Windows user among the active Log4j maintainers, > > AFAIK) has noticed several times, Log4j tests on Windows are pretty > > unstable. It not only fails on Gary's laptop, but Piotr and I need to > > give Windows tests in CI a kick on a regular basis. Approximately one > > out of three CI runs fails on Windows. Piotr already improved the > > situation extensively, though there are still several leftovers that > > need attention. > > > > Unless somebody steps up to improve the unstable Windows tests, I > > would like to disable those only for the WIndows platform. > > Please don't. Windows has an annoying file locking policy that > prevents users from deleting files with open file descriptors, but > that is one of the few ways to detect resource leakage we have. > > Tests running on *NIXes will ignore problems with open file > descriptors and delete the log files, but on a production system those > leaks will accumulate and cause application crashes. We had such a > leak, when we used `URLConnection#getLastModified` on a `jar:...` URL. > This call caused file descriptor exhaustion on both Windows and > *NIXes, but only the Windows test was able to detect it. > > Piotr, > who never thought would ever defend Microsoft Windows. > > PS: Gary reports the failures, but always runs the build again until > it succeeds, even on Friday 13th, when he had to wait until Saturday > 14th for the test run to succeed. > >> > >
Re: [log4j] Unstable tests on Windows
Gary uses Windows as his development OS. He is probably the only one of us who does. So he inevitably finds these issues before the rest of us. I don’t know if the CI has a build that runs on Windows for every commit. Ralph > On Nov 20, 2023, at 6:12 AM, Robert Middleton wrote: > > Are the tests run on Windows through Github workflows? It doesn't > look like it to me. > > If you need access to a Windows machine, you can download a > development VM straight from Microsoft: > https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ > > -Robert Middleton > > On Mon, Nov 20, 2023 at 7:40 AM Apache wrote: >> >> In my experience they never get fixed. To be honest, when I was doing the >> releases I would have these failures investigated to determine if it was a >> trait problem vs a problem in the code being released. If it was the latter >> I would cancel the vote. The only time tests should be disabled is if we >> know it is a problem in the test but can’t figure out how to fix it. >> >> I also don’t ever recall Gary ever having more than one or two tests fail in >> a run. >> >> Ralph >> >>> On Nov 20, 2023, at 5:00 AM, Volkan Yazıcı wrote: >>> >>> I am not asking to disable Windows tests. I am asking to disable tests >>> and only those tests that have a failure rate on Windows higher than, >>> say, 30%. To be precise, I think there are 2-3 of them dealing with >>> network sockets and rolling file appenders. I am not talking about >>> dozens or such. >>> >>> After disabling them, we can create a ticket referencing them. So that >>> interested parties can fix them. >>> On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz wrote: Hi Volkan, > On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı wrote: > > As Gary (the only Windows user among the active Log4j maintainers, > AFAIK) has noticed several times, Log4j tests on Windows are pretty > unstable. It not only fails on Gary's laptop, but Piotr and I need to > give Windows tests in CI a kick on a regular basis. Approximately one > out of three CI runs fails on Windows. Piotr already improved the > situation extensively, though there are still several leftovers that > need attention. > > Unless somebody steps up to improve the unstable Windows tests, I > would like to disable those only for the WIndows platform. Please don't. Windows has an annoying file locking policy that prevents users from deleting files with open file descriptors, but that is one of the few ways to detect resource leakage we have. Tests running on *NIXes will ignore problems with open file descriptors and delete the log files, but on a production system those leaks will accumulate and cause application crashes. We had such a leak, when we used `URLConnection#getLastModified` on a `jar:...` URL. This call caused file descriptor exhaustion on both Windows and *NIXes, but only the Windows test was able to detect it. Piotr, who never thought would ever defend Microsoft Windows. PS: Gary reports the failures, but always runs the build again until it succeeds, even on Friday 13th, when he had to wait until Saturday 14th for the test run to succeed. >>
Re: [log4j] Unstable tests on Windows
Are the tests run on Windows through Github workflows? It doesn't look like it to me. If you need access to a Windows machine, you can download a development VM straight from Microsoft: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ -Robert Middleton On Mon, Nov 20, 2023 at 7:40 AM Apache wrote: > > In my experience they never get fixed. To be honest, when I was doing the > releases I would have these failures investigated to determine if it was a > trait problem vs a problem in the code being released. If it was the latter I > would cancel the vote. The only time tests should be disabled is if we know > it is a problem in the test but can’t figure out how to fix it. > > I also don’t ever recall Gary ever having more than one or two tests fail in > a run. > > Ralph > > > On Nov 20, 2023, at 5:00 AM, Volkan Yazıcı wrote: > > > > I am not asking to disable Windows tests. I am asking to disable tests > > and only those tests that have a failure rate on Windows higher than, > > say, 30%. To be precise, I think there are 2-3 of them dealing with > > network sockets and rolling file appenders. I am not talking about > > dozens or such. > > > > After disabling them, we can create a ticket referencing them. So that > > interested parties can fix them. > > > >> On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz > >> wrote: > >> > >> Hi Volkan, > >> > >>> On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı wrote: > >>> > >>> As Gary (the only Windows user among the active Log4j maintainers, > >>> AFAIK) has noticed several times, Log4j tests on Windows are pretty > >>> unstable. It not only fails on Gary's laptop, but Piotr and I need to > >>> give Windows tests in CI a kick on a regular basis. Approximately one > >>> out of three CI runs fails on Windows. Piotr already improved the > >>> situation extensively, though there are still several leftovers that > >>> need attention. > >>> > >>> Unless somebody steps up to improve the unstable Windows tests, I > >>> would like to disable those only for the WIndows platform. > >> > >> Please don't. Windows has an annoying file locking policy that > >> prevents users from deleting files with open file descriptors, but > >> that is one of the few ways to detect resource leakage we have. > >> > >> Tests running on *NIXes will ignore problems with open file > >> descriptors and delete the log files, but on a production system those > >> leaks will accumulate and cause application crashes. We had such a > >> leak, when we used `URLConnection#getLastModified` on a `jar:...` URL. > >> This call caused file descriptor exhaustion on both Windows and > >> *NIXes, but only the Windows test was able to detect it. > >> > >> Piotr, > >> who never thought would ever defend Microsoft Windows. > >> > >> PS: Gary reports the failures, but always runs the build again until > >> it succeeds, even on Friday 13th, when he had to wait until Saturday > >> 14th for the test run to succeed. >
Re: [log4j] Unstable tests on Windows
In my experience they never get fixed. To be honest, when I was doing the releases I would have these failures investigated to determine if it was a trait problem vs a problem in the code being released. If it was the latter I would cancel the vote. The only time tests should be disabled is if we know it is a problem in the test but can’t figure out how to fix it. I also don’t ever recall Gary ever having more than one or two tests fail in a run. Ralph > On Nov 20, 2023, at 5:00 AM, Volkan Yazıcı wrote: > > I am not asking to disable Windows tests. I am asking to disable tests > and only those tests that have a failure rate on Windows higher than, > say, 30%. To be precise, I think there are 2-3 of them dealing with > network sockets and rolling file appenders. I am not talking about > dozens or such. > > After disabling them, we can create a ticket referencing them. So that > interested parties can fix them. > >> On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz >> wrote: >> >> Hi Volkan, >> >>> On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı wrote: >>> >>> As Gary (the only Windows user among the active Log4j maintainers, >>> AFAIK) has noticed several times, Log4j tests on Windows are pretty >>> unstable. It not only fails on Gary's laptop, but Piotr and I need to >>> give Windows tests in CI a kick on a regular basis. Approximately one >>> out of three CI runs fails on Windows. Piotr already improved the >>> situation extensively, though there are still several leftovers that >>> need attention. >>> >>> Unless somebody steps up to improve the unstable Windows tests, I >>> would like to disable those only for the WIndows platform. >> >> Please don't. Windows has an annoying file locking policy that >> prevents users from deleting files with open file descriptors, but >> that is one of the few ways to detect resource leakage we have. >> >> Tests running on *NIXes will ignore problems with open file >> descriptors and delete the log files, but on a production system those >> leaks will accumulate and cause application crashes. We had such a >> leak, when we used `URLConnection#getLastModified` on a `jar:...` URL. >> This call caused file descriptor exhaustion on both Windows and >> *NIXes, but only the Windows test was able to detect it. >> >> Piotr, >> who never thought would ever defend Microsoft Windows. >> >> PS: Gary reports the failures, but always runs the build again until >> it succeeds, even on Friday 13th, when he had to wait until Saturday >> 14th for the test run to succeed.
Re: [log4j] Unstable tests on Windows
I am not asking to disable Windows tests. I am asking to disable tests and only those tests that have a failure rate on Windows higher than, say, 30%. To be precise, I think there are 2-3 of them dealing with network sockets and rolling file appenders. I am not talking about dozens or such. After disabling them, we can create a ticket referencing them. So that interested parties can fix them. On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz wrote: > > Hi Volkan, > > On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı wrote: > > > > As Gary (the only Windows user among the active Log4j maintainers, > > AFAIK) has noticed several times, Log4j tests on Windows are pretty > > unstable. It not only fails on Gary's laptop, but Piotr and I need to > > give Windows tests in CI a kick on a regular basis. Approximately one > > out of three CI runs fails on Windows. Piotr already improved the > > situation extensively, though there are still several leftovers that > > need attention. > > > > Unless somebody steps up to improve the unstable Windows tests, I > > would like to disable those only for the WIndows platform. > > Please don't. Windows has an annoying file locking policy that > prevents users from deleting files with open file descriptors, but > that is one of the few ways to detect resource leakage we have. > > Tests running on *NIXes will ignore problems with open file > descriptors and delete the log files, but on a production system those > leaks will accumulate and cause application crashes. We had such a > leak, when we used `URLConnection#getLastModified` on a `jar:...` URL. > This call caused file descriptor exhaustion on both Windows and > *NIXes, but only the Windows test was able to detect it. > > Piotr, > who never thought would ever defend Microsoft Windows. > > PS: Gary reports the failures, but always runs the build again until > it succeeds, even on Friday 13th, when he had to wait until Saturday > 14th for the test run to succeed.
Re: [log4j] Unstable tests on Windows
Hi Volkan, On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı wrote: > > As Gary (the only Windows user among the active Log4j maintainers, > AFAIK) has noticed several times, Log4j tests on Windows are pretty > unstable. It not only fails on Gary's laptop, but Piotr and I need to > give Windows tests in CI a kick on a regular basis. Approximately one > out of three CI runs fails on Windows. Piotr already improved the > situation extensively, though there are still several leftovers that > need attention. > > Unless somebody steps up to improve the unstable Windows tests, I > would like to disable those only for the WIndows platform. Please don't. Windows has an annoying file locking policy that prevents users from deleting files with open file descriptors, but that is one of the few ways to detect resource leakage we have. Tests running on *NIXes will ignore problems with open file descriptors and delete the log files, but on a production system those leaks will accumulate and cause application crashes. We had such a leak, when we used `URLConnection#getLastModified` on a `jar:...` URL. This call caused file descriptor exhaustion on both Windows and *NIXes, but only the Windows test was able to detect it. Piotr, who never thought would ever defend Microsoft Windows. PS: Gary reports the failures, but always runs the build again until it succeeds, even on Friday 13th, when he had to wait until Saturday 14th for the test run to succeed.
[ANNOUNCE] Apache Log4j Tools 0.6.0 released
The Apache Log4j Tools team is pleased to announce the 0.6.0 release. This project provides tooling internally used by the Apache Log4j project. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/tools === Release Notes This minor release contains various bug fixes and improvements. Added * Started generating CycloneDX SBOM with the recent update of `logging-parent` to version `10.4.0` Changed * Update `org.apache.logging:logging-parent` to version `10.4.0` Fixed * `log4j-tools-bom` was broken due to removed `parent` during flattening. This is automatically fixed by the recent `logging-parent` version `10.4.0` update.
Re: [VOTE] Release Apache Log4j Tools 0.6.0 (RC2)
Adding my +1. With that, the release passes with 3 binding +1 votes from Piotr, Gary, and myself. I will continue the release process. On Fri, Nov 17, 2023 at 10:21 AM Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Tools 0.6.0 (RC2). > > Website: https://logging.staged.apache.org/log4j/tools > GitHub: https://github.com/apache/logging-log4j-tools > Commit: a696e081304cc0693d86533013df5b4d886cfb9c > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1237 > 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 24 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. > > === Note on 24 hours deadline > > RC1 vote was created 2 days ago. RC2 only contains missing CycloneDX > SBOMs in the distribution archived by ASF. Note that SBOMs in the > Nexus were already working in RC1. Hence, an extra 24 hours would make > it all add up to 72 hours. > > === Release Notes > > This minor release contains various bug fixes and improvements. > > Added > > * Started generating CycloneDX SBOM with the recent update of > `logging-parent` to version `10.4.0` > > Changed > > * Update `org.apache.logging:logging-parent` to version `10.4.0` > > Fixed > > * `log4j-tools-bom` was broken due to removed `parent` during > flattening. This is automatically fixed by the recent `logging-parent` > version `10.4.0` update.
[ANNOUNCE] Apache Log4j JMX GUI 2.22.0 released
Apache Log4j JMX GUI[1] team is pleased to announce the 2.22.0 release. This project provides a Swing-based client for remotely editing the Log4j configuration and remotely monitoring `StatusLogger` output. It can be run as a standalone application or as a JConsole plugin. [1] https://logging.apache.org/log4j/jmx-gui == Release notes This release contains minor improvements. === Added * Started generating CycloneDX SBOM with the recent update of `logging-parent` to version `10.4.0` * Publish the website[1] === Changed * Add OSGi and JPMS descriptors * Update `log4j-core` to version `2.21.1` * Update `logging-parent` to version `10.4.0` === Fixed * Restore the original Maven `groupId`: `org.apache.logging.log4j`
Re: [VOTE] Release Apache Log4j JMX GUI 2.22.0
Adding my +1. With that, the release passes with 3 binding +1 votes from Piotr, Gary, and myself. I will continue the release process. On Wed, Nov 15, 2023 at 4:47 PM Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j JMX GUI 2.22.0. > > Website: https://logging.staged.apache.org/log4j/jmx-gui > GitHub: https://github.com/apache/logging-log4j-jmx-gui > Commit: a61f686edfd0d5c9591b98b80ebcfb533bebe23e > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-jmx-gui > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1234 > 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. > > === Release Notes > > This release contains minor improvements. > > === Added > > * Started generating CycloneDX SBOM with the recent update of > `logging-parent` to version `10.4.0` > * Publish the website[1] > > [1] https://logging.apache.org/log4j/jmx-gui > > === Changed > > * Add OSGi and JPMS descriptors > * Update `log4j-core` to version `2.21.1` > * Update `logging-parent` to version `10.4.0` > > === Fixed > > * Restore the original Maven `groupId`: `org.apache.logging.log4j`
[log4j] Unstable tests on Windows
As Gary (the only Windows user among the active Log4j maintainers,
AFAIK) has noticed several times, Log4j tests on Windows are pretty
unstable. It not only fails on Gary's laptop, but Piotr and I need to
give Windows tests in CI a kick on a regular basis. Approximately one
out of three CI runs fails on Windows. Piotr already improved the
situation extensively, though there are still several leftovers that
need attention.
Unless somebody steps up to improve the unstable Windows tests, I
would like to disable those only for the WIndows platform.
-- Forwarded message -
From: Gary D. Gregory
Date: Fri, Nov 17, 2023 at 3:03 PM
Subject: Re: [VOTE] Release Apache Log4j 2.22.0
To:
Build failure for me on Windows from the src zip and 'mvn clean verify':
[ERROR] Failures:
[ERROR] RollingAppenderDeleteMaxDepthTest.testAppender:73
[target\rolling-with-delete-depth\test\1,
target\rolling-with-delete-depth\test\2,
target\rolling-with-delete-depth\test\test-1.log,
target\rolling-with-delete-depth\test\test-2.log,
target\rolling-with-delete-depth\test\test-3.log,
target\rolling-with-delete-depth\test\test-4.log] expected:<5> but
was:<6>
[ERROR] RollingAppenderDeleteScriptTest.testAppender:73
target\rolling-with-delete-script\test\test-2.log should have odd
index
[ERROR]
AsyncThreadContextCopyOnWriteTest.testAsyncLogWritesToLog:35->AbstractAsyncThreadContextTestBase.testAsyncLogWritesToLog:171->AbstractAsyncThreadContextTestBase.checkResult:204
[Log file 'AsyncLoggerTest.log']
expected: "INFO c.f.Bar mapvalue [stackvalue] {KEY=mapvalue,
configProp=configValue, configProp2=configValue2} COPY_ON_WRITE
CopyOnWriteSortedArrayThreadContextMap AsyncLoggerContext i=0"
but was: "INFO c.f.Bar mapvalue [stackvalue, stackvalue]
{KEY=mapvalue, configProp=configValue, configProp2=configValue2}
COPY_ON_WRITE CopyOnWriteSortedArrayThreadContextMap
AsyncLoggerContext i=0"
[ERROR]
AsyncThreadContextGarbageFreeTest.testAsyncLogWritesToLog:35->AbstractAsyncThreadContextTestBase.testAsyncLogWritesToLog:171->AbstractAsyncThreadContextTestBase.checkResult:204
[Log file 'AsyncLoggerTest.log']
expected: "INFO c.f.Bar mapvalue [stackvalue] {KEY=mapvalue,
configProp=configValue, configProp2=configValue2} GARBAGE_FREE
GarbageFreeSortedArrayThreadContextMap AsyncLoggerContext i=0"
but was: "INFO c.f.Bar mapvalue [stackvalue, stackvalue]
{KEY=mapvalue, configProp=configValue, configProp2=configValue2}
GARBAGE_FREE GarbageFreeSortedArrayThreadContextMap AsyncLoggerContext
i=0"
[ERROR] Errors:
[ERROR]
AsyncThreadContextCopyOnWriteTest.testAsyncLogWritesToLog:35->AbstractAsyncThreadContextTestBase.testAsyncLogWritesToLog:159
» ConditionTimeout Condition with lambda expression in
org.apache.logging.log4j.core.async.AbstractAsyncThreadContextTestBase
that uses org.apache.logging.log4j.core.jmx.RingBufferAdmin was not
fulfilled within 500 milliseconds.
[ERROR]
AsyncThreadContextGarbageFreeTest.testAsyncLogWritesToLog:35->AbstractAsyncThreadContextTestBase.testAsyncLogWritesToLog:159
» ConditionTimeout Condition with lambda expression in
org.apache.logging.log4j.core.async.AbstractAsyncThreadContextTestBase
that uses org.apache.logging.log4j.core.jmx.RingBufferAdmin was not
fulfilled within 500 milliseconds.
[INFO]
[ERROR] Tests run: 2452, Failures: 4, Errors: 2, Skipped: 35
All that I could capture in the console is here: https://paste.apache.org/k6auj
- Testing src zip file
- OK: ASC verify
- OK SHA check
- mvn clean verify
Using:
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: C:\java\apache-maven-3.9.5
Java version: 11.0.20, vendor: Eclipse Adoptium, runtime: C:\Program
Files\Eclipse Adoptium\jdk-11.0.20.8-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Microsoft Windows [Version 10.0.19045.3570]
Gary
On 2023/11/17 12:07:06 Volkan Yazıcı wrote:
> This is a vote to release the Apache Log4j 2.22.0.
>
> Website: https://logging.staged.apache.org/log4j
> GitHub: https://github.com/apache/logging-log4j2
> Commit: a1634d695e5702ecab505fea5aadaf9890641487
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1238
> 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.
>
> == Review kit
>
> The minimum set of steps needed to review the uploaded distribution
> files can be summarized as follows:
>
> # Verify checksums
> shasum --check *.sha512
>
> # Verify signatures
> for sigFile in *.asc; do gpg --verify $sigFile; done
>
> # Verify reproduciblity
>
[ANNOUNCE] Apache Log4j 2.22.0 released
The Apache Log4j team is pleased to announce the 2.22.0 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j == Release notes This release provides a CycloneDX Software Bill of Materials (SBOM)[2] along with each artifact and contains bug fixes addressing issues in the JPMS & OSGi infrastructure overhauled in `2.21.0`, dependency updates, and some other minor fixes and improvements. [2] https://cyclonedx.org/capabilities/sbom === CycloneDX Software Bill of Materials (SBOM) This is the first Log4j release that provides a CycloneDX Software Bill of Materials (SBOM)[2] along with each artifact. Generated SBOMs are attached as artifacts with `cyclonedx` classifier and XML extensions, that is, `--cyclonedx.xml`. They contain `vulnerability-assertion` references to a CycloneDX Vulnerability Disclosure Report (VDR)[3] that Apache Logging Services uses for all projects it maintains. This VDR is accessible through the following URL: https://logging.apache.org/cyclonedx/vdr.xml SBOM generation is streamlined by `logging-parent`, see its website[4] for details. [3] https://cyclonedx.org/capabilities/vdr [4] https://logging.apache.org/logging-parent/latest/#cyclonedx-sbom === Changed * Change the order of evaluation of `FormattedMessage` formatters. Messages are evaluated using `java.util.Format` only if they don't comply to the `java.text.MessageFormat` or `ParameterizedMessage` format. (#1223) * Change default encoding of HTTP Basic Authentication to UTF-8 and add `log4j2.configurationAuthorizationEncoding` property to overwrite it. (#1970) * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.0` (#1974) * Update `com.github.luben:zstd-jni` to version `1.5.5-10` (#1940) * Update `com.google.guava:guava` to version `32.1.3-jre` (#1875) * Update `io.netty:netty-bom` to version `4.1.101.Final` (#1960) * Update `org.eclipse.persistence:org.eclipse.persistence.jpa` to version `2.7.13` (#1900) * Update `org.fusesource.jansi:jansi` to version `2.4.1` (#1907) * Update `org.mongodb:bson` to version `4.11.1` (#1957) * Update `org.springframework:spring-framework-bom` to version `5.3.30` * Update `org.springframework.boot:spring-boot` to version `2.7.17` (#1874) * Update `org.springframework:spring-framework-bom` to version `5.3.31` (#1973) * Update `org.zeromq:jeromq` to version `0.5.4` (#1878) === Removed * Removed unused `FastDateParser` which was causing unnecessary heap overhead (LOG4J2-3672, #1848) === Fixed * Fix MDC pattern converter causing issues for `%notEmpty` (#1922) * Export missing OSGi & JPMS modules in `log4j-layout-template-json` and `log4j-1.2-api` (#1895) * Fix `spring-test` dependency scope change (LOG4J2-3675) * Fix JPMS descriptors causing `jlink` issues (#1896) * Add missing `Implementation-` and `Specification-` entries to `MANIFEST.MF` (implemented by `logging-parent` version `10.3.0` update) (#1923) * Fix `NotSerializableException` thrown when `Logger` is serialized with a `ReusableMessageFactory` (#1884)
Re: [VOTE] Release Apache Log4j 2.22.0
Adding my +1. With that, the release passes with 3 binding +1 votes from Gary, Piotr, and myself. I will continue the release process. On Fri, Nov 17, 2023 at 1:07 PM Volkan Yazıcı wrote: > This is a vote to release the Apache Log4j 2.22.0. > > Website: https://logging.staged.apache.org/log4j > GitHub: https://github.com/apache/logging-log4j2 > Commit: a1634d695e5702ecab505fea5aadaf9890641487 > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1238 > 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. > > == Review kit > > The minimum set of steps needed to review the uploaded distribution > files can be summarized as follows: > > # Verify checksums > shasum --check *.sha512 > > # Verify signatures > for sigFile in *.asc; do gpg --verify $sigFile; done > > # Verify reproduciblity > umask 0022 > unzip *-src.zip -d src > cd src > export NEXUS_REPO= > https://repository.apache.org/content/repositories/orgapachelogging-1238 > sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO > > == Release notes > > This release provides a CycloneDX Software Bill of Materials (SBOM)[1] > along with each artifact and contains bug fixes addressing issues in > the JPMS & OSGi infrastructure overhauled in `2.21.0`, dependency > updates, and some other minor fixes and improvements. > > [1] https://cyclonedx.org/capabilities/sbom > > === CycloneDX Software Bill of Materials (SBOM) > > This is the first Log4j release that provides a CycloneDX Software > Bill of Materials (SBOM)[1] along with each artifact. Generated SBOMs > are attached as artifacts with `cyclonedx` classifier and XML > extensions, that is, `--cyclonedx.xml`. They > contain `vulnerability-assertion` references to a CycloneDX > Vulnerability Disclosure Report (VDR)[2] that Apache Logging Services > uses for all projects it maintains. This VDR is accessible through the > following URL: https://logging.apache.org/cyclonedx/vdr.xml > > SBOM generation is streamlined by `logging-parent`, see its website[3] > for details. > > [2] https://cyclonedx.org/capabilities/vdr > [3] https://logging.apache.org/logging-parent/latest/#cyclonedx-sbom > > === Changed > > * Change the order of evaluation of `FormattedMessage` formatters. > Messages are evaluated using `java.util.Format` only if they don't > comply to the `java.text.MessageFormat` or `ParameterizedMessage` > format. (#1223) > * Change default encoding of HTTP Basic Authentication to UTF-8 and > add `log4j2.configurationAuthorizationEncoding` property to overwrite > it. (#1970) > * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.0` (#1974) > * Update `com.github.luben:zstd-jni` to version `1.5.5-10` (#1940) > * Update `com.google.guava:guava` to version `32.1.3-jre` (#1875) > * Update `io.netty:netty-bom` to version `4.1.101.Final` (#1960) > * Update `org.eclipse.persistence:org.eclipse.persistence.jpa` to > version `2.7.13` (#1900) > * Update `org.fusesource.jansi:jansi` to version `2.4.1` (#1907) > * Update `org.mongodb:bson` to version `4.11.1` (#1957) > * Update `org.springframework:spring-framework-bom` to version `5.3.30` > * Update `org.springframework.boot:spring-boot` to version `2.7.17` (#1874) > * Update `org.springframework:spring-framework-bom` to version `5.3.31` > (#1973) > * Update `org.zeromq:jeromq` to version `0.5.4` (#1878) > > === Removed > > * Removed unused `FastDateParser` which was causing unnecessary heap > overhead (LOG4J2-3672, #1848) > > === Fixed > > * Fix MDC pattern converter causing issues for `%notEmpty` (#1922) > * Export missing OSGi & JPMS modules in `log4j-layout-template-json` > and `log4j-1.2-api` (#1895) > * Fix `spring-test` dependency scope change (LOG4J2-3675) > * Fix JPMS descriptors causing `jlink` issues (#1896) > * Add missing `Implementation-` and `Specification-` entries to > `MANIFEST.MF` (implemented by `logging-parent` version `10.3.0` > update) (#1923) > * Fix `NotSerializableException` thrown when `Logger` is serialized > with a `ReusableMessageFactory` (#1884) >
