Re: Author lines in documentation

[Gary Gregory]

Agreed. The commit history is the best source of authorship anyway.

Gary

On Tue, May 14, 2024, 12:05 PM Ralph Goers 
wrote:

> IMO, yes. I had them due to something needed them in the tooling we used
> to use. But like code, tags in the docs aren’t very valuable.
>
> Ralph
>
> > On May 14, 2024, at 8:00 AM, Piotr P. Karwasz 
> wrote:
> >
> > Can we remove author lines in documentation pages?
> >
> > These lines are becoming crowded and somehow IntelliJ IDEA formats
> > author lines badly (i.e. inserts a blank line before them and they end
> > up in the text.
> >
> > Of course this doesn't need to be a PMC decision: when I reformat a
> > page I'll remove the names of the authors that are OK with it (and I
> > won't add mine ;-) ).
> >
> > Piotr
>
>

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

[Gary Gregory]

And for main: https://github.com/apache/logging-log4j2/pull/2493

Gary

On Thu, Apr 18, 2024 at 10:21 AM Gary D. Gregory  wrote:
>
> TY for your help Piotr.
>
> The PR for the 2.x part is here 
> https://github.com/apache/logging-log4j2/pull/2486
>
> Gary
>
> On 2024/04/18 02:58:39 "Gary D. Gregory" wrote:
> > Hi Piotr,
> >
> > Please see the branch feature/2.x/mongodb-next and its failing tests.
> >
> > TY,
> > Gary
> >
> > On 2024/04/17 21:59:45 "Gary D. Gregory" wrote:
> > > This is the plan that Piotr and I came up with one addition (1c):
> > >
> > > 1. Branch 2.x
> > > 1.a. Drop module log4j-mongodb3
> > > 1.b. Add module log4j-mongodb (no number) that contains one class that 
> > > instantiates the log4j-mongodb4 provider. XML element is MongoDb.
> > > 1.c. Deprecate module log4j-mongodb4 in favor of log4j-mongodb
> > >
> > > 2. Branch main
> > > 2.a. Rename module log4j-mongodb4 to module log4j-mongodb
> > > 2.b. Rename XML element MongoDb4 to MongoDb
> > >
> > > Gary
> > >
> > > On 2024/04/17 19:49:40 "Piotr P. Karwasz" wrote:
> > > > Hi Gary,
> > > >
> > > > On Wed, 17 Apr 2024 at 21:23, Gary Gregory  
> > > > wrote:
> > > > > But then your config has to say  AND depend on the mongodb5
> > > > > module! Still confusing 
> > > >
> > > > There is actually a rarely used feature of our plugin system, where a
> > > > plugin named `Foo` can actually create an object of type `Bar`. See
> > > > for example the `LoggerConfig.Root` plugin that actually creates an
> > > > object of type `LoggerConfig`.
> > > >
> > > > In your config you will use `MongoDb5`, but the provider will be of
> > > > type MongoDb4Provider.
> > > >
> > > > Piotr
> > > >
> > >
> >

Re: Canonicalization of URLs on our website

[Gary Gregory]

I agree with Piotr. I prefer the simplest solution, pointing to
`index.html`, no guessing required.

Gary

On Sat, Apr 20, 2024 at 4:17 PM Piotr P. Karwasz
 wrote:
>
> Hi,
>
> I scanned our https://logging.apache.org/ website and found out that
> the internal hyperlinks between our pages are not consistent. For
> example links to:
>
> https://logging.apache.org/log4j/2.x/
>
> might appear in hyperlinks with an URI path of:
>
> * `/log4j/2.x` (which causes a 301 HTTP redirect),
> * `/log4j/2.x/`,
> * `/log4j/2.x/index.html`.
>
> This lack of uniformity can cause several problems:
>
> * search engines might treat those 3 links as equivalent, but not necessarily.
> * if an `index.html` file is moved, we need to provide a redirect for
> all 3 alternatives: a recent example is
> `/log4j/2.x/log4j-1.2-api/index.html` that was moved to
> `/log4j2/2.x/log4j-1.2-api.html`.
> * for the rare people that actually look at the URL of a page, it
> doesn't seem coherent.
>
> So I would propose to adopt only one of the 3 alternatives and stick
> to it as much as possible? Which one should we choose?
>
> The simplest one (`/log4j/2.x/index.html`) does not require a Web
> server and can be viewed locally and can be viewed using the `file:`
> scheme in a browser. However I find it less elegant than
> `/log4j/2.x/`.
> Antora is probably able to generate both versions through some
> configuration option, so choosing `/log4j/2.x/` does not preclude the
> possibility to generate a different version to check the web site
> locally.
>
> Another canonicalization we might apply regards trailing `.html`
> extensions in the URL. The current website supports both:
>
> * `/log4j2/log4j-api`,
> * `/log4j2/log4j-api.html`.
>
> through `mod_negotiation`. Should we use the version with a trailing
> `.html` or without it? The `https://apache.org/` website hides the
> `.html` extension in most the links.
>
> Piotr

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

[Gary Gregory]

But then your config has to say  AND depend on the mongodb5
module! Still confusing 

On Wed, Apr 17, 2024, 2:29 PM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Wed, 17 Apr 2024 at 18:45, Gary Gregory  wrote:
> > Maybe if want to only use the latest driver for main, we should rename
> the
> > module and classes and drop the "4". That or go with what I initially
> > suggested.
>
> Your initial proposal of having a separate `log4j-mongodb4` and
> `log4j-mongodb5` modules might actually be easier to understand for
> users.
>
> We can however reduce maintenance work by setting `log4j-mongodb4` as
> dependency for `log4j-mongodb5`, bumping the dependency on MongoDB
> Java Driver in that artifact only and have a single class that reuses
> the `log4j-mongodb4` artifact.
>
> @Plugin("MongoDb5")
> public final class MongoDb5Provider {
>
> private MongoDb5Provider() {}
>
> @PluginFactory
> public static MongoDb4Provider.Builder newBuilder() {
> return new MongoDb4Provider.Builder<>();
> }
> }
>
> WDYT?
>
> Piotr
>

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

[Gary Gregory]

Maybe if want to only use the latest driver for main, we should rename the
module and classes and drop the "4". That or go with what I initially
suggested.

Gary

On Wed, Apr 17, 2024, 12:18 PM Gary Gregory  wrote:

> Hi Piotr,
>
> Having mongodb4 module depend on the mongodb 5 driver sure is confusing
> though. What I don't know and don't want to deal with is "I updated to the
> latest log4j-mongdb5 version and my app no longer works" because it might
> turn out that the newer 5.x driver drops support for older Mongo versions.
> Since we established support for major versions of the driver for 3 and 4,
> I thought it conceptually simpler to do the same for 5.
>
> WDYT?
>
> Gary
>
> On Wed, Apr 17, 2024, 11:24 AM Piotr P. Karwasz 
> wrote:
>
>> Hi Gary,
>>
>> On Wed, 17 Apr 2024 at 16:36, Gary D. Gregory 
>> wrote:
>> >
>> > Hello All,
>> >
>> > In In 2.x, I would like to:
>> >
>> > - drop log4j-mongodb3 and
>> > - add log4j-mongodb5
>> > - then do the same in 3.x
>> >
>> > Any objections?
>>
>> It is fine with me.
>>
>> Regarding log4j-mongodb5: MongoDB driver has already been upgraded to
>> version 5.0.0 in `main` by Dependabot and the unit tests passed. Do we
>> need another artifact or we just need to test it against version 4.11
>> and 5.0 of the driver?
>>
>> Piotr
>>
>

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

[Gary Gregory]

Hi Piotr,

Having mongodb4 module depend on the mongodb 5 driver sure is confusing
though. What I don't know and don't want to deal with is "I updated to the
latest log4j-mongdb5 version and my app no longer works" because it might
turn out that the newer 5.x driver drops support for older Mongo versions.
Since we established support for major versions of the driver for 3 and 4,
I thought it conceptually simpler to do the same for 5.

WDYT?

Gary

On Wed, Apr 17, 2024, 11:24 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Wed, 17 Apr 2024 at 16:36, Gary D. Gregory  wrote:
> >
> > Hello All,
> >
> > In In 2.x, I would like to:
> >
> > - drop log4j-mongodb3 and
> > - add log4j-mongodb5
> > - then do the same in 3.x
> >
> > Any objections?
>
> It is fine with me.
>
> Regarding log4j-mongodb5: MongoDB driver has already been upgraded to
> version 5.0.0 in `main` by Dependabot and the unit tests passed. Do we
> need another artifact or we just need to test it against version 4.11
> and 5.0 of the driver?
>
> Piotr
>

Re: [VOTE] Release Apache Log4j Tools 0.8.0 (RC3)

[Gary Gregory]

What's the difference with RC2?

TY,
Gary

On Thu, Mar 21, 2024, 11:46 AM Volkan Yazıcı  wrote:

> This is a vote to release the Apache Log4j Tools 0.8.0 (RC3).
>
> Website: https://logging.staged.apache.org/log4j/tools
> GitHub: https://github.com/apache/logging-log4j-tools
> Commit: 7d157b61e198e3baca816129d8d406b300436e2f
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1266
> 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 until 2024-03-22 12:30 (CET) 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.
>
> === Timing & Differences
>
> I will keep this vote open until 2024-03-22 12:30 (CET), that is, the
> official end date of the RC2, since RC3 contains a minor difference:
>
>
> https://github.com/apache/logging-log4j-tools/compare/2bb07037bbbfe14fe1c224d46a3e4135b48ffde6...7d157b61e198e3baca816129d8d406b300436e2f
>
> === Review kit
>
> The minimum set of steps needed to review the uploaded distribution
> files in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> svn co https://dist.apache.org/repos/... && cd $_
>
> # Verify checksums
> shasum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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/...
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> === Release notes
>
> This release delivers the first version of Log4j Docgen (Documentation
> Generator).
> It is a set of tools to auto-generate the Log4j plugin documentation (to be
> integrated into the website) and the Log4j configuration XSD file (for
> assisting the configuration of the Log4j runtime, i.e., `log4j2.xml`) from
> the Log4j source code. See the project website for details.
>
>  Added
>
> * Add the `log4j-docgen` et al. containing a universal XML model to
> document Log4j plugins
>
>  Changed
>
> * Move Log4j Changelog XML namespace and schema location to `
> https://logging.apache.org/xml/ns` 
> and `
> https://logging.apache.org/xml/ns/log4j-changelog-0.xsd`
> , respectively
>
>  Removed
>
> * Remove `author` from Log4j Changelog. It was yet another bit to maintain
> and created role-related (who did what) problems. Many modern software
> projects use a VCS (e.g., Git) and support services (e.g., GitHub) which
> make it trivial to trace back the origin of a change using commit and issue
> IDs.
>
>  Updated
>
> * Update `org.apache.logging:logging-parent` to version `10.6.0`
> * Update `jakarta.inject:jakarta.inject-api` to version `2.0.1` (#94)
> * Update `org.apache.logging.log4j:log4j-core` to version `2.23.1` (#108)
> * Update `org.apache.logging.log4j:log4j-plugins` to version `3.0.0-beta2`
> (#107)
> * Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to
> version `3.11.0` (#98)
> * Update `org.assertj:assertj-core` to version `3.25.3` (#104)
> * Update `org.codehaus.modello:modello-maven-plugin` to version `2.3.0`
> (#105)
> * Update `org.junit:junit-bom` to version `5.10.2` (#103)
>

Re: [VOTE] Release Apache Log4j Tools 0.8.0 (RC2)

[Gary Gregory]

+1

Tested src zip file
SHA512 OK
ASC OK
Apache RAT check OK
Build 'mvn clean verify' OK

Using:

openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment Homebrew (build 17.0.10+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.10+0, mixed mode, sharing)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.10, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.10/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"

Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64

Gary

On Tue, Mar 19, 2024 at 7:35 AM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j Tools 0.8.0 (RC2).
>
> Website: https://logging.staged.apache.org/log4j/tools
> GitHub: https://github.com/apache/logging-log4j-tools
> Commit: 2bb07037bbbfe14fe1c224d46a3e4135b48ffde6
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1265
> 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.
>
> === Review kit
>
> The minimum set of steps needed to review the uploaded distribution
> files in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> svn co https://dist.apache.org/repos/... && cd $_
>
> # Verify checksums
> shasum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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/...
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> === Release notes
>
> This release delivers the first version of Log4j Docgen (Documentation
> Generator). It is a set of tools to auto-generate the Log4j plugin
> documentation (to be integrated into the website) and the Log4j
> configuration XSD file (for assisting the configuration of the Log4j
> runtime, i.e., `log4j2.xml`) from the Log4j source code. See the
> project website for details.
>
>  Added
>
> * Add the `log4j-docgen` et al. containing a universal XML model to
> document Log4j plugins
>
>  Changed
>
> * Move Log4j Changelog XML namespace and schema location to
> `https://logging.apache.org/xml/ns` and
> `https://logging.apache.org/xml/ns/log4j-changelog-0.xsd`,
> respectively
>
>  Removed
>
> * Remove `author` from Log4j Changelog. It was yet another bit to
> maintain and created role-related (who did what) problems. Many modern
> software projects use a VCS (e.g., Git) and support services (e.g.,
> GitHub) which make it trivial to trace back the origin of a change
> using commit and issue IDs.
>
>  Updated
>
> * Update `org.apache.logging:logging-parent` to version `10.6.0`
> * Update `jakarta.inject:jakarta.inject-api` to version `2.0.1` (#94)
> * Update `org.apache.logging.log4j:log4j-core` to version `2.23.1` (#108)
> * Update `org.apache.logging.log4j:log4j-plugins` to version
> `3.0.0-beta2` (#107)
> * Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to
> version `3.11.0` (#98)
> * Update `org.assertj:assertj-core` to version `3.25.3` (#104)
> * Update `org.codehaus.modello:modello-maven-plugin` to version `2.3.0` (#105)
> * Update `org.junit:junit-bom` to version `5.10.2` (#103)

Re: [VOTE] Release Apache Log4Net 2.0.17

[Gary Gregory]

Ah, ok, then I'll abstain from voting until we have a version I can
build locally.

TY for the heads up.

Gary

On Fri, Mar 15, 2024 at 2:24 PM Jan Friedrich  wrote:
>
> Hello Gary,
>
> https://paste.apache.org/1ropz looks like you're building 2.0.16?
> Building the current version is currently very difficult due to the many 
> target frameworks: 
> net20;net35;net40;net40-client;net45;netstandard1.3;netstandard2.0
> You need to have each SDK for them and especially the old ones are really 
> difficult to install.
>
> In the next version (3.0.0) we have stripped these down to two: 
> net462;netstandard2.0
> Then it will be easy to build them on your machine.
>
> Regards.
>
> Jan
>
> Friday, March 15, 2024, 5:47:22 PM, you wrote:
>
> > What about the failure?
>
> > Gary
>
> > On Fri, Mar 15, 2024, 11:35 AM Davyd McColl  wrote:
>
> >> Hi
> >>
> >> Yes, everything should be done via npm scripts. So I should remove any
> >> confusing .cmd files.
> >>
> >> As for the version, I should update that, but it's minor. That version
> >> comes from package.json and will only show when running npm commands. But I
> >> admit it's confusing.
> >>
> >> -d
> >>
> >> On 15 March 2024 16:28:47 "Gary D. Gregory"  wrote:
> >>
> >>> We might need better build instructions... for me at least ;-)
> >>>
> >>> I take it the build.cmd file should be removed since it's not mentioned
> >>> in https://github.com/apache/logging-log4net/blob/master/doc/BUILDING.md
> >>> ?
> >>>
> >>> BUILDING.md  contains a section called "TL;DR (!Windows):" which is too
> >>> easy to confuse with "TL;DR (Windows):", just say "TL;DR (non-Windows):",
> >>> there is no need to be clever here IMO.
> >>>
> >>> When I say "npm i" and then "npm run build", it starts with:
> >>>
>  log4net@2.0.12 prebuild
>  run-s clean-build
>  log4net@2.0.12 clean-build
>  rimraf build
>  log4net@2.0.12 build
>  zarro @
> 
> >>>
> >>> Why does it say log4net@2.0.12 when I am building 2.0.17?
> >>>
> >>> Then the build errors out with https://paste.apache.org/1ropz
> >>>
> >>> I, off course, don't know what I'm doing with .net... ;-)
> >>>
> >>> Gary
> >>>
> >>> On 2024/03/15 12:28:03 Davyd McColl wrote:
> >>>
>  Hi all,
> 
>  This is a vote to release the Apache Log4net 2.0.17.
> 
>  Website:
>  https://logging.staged.apache.org/log4net/release/release-notes.html
>  GitHub: https://github.com/apache/logging-log4net
>  GitHub release (pre-release):
>  https://github.com/apache/logging-log4net/releases/tag/rel/2.0.17-rc1
>  Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net
> 
>  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.
> 
>  Thanks to Jan for basically doing all of this (:
> 
>  -d
> 
> >>>
>

Re: [VOTE] Release Apache Log4Net 2.0.17

[Gary Gregory]

What about the failure?

Gary

On Fri, Mar 15, 2024, 11:35 AM Davyd McColl  wrote:

> Hi
>
> Yes, everything should be done via npm scripts. So I should remove any
> confusing .cmd files.
>
> As for the version, I should update that, but it's minor. That version
> comes from package.json and will only show when running npm commands. But I
> admit it's confusing.
>
> -d
>
> On 15 March 2024 16:28:47 "Gary D. Gregory"  wrote:
>
>> We might need better build instructions... for me at least ;-)
>>
>> I take it the build.cmd file should be removed since it's not mentioned
>> in https://github.com/apache/logging-log4net/blob/master/doc/BUILDING.md
>> ?
>>
>> BUILDING.md  contains a section called "TL;DR (!Windows):" which is too
>> easy to confuse with "TL;DR (Windows):", just say "TL;DR (non-Windows):",
>> there is no need to be clever here IMO.
>>
>> When I say "npm i" and then "npm run build", it starts with:
>>
>>> log4net@2.0.12 prebuild
>>> run-s clean-build
>>> log4net@2.0.12 clean-build
>>> rimraf build
>>> log4net@2.0.12 build
>>> zarro @
>>>
>>
>> Why does it say log4net@2.0.12 when I am building 2.0.17?
>>
>> Then the build errors out with https://paste.apache.org/1ropz
>>
>> I, off course, don't know what I'm doing with .net... ;-)
>>
>> Gary
>>
>> On 2024/03/15 12:28:03 Davyd McColl wrote:
>>
>>> Hi all,
>>>
>>> This is a vote to release the Apache Log4net 2.0.17.
>>>
>>> Website:
>>> https://logging.staged.apache.org/log4net/release/release-notes.html
>>> GitHub: https://github.com/apache/logging-log4net
>>> GitHub release (pre-release):
>>> https://github.com/apache/logging-log4net/releases/tag/rel/2.0.17-rc1
>>> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net
>>>
>>> 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.
>>>
>>> Thanks to Jan for basically doing all of this (:
>>>
>>> -d
>>>
>>

Re: [VOTE] Release Apache Log4net 2.0.16

[Gary Gregory]

You don't need memory, if you deleted the messages already from your email
app, go to lists.apache.org

Gary


On Fri, Mar 8, 2024, 8:59 AM Davyd McColl  wrote:

> Hi Gary
>
>
> I'll try to remember that for the future. From memory now, there was
> only one person who had any holdups and that was due to outdated build
> docs from me - so it should be resolved. There were no -1's, and at
> least 4 +1's that I saw. I'll try to keep better tally next time.
>
>
> -d
>
> On 2024/03/08 14:22, Gary Gregory wrote:
> > Process:
> >
> > You need to reply to this thread with a [RESULT] prefix, tally all the
> > votes, and say whether the vote passes or not. It is helpful to note
> which
> > votes are binding or not.
> >
> > Gary
> >
> > On Fri, Mar 8, 2024, 6:06 AM Davyd McColl  wrote:
> >
> >> Hi all
> >>
> >>
> >> Thanks for all the checking - log4net 2.0.16 is out in the wild now (:
> >>
> >>
> >> -d
> >>
> >> On 2024/03/08 00:02, Jan Friedrich wrote:
> >>> Hello Gary,
> >>>
> >>> the errors are in the examples project for .net compact framework
> (which
> >> is no longer supported by microsoft):
> >>>
> >>
> C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj(23,1):
> >> error MSB4075:
> >>> The project file
> >>
> "C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj"
> >> must be opened in the Visual Studio IDE and converted to the latest
> version
> >> before it can be built by MSBuild.
> >>> -> This project file can only be opened by VS 2003.
> >>>
> >>> In the next release we will drop support for those exotic frameworks
> and
> >> delete the corresponding examples.
> >>> I've already updated all the examples in my feature branch for this.
> >>>
> >>> Regards.
> >>>
> >>> Jan
> >>>
> >>> Thursday, March 7, 2024, 10:28:40 PM, you wrote:
> >>>
> >>>> I've failed to build probably because the machine I am doing this on
> is
> >> DNS locked down for security and can only access certain sites.
> >>>> I was able to install install-dotnet-core-sdk-1.1.ps1 but not
> >> install-net-framework-sdk-3.5.ps1 (Error 0x800F0954 in a dialog that
> points
> >> to
> >>
> https://learn.microsoft.com/en-US/troubleshoot/windows-client/application-management/dotnet-framework-35-installation-error
> )
> >> but I also don't know if how if this machine has enough already on top
> of
> >> Microsoft Windows [Version 10.0.19045.4046]
> >>>> My results: https://paste.apache.org/jj3c8
> >>>> I rebooted and tried again with the same results.
> >>>> Gary
> >>>> On 2024/03/07 03:11:22 Robert Middleton wrote:
> >>>>> +1
> >>>>> Verified the following:
> >>>>> * apache-log4net-source-2.0.16.zip and associated sha/signature
> >>>>> * apache-log4net-binaries-2.0.16.zip and associated sha/signature
> >>>>> It looks all good to me.
> >>>>> -Robert Middleton
> >>>>> On Tue, Mar 5, 2024 at 1:20 AM Ralph Goers <
> ralph.go...@dslextreme.com>
> >> wrote:
> >>>>>> +1
> >>>>>> Verified signatures
> >>>>>> Verified hashes
> >>>>>> Verified License and Notice files.
> >>>>>> Note - the copyright year should be the first year the code was
> >> created. You can update it to include “-(currentYear}” but that is not
> >> strictly necessary.
> >>>>>> Ralph
> >>>>>>> On Mar 4, 2024, at 10:48 AM, Jan Friedrich 
> >> wrote:
> >>>>>>> +1
> >>>>>>> Unit tests on my machine were successful.
> >>>>>>> We integrated the new version into our test environment and all
> >> manual tests were successful.
> >>>>>>> Jan
> >>>>>>>> +1
> >>>>>>>> Verified signatures.
> >>>>>>>> Verified hashes.
> >>>>>>>> `NOTICE` contains 2022 as the copyright year, but I don't find it
> a
> >>>>>>>> blocker. (I have fixed it in `master`.)
> >>>>>>>> On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl 
> >> wrote:
> >>>>>>>>> Hi all
> >>>>>>>>> This is the vote to release Apache log4net version 2.0.16
> >>>>>>>>> Website:
> >>>>>>>>>
> >> https://logging.staged.apache.org/log4net/release/release-notes.html
> >>>>>>>>> GitHub: https://github.com/apache/logging-log4net
> >>>>>>>>> GitHub release (pre-release):
> >>>>>>>>>
> https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1
> >>>>>>>>> Distribution: I'm not sure -
> >>>>>>>>> https://dist.apache.org/repos/dist/dev/logging/log4net should
> have
> >>>>>>>>> 2.0.16 binaries and source (I've added via SVN), but I'm not
> seeing
> >>>>>>>>> them. Any help appreciated.
> >>>>>>>>> Please have a look at the staging site & artifacts and test (if
> >> you can
> >>>>>>>>> - clone, `npm i`, `npm test`)
> >>>>>>>>> [ ] +1, release the artifacts
> >>>>>>>>> [ ] -1, don't release, because
> >>>>>>>>> (thanks Piotr: I copied most of your last VOTE mail!)
> >>>>>>>>> -d
>

Re: [VOTE] Release Apache Log4net 2.0.16

[Gary Gregory]

Process:

You need to reply to this thread with a [RESULT] prefix, tally all the
votes, and say whether the vote passes or not. It is helpful to note which
votes are binding or not.

Gary

On Fri, Mar 8, 2024, 6:06 AM Davyd McColl  wrote:

> Hi all
>
>
> Thanks for all the checking - log4net 2.0.16 is out in the wild now (:
>
>
> -d
>
> On 2024/03/08 00:02, Jan Friedrich wrote:
> > Hello Gary,
> >
> > the errors are in the examples project for .net compact framework (which
> is no longer supported by microsoft):
> >
> >
> C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj(23,1):
> error MSB4075:
> > The project file
> "C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj"
> must be opened in the Visual Studio IDE and converted to the latest version
> before it can be built by MSBuild.
> >
> > -> This project file can only be opened by VS 2003.
> >
> > In the next release we will drop support for those exotic frameworks and
> delete the corresponding examples.
> > I've already updated all the examples in my feature branch for this.
> >
> > Regards.
> >
> > Jan
> >
> > Thursday, March 7, 2024, 10:28:40 PM, you wrote:
> >
> >> I've failed to build probably because the machine I am doing this on is
> DNS locked down for security and can only access certain sites.
> >> I was able to install install-dotnet-core-sdk-1.1.ps1 but not
> install-net-framework-sdk-3.5.ps1 (Error 0x800F0954 in a dialog that points
> to
> https://learn.microsoft.com/en-US/troubleshoot/windows-client/application-management/dotnet-framework-35-installation-error)
> but I also don't know if how if this machine has enough already on top of
> Microsoft Windows [Version 10.0.19045.4046]
> >> My results: https://paste.apache.org/jj3c8
> >> I rebooted and tried again with the same results.
> >> Gary
> >> On 2024/03/07 03:11:22 Robert Middleton wrote:
> >>> +1
> >>> Verified the following:
> >>> * apache-log4net-source-2.0.16.zip and associated sha/signature
> >>> * apache-log4net-binaries-2.0.16.zip and associated sha/signature
> >>> It looks all good to me.
> >>> -Robert Middleton
> >>> On Tue, Mar 5, 2024 at 1:20 AM Ralph Goers 
> wrote:
>  +1
>  Verified signatures
>  Verified hashes
>  Verified License and Notice files.
>  Note - the copyright year should be the first year the code was
> created. You can update it to include “-(currentYear}” but that is not
> strictly necessary.
>  Ralph
> > On Mar 4, 2024, at 10:48 AM, Jan Friedrich 
> wrote:
> > +1
> > Unit tests on my machine were successful.
> > We integrated the new version into our test environment and all
> manual tests were successful.
> > Jan
> >> +1
> >> Verified signatures.
> >> Verified hashes.
> >> `NOTICE` contains 2022 as the copyright year, but I don't find it a
> >> blocker. (I have fixed it in `master`.)
> >> On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl 
> wrote:
> >>> Hi all
> >>> This is the vote to release Apache log4net version 2.0.16
> >>> Website:
> >>>
> https://logging.staged.apache.org/log4net/release/release-notes.html
> >>> GitHub: https://github.com/apache/logging-log4net
> >>> GitHub release (pre-release):
> >>> https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1
> >>> Distribution: I'm not sure -
> >>> https://dist.apache.org/repos/dist/dev/logging/log4net should have
> >>> 2.0.16 binaries and source (I've added via SVN), but I'm not seeing
> >>> them. Any help appreciated.
> >>> Please have a look at the staging site & artifacts and test (if
> you can
> >>> - clone, `npm i`, `npm test`)
> >>> [ ] +1, release the artifacts
> >>> [ ] -1, don't release, because
> >>> (thanks Piotr: I copied most of your last VOTE mail!)
> >>> -d
>

Re: [VOTE] Release Apache Log4j 2.23.1

[Gary Gregory]

All better now: +1

For details see: [log4j] `2.23.1` reproducibility failure (Was: [VOTE]
Release Apache Log4j 2.23.1)

Gary




On Wed, Mar 6, 2024 at 9:26 AM Gary Gregory  wrote:
>
> Same :-(
>
> [INFO] --- bnd-baseline:7.0.0:baseline (check-api-compat) @ log4j-bom ---
> [INFO] skip project with packaging=pom
> [INFO]
> [INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
> [ERROR] project.build.outputTimestamp property should not be inherited
> but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
> Downloading from reference:
> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
> [INFO] Reference buildinfo file not found: it will be generated from
> downloaded reference artifacts
> Downloading from reference:
> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> Downloaded from reference:
> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> (12 kB at 77 kB/s)
> Downloading from reference:
> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> Downloaded from reference:
> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> (704 kB at 914 kB/s)
> [INFO] Minimal buildinfo generated from downloaded artifacts:
> /Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
> [ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
> with diffoscope
> target/reference/org.apache.logging.log4j/log4j-bom-2.23.1-cyclonedx.xml
> target/bom.xml
> [ERROR] Reproducible Build output summary: 1 files ok, 1 different
> [ERROR] see diff target/reference/log4j-bom-2.23.1.buildinfo
> target/log4j-bom-2.23.1.buildinfo
> [ERROR] see also
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> [INFO] Reproducible Build output comparison saved to
> /Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
> [INFO] Aggregate buildcompare copied to
> /Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
> [INFO] 
> 
> [INFO] Reactor Summary for Apache Log4j BOM 2.23.1:
> [INFO]
> [INFO] Apache Log4j BOM ... FAILURE [ 38.689 
> s]
> [INFO] Apache Log4j Parent  SKIPPED
>
> Gary
>
> On Wed, Mar 6, 2024 at 9:23 AM Volkan Yazıcı  wrote:
> >
> > Could you retry after cleaning up your local repository, please? That is,
> >
> > rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
> >
> >
> >
> > On Wed, Mar 6, 2024 at 3:03 PM Gary Gregory  wrote:
> >
> > > I get a build failure:
> > >
> > > INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
> > > [ERROR] project.build.outputTimestamp property should not be inherited
> > > but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
> > > Downloading from reference:
> > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
> > > [INFO] Reference buildinfo file not found: it will be generated from
> > > downloaded reference artifacts
> > > Downloading from reference:
> > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > > Downloaded from reference:
> > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > > (12 kB at 86 kB/s)
> > > Downloading from reference:
> > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > > Downloaded from reference:
> > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > > (704 kB at 949 kB/s)
> > > [INFO] Minimal buildinfo generated from downloaded artifacts:
> > >
> > > /Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
> > > [ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investi

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

[Gary Gregory]

The build was completed successfully.

Gary

On Wed, Mar 6, 2024 at 11:02 AM Gary Gregory  wrote:
>
> I nuked the whole thing (rm -rf ~/.m2/repository/) for good measure
> (I'll do that once a month from now on).
>
> Building (and downloading the world)...
>
> It's made it past log4j-bom so we might be looking good...
>
> TY!
> Gary
>
> On Wed, Mar 6, 2024 at 10:33 AM Volkan Yazıcı  wrote:
> >
> > Could you do `rm -rf ~/.m2/repository/org/apache/commons` and retry,
> > please? (If you compare `target/bom.xml`s you can see that your local
> > `commons-*` clones have different hashes.)
> >
> > On Wed, Mar 6, 2024 at 4:00 PM Gary Gregory  wrote:
> >
> > > On Wed, Mar 6, 2024 at 9:54 AM Volkan Yazıcı  wrote:
> > > >
> > > > Could you share the `target/bom.xml` and
> > >
> > > https://paste.apache.org/za0k3
> > >
> > > > `target/log4j-bom-2.23.1.buildinfo` files too, please?
> > >
> > > https://paste.apache.org/1403q
> > >
> > > Gary
> > >
> > > >
> > > > On Wed, Mar 6, 2024 at 3:35 PM Gary Gregory 
> > > wrote:
> > > >
> > > > > rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
> > > > > export NEXUS_REPO=
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261
> > > > > sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> > > > >
> > > > > Gary
> > > > >
> > > > > On Wed, Mar 6, 2024 at 9:33 AM Volkan Yazıcı  wrote:
> > > > > >
> > > > > > Which command are you exactly running?
> > > > > >
> > > > > > Could you share the `target/bom.xml` and
> > > > > `target/log4j-bom-2.23.1.buildinfo` files too, please?
> > > > > >
> > > > > > On Wed, Mar 6, 2024 at 3:28 PM Gary Gregory 
> > > > > wrote:
> > > > > >>
> > > > > >> Same :-(
> > > > > >>
> > > > > >> [INFO] --- bnd-baseline:7.0.0:baseline (check-api-compat) @
> > > log4j-bom
> > > > > ---
> > > > > >> [INFO] skip project with packaging=pom
> > > > > >> [INFO]
> > > > > >> [INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
> > > > > >> [ERROR] project.build.outputTimestamp property should not be
> > > inherited
> > > > > >> but defined in POM
> > > /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
> > > > > >> Downloading from reference:
> > > > > >>
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
> > > > > >> [INFO] Reference buildinfo file not found: it will be generated 
> > > > > >> from
> > > > > >> downloaded reference artifacts
> > > > > >> Downloading from reference:
> > > > > >>
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > > > > >> Downloaded from reference:
> > > > > >>
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > > > > >> (12 kB at 77 kB/s)
> > > > > >> Downloading from reference:
> > > > > >>
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > > > > >> Downloaded from reference:
> > > > > >>
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > > > > >> (704 kB at 914 kB/s)
> > > > > >> [INFO] Minimal buildinfo generated from downloaded artifacts:
> > > > > >>
> > > > >
> > > /Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
> > > > > >> [ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
> > > > > >> with diffoscope
> >

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

[Gary Gregory]

I nuked the whole thing (rm -rf ~/.m2/repository/) for good measure
(I'll do that once a month from now on).

Building (and downloading the world)...

It's made it past log4j-bom so we might be looking good...

TY!
Gary

On Wed, Mar 6, 2024 at 10:33 AM Volkan Yazıcı  wrote:
>
> Could you do `rm -rf ~/.m2/repository/org/apache/commons` and retry,
> please? (If you compare `target/bom.xml`s you can see that your local
> `commons-*` clones have different hashes.)
>
> On Wed, Mar 6, 2024 at 4:00 PM Gary Gregory  wrote:
>
> > On Wed, Mar 6, 2024 at 9:54 AM Volkan Yazıcı  wrote:
> > >
> > > Could you share the `target/bom.xml` and
> >
> > https://paste.apache.org/za0k3
> >
> > > `target/log4j-bom-2.23.1.buildinfo` files too, please?
> >
> > https://paste.apache.org/1403q
> >
> > Gary
> >
> > >
> > > On Wed, Mar 6, 2024 at 3:35 PM Gary Gregory 
> > wrote:
> > >
> > > > rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
> > > > export NEXUS_REPO=
> > > >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261
> > > > sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> > > >
> > > > Gary
> > > >
> > > > On Wed, Mar 6, 2024 at 9:33 AM Volkan Yazıcı  wrote:
> > > > >
> > > > > Which command are you exactly running?
> > > > >
> > > > > Could you share the `target/bom.xml` and
> > > > `target/log4j-bom-2.23.1.buildinfo` files too, please?
> > > > >
> > > > > On Wed, Mar 6, 2024 at 3:28 PM Gary Gregory 
> > > > wrote:
> > > > >>
> > > > >> Same :-(
> > > > >>
> > > > >> [INFO] --- bnd-baseline:7.0.0:baseline (check-api-compat) @
> > log4j-bom
> > > > ---
> > > > >> [INFO] skip project with packaging=pom
> > > > >> [INFO]
> > > > >> [INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
> > > > >> [ERROR] project.build.outputTimestamp property should not be
> > inherited
> > > > >> but defined in POM
> > /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
> > > > >> Downloading from reference:
> > > > >>
> > > >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
> > > > >> [INFO] Reference buildinfo file not found: it will be generated from
> > > > >> downloaded reference artifacts
> > > > >> Downloading from reference:
> > > > >>
> > > >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > > > >> Downloaded from reference:
> > > > >>
> > > >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > > > >> (12 kB at 77 kB/s)
> > > > >> Downloading from reference:
> > > > >>
> > > >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > > > >> Downloaded from reference:
> > > > >>
> > > >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > > > >> (704 kB at 914 kB/s)
> > > > >> [INFO] Minimal buildinfo generated from downloaded artifacts:
> > > > >>
> > > >
> > /Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
> > > > >> [ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
> > > > >> with diffoscope
> > > > >>
> > target/reference/org.apache.logging.log4j/log4j-bom-2.23.1-cyclonedx.xml
> > > > >> target/bom.xml
> > > > >> [ERROR] Reproducible Build output summary: 1 files ok, 1 different
> > > > >> [ERROR] see diff target/reference/log4j-bom-2.23.1.buildinfo
> > > > >> target/log4j-bom-2.23.1.buildinfo
> > > > >> [ERROR] see also
> > > > >> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> > > > >> [INFO] Repro

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

[Gary Gregory]

On Wed, Mar 6, 2024 at 9:54 AM Volkan Yazıcı  wrote:
>
> Could you share the `target/bom.xml` and

https://paste.apache.org/za0k3

> `target/log4j-bom-2.23.1.buildinfo` files too, please?

https://paste.apache.org/1403q

Gary

>
> On Wed, Mar 6, 2024 at 3:35 PM Gary Gregory  wrote:
>
> > rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
> > export NEXUS_REPO=
> > https://repository.apache.org/content/repositories/orgapachelogging-1261
> > sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> >
> > Gary
> >
> > On Wed, Mar 6, 2024 at 9:33 AM Volkan Yazıcı  wrote:
> > >
> > > Which command are you exactly running?
> > >
> > > Could you share the `target/bom.xml` and
> > `target/log4j-bom-2.23.1.buildinfo` files too, please?
> > >
> > > On Wed, Mar 6, 2024 at 3:28 PM Gary Gregory 
> > wrote:
> > >>
> > >> Same :-(
> > >>
> > >> [INFO] --- bnd-baseline:7.0.0:baseline (check-api-compat) @ log4j-bom
> > ---
> > >> [INFO] skip project with packaging=pom
> > >> [INFO]
> > >> [INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
> > >> [ERROR] project.build.outputTimestamp property should not be inherited
> > >> but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
> > >> Downloading from reference:
> > >>
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
> > >> [INFO] Reference buildinfo file not found: it will be generated from
> > >> downloaded reference artifacts
> > >> Downloading from reference:
> > >>
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > >> Downloaded from reference:
> > >>
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > >> (12 kB at 77 kB/s)
> > >> Downloading from reference:
> > >>
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > >> Downloaded from reference:
> > >>
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > >> (704 kB at 914 kB/s)
> > >> [INFO] Minimal buildinfo generated from downloaded artifacts:
> > >>
> > /Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
> > >> [ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
> > >> with diffoscope
> > >> target/reference/org.apache.logging.log4j/log4j-bom-2.23.1-cyclonedx.xml
> > >> target/bom.xml
> > >> [ERROR] Reproducible Build output summary: 1 files ok, 1 different
> > >> [ERROR] see diff target/reference/log4j-bom-2.23.1.buildinfo
> > >> target/log4j-bom-2.23.1.buildinfo
> > >> [ERROR] see also
> > >> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> > >> [INFO] Reproducible Build output comparison saved to
> > >> /Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
> > >> [INFO] Aggregate buildcompare copied to
> > >> /Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
> > >> [INFO]
> > ----
> > >> [INFO] Reactor Summary for Apache Log4j BOM 2.23.1:
> > >> [INFO]
> > >> [INFO] Apache Log4j BOM ... FAILURE [
> > 38.689 s]
> > >> [INFO] Apache Log4j Parent  SKIPPED
> > >>
> > >> Gary
> > >>
> > >> On Wed, Mar 6, 2024 at 9:23 AM Volkan Yazıcı  wrote:
> > >> >
> > >> > Could you retry after cleaning up your local repository, please? That
> > is,
> > >> >
> > >> > rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Mar 6, 2024 at 3:03 PM Gary Gregory 
> > wrote:
> > >> >
> > >> > > I get a build failure:
> > >> > >
> > >> > > INFO] --- artifact:3.5.0:compare (default-

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

[Gary Gregory]

rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
export 
NEXUS_REPO=https://repository.apache.org/content/repositories/orgapachelogging-1261
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO

Gary

On Wed, Mar 6, 2024 at 9:33 AM Volkan Yazıcı  wrote:
>
> Which command are you exactly running?
>
> Could you share the `target/bom.xml` and `target/log4j-bom-2.23.1.buildinfo` 
> files too, please?
>
> On Wed, Mar 6, 2024 at 3:28 PM Gary Gregory  wrote:
>>
>> Same :-(
>>
>> [INFO] --- bnd-baseline:7.0.0:baseline (check-api-compat) @ log4j-bom ---
>> [INFO] skip project with packaging=pom
>> [INFO]
>> [INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
>> [ERROR] project.build.outputTimestamp property should not be inherited
>> but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
>> Downloading from reference:
>> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
>> [INFO] Reference buildinfo file not found: it will be generated from
>> downloaded reference artifacts
>> Downloading from reference:
>> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
>> Downloaded from reference:
>> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
>> (12 kB at 77 kB/s)
>> Downloading from reference:
>> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
>> Downloaded from reference:
>> https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
>> (704 kB at 914 kB/s)
>> [INFO] Minimal buildinfo generated from downloaded artifacts:
>> /Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
>> [ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
>> with diffoscope
>> target/reference/org.apache.logging.log4j/log4j-bom-2.23.1-cyclonedx.xml
>> target/bom.xml
>> [ERROR] Reproducible Build output summary: 1 files ok, 1 different
>> [ERROR] see diff target/reference/log4j-bom-2.23.1.buildinfo
>> target/log4j-bom-2.23.1.buildinfo
>> [ERROR] see also
>> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
>> [INFO] Reproducible Build output comparison saved to
>> /Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
>> [INFO] Aggregate buildcompare copied to
>> /Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
>> [INFO] 
>> 
>> [INFO] Reactor Summary for Apache Log4j BOM 2.23.1:
>> [INFO]
>> [INFO] Apache Log4j BOM ... FAILURE [ 38.689 
>> s]
>> [INFO] Apache Log4j Parent  SKIPPED
>>
>> Gary
>>
>> On Wed, Mar 6, 2024 at 9:23 AM Volkan Yazıcı  wrote:
>> >
>> > Could you retry after cleaning up your local repository, please? That is,
>> >
>> > rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
>> >
>> >
>> >
>> > On Wed, Mar 6, 2024 at 3:03 PM Gary Gregory  wrote:
>> >
>> > > I get a build failure:
>> > >
>> > > INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
>> > > [ERROR] project.build.outputTimestamp property should not be inherited
>> > > but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
>> > > Downloading from reference:
>> > >
>> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
>> > > [INFO] Reference buildinfo file not found: it will be generated from
>> > > downloaded reference artifacts
>> > > Downloading from reference:
>> > >
>> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
>> > > Downloaded from reference:
>> > >
>> > > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
>> > > (12 kB at 86 kB/s)
>> > > Downloading from reference:
>> > >
>> > > https://repos

Re: [VOTE] Release Apache Log4j 2.23.1

[Gary Gregory]

Same :-(

[INFO] --- bnd-baseline:7.0.0:baseline (check-api-compat) @ log4j-bom ---
[INFO] skip project with packaging=pom
[INFO]
[INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
[ERROR] project.build.outputTimestamp property should not be inherited
but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
Downloading from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
[INFO] Reference buildinfo file not found: it will be generated from
downloaded reference artifacts
Downloading from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
Downloaded from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
(12 kB at 77 kB/s)
Downloading from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
Downloaded from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
(704 kB at 914 kB/s)
[INFO] Minimal buildinfo generated from downloaded artifacts:
/Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
[ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
with diffoscope
target/reference/org.apache.logging.log4j/log4j-bom-2.23.1-cyclonedx.xml
target/bom.xml
[ERROR] Reproducible Build output summary: 1 files ok, 1 different
[ERROR] see diff target/reference/log4j-bom-2.23.1.buildinfo
target/log4j-bom-2.23.1.buildinfo
[ERROR] see also
https://maven.apache.org/guides/mini/guide-reproducible-builds.html
[INFO] Reproducible Build output comparison saved to
/Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
[INFO] Aggregate buildcompare copied to
/Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
[INFO] 
[INFO] Reactor Summary for Apache Log4j BOM 2.23.1:
[INFO]
[INFO] Apache Log4j BOM ... FAILURE [ 38.689 s]
[INFO] Apache Log4j Parent  SKIPPED

Gary

On Wed, Mar 6, 2024 at 9:23 AM Volkan Yazıcı  wrote:
>
> Could you retry after cleaning up your local repository, please? That is,
>
> rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1*
>
>
>
> On Wed, Mar 6, 2024 at 3:03 PM Gary Gregory  wrote:
>
> > I get a build failure:
> >
> > INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
> > [ERROR] project.build.outputTimestamp property should not be inherited
> > but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
> > Downloading from reference:
> >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
> > [INFO] Reference buildinfo file not found: it will be generated from
> > downloaded reference artifacts
> > Downloading from reference:
> >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > Downloaded from reference:
> >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
> > (12 kB at 86 kB/s)
> > Downloading from reference:
> >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > Downloaded from reference:
> >
> > https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
> > (704 kB at 949 kB/s)
> > [INFO] Minimal buildinfo generated from downloaded artifacts:
> >
> > /Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
> > [ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
> > with diffoscope
> > target/reference/org.apache.logging.log4j/log4j-bom-2.23.1-cyclonedx.xml
> > target/bom.xml
> > [ERROR] Reproducible Build output summary: 1 files ok, 1 different
> > [ERROR] see diff target/reference/log4j-bom-2.23.1.buildinfo
> > target/log4j-bom-2.23.1.buildinfo
> > [ERROR] see also
> > https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> > [INFO] Reproducible Build output comparison saved to
> > /Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
> > [INFO] Aggregate 

Re: [VOTE] Release Apache Log4j 2.23.1

[Gary Gregory]

I get a build failure:

INFO] --- artifact:3.5.0:compare (default-cli) @ log4j-bom ---
[ERROR] project.build.outputTimestamp property should not be inherited
but defined in POM /Users/garydgregory/rc/log4j/src/.flattened-pom.xml
Downloading from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.buildinfo
[INFO] Reference buildinfo file not found: it will be generated from
downloaded reference artifacts
Downloading from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
Downloaded from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1.pom
(12 kB at 86 kB/s)
Downloading from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
Downloaded from reference:
https://repository.apache.org/content/repositories/orgapachelogging-1261/org/apache/logging/log4j/log4j-bom/2.23.1/log4j-bom-2.23.1-cyclonedx.xml
(704 kB at 949 kB/s)
[INFO] Minimal buildinfo generated from downloaded artifacts:
/Users/garydgregory/rc/log4j/src/target/reference/log4j-bom-2.23.1.buildinfo
[ERROR] sha512 mismatch log4j-bom-2.23.1-cyclonedx.xml: investigate
with diffoscope
target/reference/org.apache.logging.log4j/log4j-bom-2.23.1-cyclonedx.xml
target/bom.xml
[ERROR] Reproducible Build output summary: 1 files ok, 1 different
[ERROR] see diff target/reference/log4j-bom-2.23.1.buildinfo
target/log4j-bom-2.23.1.buildinfo
[ERROR] see also
https://maven.apache.org/guides/mini/guide-reproducible-builds.html
[INFO] Reproducible Build output comparison saved to
/Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
[INFO] Aggregate buildcompare copied to
/Users/garydgregory/rc/log4j/src/target/log4j-bom-2.23.1.buildcompare
[INFO] 
[INFO] Reactor Summary for Apache Log4j BOM 2.23.1:
[INFO]
[INFO] Apache Log4j BOM ... FAILURE [ 37.006 s]
[INFO] Apache Log4j Parent  SKIPPED


Running:
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO

where NEXUS_REPO is
https://repository.apache.org/content/repositories/orgapachelogging-1261

Using:

openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment Homebrew (build 17.0.10+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.10+0, mixed mode, sharing)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.10, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.10/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"

Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64

Gary

On Wed, Mar 6, 2024 at 8:13 AM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j 2.23.1.
>
> Website: https://logging.staged.apache.org/log4j
> GitHub: https://github.com/apache/logging-log4j2
> Commit: fea2a7116160fb1555d578406444b4fc4f0ef2da
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1261
> 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 in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> svn co https://dist.apache.org/repos/... && cd $_
>
> # Verify checksums
> shasum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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/...
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> == Release notes
>
> This release contains several small fixes and some dependency updates.
>
> === Changed
> * Improve performance of `CloseableThreadContext#closeMap()` (#2296)
>
> === Fixed
>
> * Fix handling of `LoggerContextAware` lookups 

Re: [VOTE] Release Apache Log4j 2.23.1

[Gary Gregory]

Hi,

Thank you for creating this RC.

It would be more helpful to provide cut-and-paste instructions. This
does not work obviously:

svn co https://dist.apache.org/repos/... && cd $_

Neither the "svn co" nor the cd "$_" will work ;-)

Gary

On Wed, Mar 6, 2024 at 8:13 AM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j 2.23.1.
>
> Website: https://logging.staged.apache.org/log4j
> GitHub: https://github.com/apache/logging-log4j2
> Commit: fea2a7116160fb1555d578406444b4fc4f0ef2da
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1261
> 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 in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> svn co https://dist.apache.org/repos/... && cd $_
>
> # Verify checksums
> shasum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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/...
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> == Release notes
>
> This release contains several small fixes and some dependency updates.
>
> === Changed
> * Improve performance of `CloseableThreadContext#closeMap()` (#2296)
>
> === Fixed
>
> * Fix handling of `LoggerContextAware` lookups (#2309)
> * Fix NPE in `PatternProcessor` for a `UNIX_MILLIS` pattern (#2346)
> * Fix that parameterized message formatting doesn't throw an exception
> when there are insufficient number of parameters (#2343)
> * Fix `StatusLogger` log level filtering when debug mode is enabled (#2337)
> * Add `log4j2.StatusLogger.dateFormatZone` system property to set the
> time-zone `StatusLogger` uses to format `java.time.Instant`. Without
> this, formatting patterns accessing to time-zone-specific fields
> (e.g., year-of-era) cause failures. (#2322)
> * Fix `StatusLogger` to correctly read
> `log4j2.StatusLogger.properties` resource (#2354)
> * Fix stack overflow in `StatusLogger` (#2322)
>
> === Updated
>
> * Update `jakarta.activation:jakarta.activation-api` to version `2.1.3` 
> (#2335)
> * Update `jakarta.mail:jakarta.mail-api` to version `2.1.3` (#2348)
> * Update `org.apache.commons:commons-compress` to version `1.26.0` (#2304)
> * Update `org.apache.commons:commons-dbcp2` to version `2.12.0` (#2344)
> * Update `org.apache.kafka:kafka-clients` to version `3.7.0` (#2326)
> * Update `org.eclipse.angus:angus-activation` to version `2.0.2` (#2336)
> * Update `org.eclipse.angus:jakarta.mail` to version `2.0.3` (#2349)

Re: [VOTE] Release Apache Log4j 3.0.0-beta2 RC1

[Gary Gregory]

+1

Note that the verification instructions below or the distro process or
both need changes because the wget and all commands get EVERYTHING and
work on EVERYTHING, which in this case means that BOTH release
candidates for 2.23.0 and 3.0.0-beta2 are downloaded and instructions
work on both at the same time, obviously not the intent.

Over at Commons, we account for this use case by using the version in
the distro folder, so, for example, here you'd RC in
https://dist.apache.org/repos/dist/dev/logging/log4j/3.0.0-beta2, not
https://dist.apache.org/repos/dist/dev/logging/log4j

- Tested src zip file
- ASC OK
- SHA512 OK
- mvn clean verify OK

Using:

openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment Homebrew (build 17.0.9+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.9+0, mixed mode, sharing)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.9, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"

Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64

Gary

On Sun, Feb 18, 2024 at 8:07 AM Piotr P. Karwasz
 wrote:
>
> This is a vote to release the Apache Log4j 3.0.0-beta2.
>
> Website: https://logging.staged.apache.org/log4j/3.x/
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 086db24a04f905b40649666aafe3bb4778a75291
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1259
> 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.
>
> Countdown: 
> https://www.timeanddate.com/countdown/generic?iso=20240221T0807=1440=cursive
>
> == Verification instructions
>
> The following environment is required to verify the build:
>  * any UNIX OS,
>  * JDK 17
>
> Short verification procedure:
>
> # Download distribution
> wget --recursive --no-parent --cut-dirs=5 --no-host-directories \
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> # Verify hashes
> sha512sum -c *sha512
> # Verify signatures
> for sig in *asc; do gpg --verify $sig; done
> # Prepare build environment:
> unzip -d src apache-log4j-3.0.0-beta2-src.zip && cd src
> umask 0022
> # Run build and verification
> ./mvnw clean verify artifact:compare -Prelease \
> -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1258
>
> == Release Notes
>
> This release provides a continuation of the modularisation process of
> Log4j Core.
> The following features were moved to separate artifacts:
>
> * The async logger feature was moved to `log4j-async-logger` and it
> was upgraded to use LMAX Disruptor 4.x.
> The async appender is still available by default in `log4j-core`.
> * The YAML configuration is available now in `log4j-config-yaml`.
> * The Java properties configuration was removed and replaced with a
> similar format based on `jackson-dataformat-properties` in a new
> `log4j-config-properties` artifact.
>
> Other features were removed:
>
> * Jetty 9.x users are encouraged to migrate to Jetty 10.x or later and
> replace `log4j-appserver` with `log4j-slf4j2-impl`.
> * Tomcat JULI support will be available from a third-party (cf.
> https://github.com/copernik-eu/log4j-plugins).
> * Apache Commons Logging users are encouraged to upgrade
> `commons-logging` to version 1.3.0 or later and remove `log4j-jcl`.
> * Support for the XML layout was dropped.
> * Support for JMX was dropped and will be replaced with a more recent
> technology.
>
> === Added
>
> * Add and update DSLs for setting up dependency injection for test and
> non-test code. (#2147)
> * Add a `ConfigurationExtension` mechanism to allow third-party JARs
> to extend the `` element.
> * Add a new properties configuration factory based on
> `jackson-dataformat-properties`.
>
> === 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)
> * Split off async logger support into a new `log4j-async-logger` module.
> * Split off YAML configuration into a new `log4j-config-yaml` module.
>
> === Fixed
>
> * Rewrote message parameter formatter with improved escape handling (#1626)
> * The MongoDb4 appender now supports long values to configure
> `collectionSize` (#1747)
> * Mark `JdkMapAdapterStringMap` as 

Re: [VOTE] Release Apache Log4j 2.23.0 RC1

[Gary Gregory]

+1

- Testing src zip file.
- ASC OK
- SHA512 OK
- mvn clean verify OK

openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment Homebrew (build 17.0.9+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.9+0, mixed mode, sharing)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.9, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"

Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64

Gary

On Sat, Feb 17, 2024 at 8:15 AM Piotr P. Karwasz
 wrote:
>
> This is a vote to release the Apache Log4j 2.23.0.
>
> Website: https://logging.staged.apache.org/log4j/2.x/
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 73da9013314ba8afe459baf52f3360ca1a2df51f
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1258
> 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.
>
> Countdown: 
> https://www.timeanddate.com/countdown/generic?iso=20240220T1315=1440=cursive
>
> == Verification instructions
>
> The following environment is required to verify the build:
>  * any UNIX OS,
>  * JDK 17
>
> Short verification procedure:
>
> # Download distribution
> wget --recursive --no-parent --cut-dirs=5 --no-host-directories
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> # Verify hashes
> sha512-sum -c *sha512
> # Verify signatures
> for sig in *asc; do gpg --verify $sig; done
> # Prepare build environment:
> unzip -d src apache-log4j-2.23.0-src.zip && cd src
> umask 0022
> # Run build and verification
> ./mvnw clean verify -Prelease
> -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1258
>
> == Release Notes
>
> This release adds support for LMAX Disruptor 4.x and several
> performance and bug fixes.
>
> In order to maintain compatibility with JRE 8, support for LMAX
> Disruptor 3.x is maintained.
>
> === Added
>
> * Added support for LMAX Disruptor 4.x (#1821)
>
> === Changed
>
> * Simplify BND configuration after upgrade from version `6.4.1` to `7.0.0`
>
> === Deprecated
>
> * Deprecate the configuration attribute `verbose` (i.e.,
> ` (#2226)
> * Deprecated the `RingBufferLogEventHandler` class for removal from
> the public API in 3.x
>
> === Fixed
>
> * Fix regression in `JdkMapAdapterStringMap` performance. (#2238)
> * Fix the behavior of `Logger#setLevel` and `Logger#getLevel` in the
> Log4j 1.2 bridge. (#2282)
> * Fix the behavior of `CoreLogger#getLevel` and `CoreLogger#setLevel`
> in the `log4j-jul` module. (#2282)
> * Allow deserialization of all arrays of allowed classes.
> (https://issues.apache.org/jira/browse/LOG4J2-3680[LOG4J2-3680])
> * Allow the  node to appear in any position in the
> configuration element.
> * Fix forgotten `threadName` field in `RingBufferLogEvent#clear()` (#2234)
> * Fix `StringBuilder` cache corruption on recursive access
> * Fixed use of `SecurityManager` in `LoaderUtil` where
> `AccessController::doPrivileged` should only be invoked when a
> `SecurityManager` is installed. Some runtimes do not seem to have this
> method available. (#2129)
> * Fix `log4j-spring-cloud-config-client` dependencies to include only
> those required. (#2157)
> * Fix typo in Kubernetes `clientKeyData` configuration property.
>
> === Updated
>
> * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.1` (#2126)
> * Update `commons-codec:commons-codec` to version `1.16.1` (#2277)
> * Update `io.netty:netty-bom` to version `4.1.107.Final` (#2284)
> * Update `org.apache.logging:logging-parent` to version `10.6.0` (#2197)
> * Update `org.eclipse.jetty:jetty-bom` to version `9.4.54.v20240208` (#2287)
> * Update `org.jctools:jctools-core` to version `4.0.3` (#2270)
> * Update `org.springframework:spring-framework-bom` to version `5.3.32` 
> (#2293)
> * Update `org.zeromq:jeromq` to version `0.6.0` (#2271)
>
> Piotr

Re: Version 2.23.0 release schedule

[Gary Gregory]

Cool beans.

Gary

On Sat, Feb 17, 2024, 12:55 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Sat, 17 Feb 2024 at 03:12, Gary Gregory  wrote:
> >
> > Hi Piotr,
> >
> > Are you planning for a RC?
>
> Yes, I'll prepare a release this weekend.
>
> Piotr
>

Re: Version 2.23.0 release schedule

[Gary Gregory]

Hi Piotr,

Are you planning for a RC?

Gary

On Wed, Feb 14, 2024 at 8:12 AM Gary Gregory  wrote:
>
> FYI, the 1.2 bridge is fixed now. Not sure if the bug is present or not for 
> JUL.
>
> Gary
>
> On Mon, Feb 12, 2024, 8:07 AM Piotr P. Karwasz  
> wrote:
>>
>> Hi Gary,
>>
>> On Mon, 12 Feb 2024 at 13:22, Gary Gregory  wrote:
>> >
>> > I'll continue later today to try and fix the set Level issue...
>>
>> Great! I have created a bug for that:
>>
>> https://github.com/apache/logging-log4j2/issues/2281
>>
>> Piotr

Re: Migrate *all* Issue Tracking and Discussions to GitHub

[Gary Gregory]

Keep in mind that decisions for the project still must be recorded on the
mailing list. This might be a silly reminder since the issue is the same
with Jira. Let's just be mindful of this information tracking as we've
moved more of our infrastructure to GitHub. Don't get me wrong, I love
working with GitHub, I just want to make sure that we play by our Apache
rules.

Gary

On Wed, Feb 14, 2024, 8:47 AM Robert Middleton 
wrote:

> I have no strong feelings either way.  Turning on github discussions is a
> good idea in my mind.
>
> +0
>
> -Robert Middleton
>
> On Tue, Feb 13, 2024 at 12:45 PM Jan Friedrich  >
> wrote:
>
> > +1 from me
> >
> > Jan
> >
> > XA> +1.
> > XA> 
> > XA> From: Matt Sicker 
> > XA> Sent: Wednesday, February 14, 2024 1:22:48 AM
> > XA> To: Apache Logging Developers List 
> > XA> Subject: Re: Migrate *all* Issue Tracking and Discussions to GitHub
> >
> > XA> I think it’s a good idea, especially since Jira registrations are
> > closed.
> >
> > >> On Feb 13, 2024, at 02:20, Volkan Yazıcı  wrote:
> > >>
> > >> Log4j has deprecated JIRA in favor of GitHub Issues and enabled GitHub
> > >> Discussions as an alternative (not replacement!) to mailing lists. So
> > far
> > >> it has been a great success[1]. I suggest doing the same for Log4cxx
> and
> > >> Log4net too. Thoughts? Objections?
> > >>
> > >> Note that I am not talking about only enabling these features. But to
> > >> actively promote them on the website too. Check out the Log4j support
> > page
> > >>  for an example.
> > >>
> > >> [1] Code was already on GitHub. Now we can refer to PRs, issues,
> > commits,
> > >> code blocks, etc. while having conversations on any GitHub text
> input. I
> > >> find this quite convenient. IMO, as a result of this convenience, I
> see
> > way
> > >> more maintainer engagement in PRs and issues. Next to that, GitHub
> > >> Discussions clearly enabled more user interactions. It works around
> the
> > >> mailing list subscription barrier.
> >
> >
>

Re: Version 2.23.0 release schedule

[Gary Gregory]

FYI, the 1.2 bridge is fixed now. Not sure if the bug is present or not for
JUL.

Gary

On Mon, Feb 12, 2024, 8:07 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Mon, 12 Feb 2024 at 13:22, Gary Gregory  wrote:
> >
> > I'll continue later today to try and fix the set Level issue...
>
> Great! I have created a bug for that:
>
> https://github.com/apache/logging-log4j2/issues/2281
>
> Piotr
>

Re: Usage examples of flow messages

[Gary Gregory]

I think I invented this extra stuff back when I was co-writing a
proprietary, complex, and feature-rich JDBC driver. I no longer live
in that particular code base, but I can say that writing this kind of
code and implementing a specification like JDBC makes you write code
to a logging library rather differently from anything else. You want a
logging API that is rich, expressive, and efficient. Log4j 2 is all of
that.

For the curious: We only log using DEBUG and TRACE. We want to focus
on using TRACE for APIs and wire-level data. This leaves DEBUG for
everything else, and then we use markers.

I toyed with the idea of adding a custom WIRE level that would be
finer than TRACE but never pulled the trigger on that.

Gary

On Tue, Feb 13, 2024 at 7:09 AM Apache  wrote:
>
> Yes, add the missing method.
>
> We use these methods A LOT. I suspect we are not alone.
>
> Ralph
>
> > On Feb 13, 2024, at 3:17 AM, Piotr P. Karwasz  
> > wrote:
> >
> > Hi all,
> >
> > Our Logger interface contains 11 traceEntry/traceExit methods and 4
> > deprecated entry/exit methods. As far as I have seen, only the
> > deprecated ones are documented in [1].
> >
> > I understand the purpose of some of them:
> >
> > * entry(Object...) and its vararg-free version entry() can be used to
> > log the parameters of a method call,
> > * why is there not traceEntry(Object...) non-deprecated method?
> > * exit(R), exit(), traceExit(R) and traceExit() log the return value
> > of a method call.
> >
> > For those that want to be creative, you can add a custom format
> > specifier, so we have
> >
> > * traceEntry(String, Object...) for input parameters,
> > * traceExit(String, R) for the return value,
> > * there is no traceExit(String) variant for methods returning void.
> >
> > If someone wants the exit message to cite parameters again, you can
> > use `traceExit(EntryMessage, R)` or `traceExit(EntryMessage)`.
> >
> > However these seem pretty much useless to me:
> >
> > * traceEntry(Supplier...), traceEntry(String, Supplier...) seem like
> > overkill, since you usually log parameters that are already evaluated,
> > * traceEntry(Message) and traceExit(Message, R) seem also overkill to
> > me: if the user is not satisfied with providing a format specifier, he
> > can call trace(Message) or trace(Supplier) with the message of his
> > choice.
> >
> > Should we add the missing `traceEntry(Object...)` and `traceExit()`
> > methods and deprecate those above?
> >
> > In general I don't see users today using those methods directly in
> > their code. If they use them, they probably use AspectJ or a similar
> > framework to decorate the messages. In such a case they probably use 2
> > methods of the 15 above.
> >
> > Piotr
> >
> > [1] https://logging.apache.org/log4j/2.x/manual/messages.html
>

Re: [VOTE] Move Chainsaw to dormant

[Gary Gregory]

+1

Gary

On Mon, Feb 12, 2024 at 4:32 PM Christian Grobmeier
 wrote:
>
> Hello,
>
> This vote is to put Chainsaw to the "Dormant" components. There is much work 
> to be done on this component, but not enough hours can be committed to do 
> that work. To reflect this situation to the user, it is better to move 
> Chainsaw to the dormant section and communicate it as "no longer maintained." 
>  The component can be moved back to the "active" state whenever people are 
> actively working on it. The main branch in the repository will be marked with 
> the new state, but the repository will not be archived for now.
>
> Please note:
>
> [ ] +1, move to dormant
> [ ]  -1, don't because...
>
> I will leave this vote open for the usual 72 hours.
>
> Thank you!
>
> Kind regards,
> Christian

Re: Version 2.23.0 release schedule

[Gary Gregory]

I'll continue later today to try and fix the set Level issue...

Gary

On Mon, Feb 12, 2024, 6:15 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> This week I was planning to perform a 2.23.0 release. According to
> Github most of the issues scheduled for this milestone are resolved:
>
> https://github.com/apache/logging-log4j2/milestone/9
>
> Are there any other issues I should be waiting for?
>
> Piotr
>

Re: Using the Log4j 1.2 bridge.

[Gary Gregory]

To make sure I understand, you are saying the bug is in
org.apache.logging.log4j.core.Logger.setLevel(Level)?

Gary

On Sat, Feb 10, 2024 at 5:24 PM Piotr P. Karwasz
 wrote:
>
> Hi Gary,
>
> On Sat, 10 Feb 2024 at 18:14, Gary Gregory  wrote:
> > In my branch 
> > https://github.com/garydgregory/commons-logging/tree/log4j1-log42-api
> > I have test failures where all 6 events are logged instead of 4 by the
> > existing test that calls (mvn clean verify): Unexpected number of log
> > events expected:<4> but was:<6> based on:
> >
> > private void logPlainMessages(final Log log) {
> > log.trace("trace"); // Should not actually get logged
> > log.debug("debug"); // Should not actually get logged
> > log.info("info");
> > log.warn("warn");
> > log.error("error");
> > log.fatal("fatal");
> > }
>
> Before the test is executed, Log4j 2.x is configured through the Log4j
> 1.x interface.
>
> public void setUpTestAppender(final List logEvents) {
> final TestAppender appender = new TestAppender(logEvents);
> final Logger rootLogger = Logger.getRootLogger();
> rootLogger.removeAllAppenders();
> rootLogger.addAppender(appender);
> rootLogger.setLevel(Level.INFO);
> }
>
> The problem is in the `rootLogger.setLevel` call, which delegates to
> `core.Logger#setLevel`.
>
> The last one is broken: it modifies the `PrivateConfig` of the logger,
> but does not modify the underlying `LoggerConfig`.
> Therefore the level change does not propagate to the whole hierarchy.
>
> I will be preparing version 2.23.0. Feel free to fix the bug or submit a PR.
>
> Piotr

Re: Using the Log4j 1.2 bridge.

[Gary Gregory]

Thank you Piotr! I'll poke around...

Gary

On Sat, Feb 10, 2024, 5:24 PM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Sat, 10 Feb 2024 at 18:14, Gary Gregory  wrote:
> > In my branch
> https://github.com/garydgregory/commons-logging/tree/log4j1-log42-api
> > I have test failures where all 6 events are logged instead of 4 by the
> > existing test that calls (mvn clean verify): Unexpected number of log
> > events expected:<4> but was:<6> based on:
> >
> > private void logPlainMessages(final Log log) {
> > log.trace("trace"); // Should not actually get logged
> > log.debug("debug"); // Should not actually get logged
> > log.info("info");
> > log.warn("warn");
> > log.error("error");
> > log.fatal("fatal");
> > }
>
> Before the test is executed, Log4j 2.x is configured through the Log4j
> 1.x interface.
>
> public void setUpTestAppender(final List logEvents) {
> final TestAppender appender = new TestAppender(logEvents);
> final Logger rootLogger = Logger.getRootLogger();
> rootLogger.removeAllAppenders();
> rootLogger.addAppender(appender);
> rootLogger.setLevel(Level.INFO);
> }
>
> The problem is in the `rootLogger.setLevel` call, which delegates to
> `core.Logger#setLevel`.
>
> The last one is broken: it modifies the `PrivateConfig` of the logger,
> but does not modify the underlying `LoggerConfig`.
> Therefore the level change does not propagate to the whole hierarchy.
>
> I will be preparing version 2.23.0. Feel free to fix the bug or submit a
> PR.
>
> Piotr
>

Fwd: Using the Log4j 1.2 bridge.

[Gary Gregory]

Hi All and Piotr mostly (since you did the 2.x code in Commons Logging),

[ Background: My reply
https://lists.apache.org/thread/rcxkfffg9pfj9662d1fxlyo4l8cv2yyq to
the post https://lists.apache.org/thread/w5yq2locvdt8yhf8k9075vgjg1kw5569
]

In my branch 
https://github.com/garydgregory/commons-logging/tree/log4j1-log42-api
I have test failures where all 6 events are logged instead of 4 by the
existing test that calls (mvn clean verify): Unexpected number of log
events expected:<4> but was:<6> based on:

private void logPlainMessages(final Log log) {
log.trace("trace"); // Should not actually get logged
log.debug("debug"); // Should not actually get logged
log.info("info");
log.warn("warn");
log.error("error");
log.fatal("fatal");
}

It turns out that I see this in the test resources, log4j2-test.xml:












I can understand that the above v2 file does not kick in before my
branch since the problematic test is a v1 test. But, now that this
test ends up using the 1.2-api bridge, the file is in play.

How do I make the 1.x test point to a different file so that the code
passes as is?

TY,
Gary

Re: [Log4j] If and how to document potential OOME

[Gary Gregory]

Oh, I don't want to suggest this is a Lo4j issue at all. I am wondering if
there is a pattern we should document aside from "know your third party
objects" which is not helpful for us to say. It sounds like there is
nothing for us to do.

Gary

On Fri, Jan 26, 2024, 7:16 AM Apache  wrote:

> That is kind of my point. Anyone who logs an object that behaves this way
> is asking for trouble. It really sounds like an esoteric edge case to me. I
> don’t view this as a Log4J problem as the error wouldn’t even have Log4J in
> the stack trace.
>
> Ralph
>
> > On Jan 25, 2024, at 9:52 PM, Gary Gregory 
> wrote:
> >
> > I have no control over this. I think this is a general problem with
> third
> > party objects and toString(). There is no toString(fromHereToThere) or
> > toStringReader() so I can't see a general way to deal with it. Even if I
> > created a wrapper for the Object and called toString(), truncated and
> > cached the result and have the wrapper return the shorter string in its
> > toString(), I still would have toString()'d the original...
> >
> > Gary
> >
> >> On Thu, Jan 25, 2024, 11:33 PM Ralph Goers 
> >> wrote:
> >>
> >> OK. The only good way to handle that is to parse the YAML/JSON file
> while
> >> streaming it and extract just the fields you want to include in the
> logs.
> >>
> >> Ralph
> >>
> >>> On Jan 25, 2024, at 6:40 PM, Gary Gregory 
> >> wrote:
> >>>
> >>> Well, it's worse than that because the object is an object created by
> >>> parsing a YAML (or JSON) file, then the toString() of that object
> >>> renders a String in some other format.
> >>>
> >>> Gary
> >>>
> >>> On Thu, Jan 25, 2024 at 7:45 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> >> wrote:
> >>>>
> >>>> Volkan & Matt,
> >>>>
> >>>> Neither of those is going to help. The issue is that when the toString
> >> method is called it reads a whole file in and stores it as a String.
> This
> >> could cause the OOM error. Truncating it in a layout simply limits how
> much
> >> of the String is printed. Even Gary’s proposal of calling substring() is
> >> still going to operate on the whole String. He would really need a
> method
> >> that accepts the max number of characters to read from the file.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Jan 25, 2024, at 2:49 PM, Volkan Yazıcı  wrote:
> >>>>>
> >>>>> *[Just responding to Matt. I don't have an answer for Gary.]*
> >>>>>
> >>>>> `JsonTemplateLayout` has `maxStringLength`, and related with it,
> >>>>> `truncatedStringSuffix`.
> >>>>>
> >>>>> On Thu, Jan 25, 2024 at 9:45 PM Matt Sicker 
> wrote:
> >>>>>
> >>>>>> You can use the %maxLength{…}{N} pattern converter with
> PatternLayout
> >> at
> >>>>>> least. Unfortunately, I don’t think any other layouts support a
> >> similar
> >>>>>> option.
> >>>>>>
> >>>>>>> On Jan 25, 2024, at 10:55, Gary D. Gregory 
> >> wrote:
> >>>>>>>
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> I'd like to ask how to if we can devise advice around an issue I
> ran
> >>>>>> into this week.
> >>>>>>>
> >>>>>>> One of our test suites processes about 40K files of test fixtures.
> >> These
> >>>>>> inputs are parsed, processed, and asserted. This randomly fails on a
> >> call
> >>>>>> to Logger#debug(), randomly in that it happens usually once per
> build,
> >>>>>> somewhere in a logging call. But it usually fails with a call that
> >> looks
> >>>>>> like this:
> >>>>>>>
> >>>>>>> logger.debug("This is fun" + myFunObject);
> >>>>>>>
> >>>>>>> To simplify things, let's say that it turns out that after an
> >> underlying
> >>>>>> third party jar file version upgrade the call to
> >> myFunObject#toString() no
> >>>>>> longer returns Object#toString() but rather (again to simplify) the
> >>>>>> contents of the file that was parsed to create myFunObject. This
> >> toString()
> >>>>>> can be megabytes. The solution is obvious:
> >>>>>>>
> >>>>>>> logger.debug("This is fun", myFunObject::toString)
> >>>>>>>
> >>>>>>> And our CI builds no longer randomly fail since our default logging
> >> does
> >>>>>> not log at the debug level.
> >>>>>>>
> >>>>>>> A better solution could be:
> >>>>>>>
> >>>>>>> logger.debug("This is fun", () ->
> myFunObject.toString().substring(0,
> >>>>>> 100))
> >>>>>>>
> >>>>>>> where I still want _some_ information better than making my own
> >>>>>> toString() with System#identityHashCode(Object) or somesuch. Sure,
> >>>>>> .toString() is still called but it does not make it down into
> >> logging. In
> >>>>>> my case the OOME happened in myFunObject::toString so the
> substring()
> >>>>>> example would not have worked.
> >>>>>>>
> >>>>>>> My question is: Should we document some general advice on this
> >> pattern
> >>>>>> and what should the advice be? Would it make sense to have some
> >> features
> >>>>>> where we truncate/reject Strings above a threshold. And yes, calling
> >>>>>> myFunObject.toString() can still still get me in trouble.
> >>>>>>>
> >>>>>>> Gary
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
> >>
>
>

Re: [Log4j] If and how to document potential OOME

[Gary Gregory]

I have no control over this. I think this is a general problem with third
party objects and toString(). There is no toString(fromHereToThere) or
toStringReader() so I can't see a general way to deal with it. Even if I
created a wrapper for the Object and called toString(), truncated and
cached the result and have the wrapper return the shorter string in its
toString(), I still would have toString()'d the original...

Gary

On Thu, Jan 25, 2024, 11:33 PM Ralph Goers 
wrote:

> OK. The only good way to handle that is to parse the YAML/JSON file while
> streaming it and extract just the fields you want to include in the logs.
>
> Ralph
>
> > On Jan 25, 2024, at 6:40 PM, Gary Gregory 
> wrote:
> >
> > Well, it's worse than that because the object is an object created by
> > parsing a YAML (or JSON) file, then the toString() of that object
> > renders a String in some other format.
> >
> > Gary
> >
> > On Thu, Jan 25, 2024 at 7:45 PM Ralph Goers 
> wrote:
> >>
> >> Volkan & Matt,
> >>
> >> Neither of those is going to help. The issue is that when the toString
> method is called it reads a whole file in and stores it as a String. This
> could cause the OOM error. Truncating it in a layout simply limits how much
> of the String is printed. Even Gary’s proposal of calling substring() is
> still going to operate on the whole String. He would really need a method
> that accepts the max number of characters to read from the file.
> >>
> >> Ralph
> >>
> >>> On Jan 25, 2024, at 2:49 PM, Volkan Yazıcı  wrote:
> >>>
> >>> *[Just responding to Matt. I don't have an answer for Gary.]*
> >>>
> >>> `JsonTemplateLayout` has `maxStringLength`, and related with it,
> >>> `truncatedStringSuffix`.
> >>>
> >>> On Thu, Jan 25, 2024 at 9:45 PM Matt Sicker  wrote:
> >>>
> >>>> You can use the %maxLength{…}{N} pattern converter with PatternLayout
> at
> >>>> least. Unfortunately, I don’t think any other layouts support a
> similar
> >>>> option.
> >>>>
> >>>>> On Jan 25, 2024, at 10:55, Gary D. Gregory 
> wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I'd like to ask how to if we can devise advice around an issue I ran
> >>>> into this week.
> >>>>>
> >>>>> One of our test suites processes about 40K files of test fixtures.
> These
> >>>> inputs are parsed, processed, and asserted. This randomly fails on a
> call
> >>>> to Logger#debug(), randomly in that it happens usually once per build,
> >>>> somewhere in a logging call. But it usually fails with a call that
> looks
> >>>> like this:
> >>>>>
> >>>>> logger.debug("This is fun" + myFunObject);
> >>>>>
> >>>>> To simplify things, let's say that it turns out that after an
> underlying
> >>>> third party jar file version upgrade the call to
> myFunObject#toString() no
> >>>> longer returns Object#toString() but rather (again to simplify) the
> >>>> contents of the file that was parsed to create myFunObject. This
> toString()
> >>>> can be megabytes. The solution is obvious:
> >>>>>
> >>>>> logger.debug("This is fun", myFunObject::toString)
> >>>>>
> >>>>> And our CI builds no longer randomly fail since our default logging
> does
> >>>> not log at the debug level.
> >>>>>
> >>>>> A better solution could be:
> >>>>>
> >>>>> logger.debug("This is fun", () -> myFunObject.toString().substring(0,
> >>>> 100))
> >>>>>
> >>>>> where I still want _some_ information better than making my own
> >>>> toString() with System#identityHashCode(Object) or somesuch. Sure,
> >>>> .toString() is still called but it does not make it down into
> logging. In
> >>>> my case the OOME happened in myFunObject::toString so the substring()
> >>>> example would not have worked.
> >>>>>
> >>>>> My question is: Should we document some general advice on this
> pattern
> >>>> and what should the advice be? Would it make sense to have some
> features
> >>>> where we truncate/reject Strings above a threshold. And yes, calling
> >>>> myFunObject.toString() can still still get me in trouble.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>
> >>>>
> >>
>
>

Re: [Log4j] If and how to document potential OOME

[Gary Gregory]

Well, it's worse than that because the object is an object created by
parsing a YAML (or JSON) file, then the toString() of that object
renders a String in some other format.

Gary

On Thu, Jan 25, 2024 at 7:45 PM Ralph Goers  wrote:
>
> Volkan & Matt,
>
> Neither of those is going to help. The issue is that when the toString method 
> is called it reads a whole file in and stores it as a String. This could 
> cause the OOM error. Truncating it in a layout simply limits how much of the 
> String is printed. Even Gary’s proposal of calling substring() is still going 
> to operate on the whole String. He would really need a method that accepts 
> the max number of characters to read from the file.
>
> Ralph
>
> > On Jan 25, 2024, at 2:49 PM, Volkan Yazıcı  wrote:
> >
> > *[Just responding to Matt. I don't have an answer for Gary.]*
> >
> > `JsonTemplateLayout` has `maxStringLength`, and related with it,
> > `truncatedStringSuffix`.
> >
> > On Thu, Jan 25, 2024 at 9:45 PM Matt Sicker  wrote:
> >
> >> You can use the %maxLength{…}{N} pattern converter with PatternLayout at
> >> least. Unfortunately, I don’t think any other layouts support a similar
> >> option.
> >>
> >>> On Jan 25, 2024, at 10:55, Gary D. Gregory  wrote:
> >>>
> >>> Hi All,
> >>>
> >>> I'd like to ask how to if we can devise advice around an issue I ran
> >> into this week.
> >>>
> >>> One of our test suites processes about 40K files of test fixtures. These
> >> inputs are parsed, processed, and asserted. This randomly fails on a call
> >> to Logger#debug(), randomly in that it happens usually once per build,
> >> somewhere in a logging call. But it usually fails with a call that looks
> >> like this:
> >>>
> >>> logger.debug("This is fun" + myFunObject);
> >>>
> >>> To simplify things, let's say that it turns out that after an underlying
> >> third party jar file version upgrade the call to myFunObject#toString() no
> >> longer returns Object#toString() but rather (again to simplify) the
> >> contents of the file that was parsed to create myFunObject. This toString()
> >> can be megabytes. The solution is obvious:
> >>>
> >>> logger.debug("This is fun", myFunObject::toString)
> >>>
> >>> And our CI builds no longer randomly fail since our default logging does
> >> not log at the debug level.
> >>>
> >>> A better solution could be:
> >>>
> >>> logger.debug("This is fun", () -> myFunObject.toString().substring(0,
> >> 100))
> >>>
> >>> where I still want _some_ information better than making my own
> >> toString() with System#identityHashCode(Object) or somesuch. Sure,
> >> .toString() is still called but it does not make it down into logging. In
> >> my case the OOME happened in myFunObject::toString so the substring()
> >> example would not have worked.
> >>>
> >>> My question is: Should we document some general advice on this pattern
> >> and what should the advice be? Would it make sense to have some features
> >> where we truncate/reject Strings above a threshold. And yes, calling
> >> myFunObject.toString() can still still get me in trouble.
> >>>
> >>> Gary
> >>>
> >>
> >>
>

Re: [Log4j] If and how to document potential OOME

[Gary Gregory]

Obvious mistake:

logger.debug("This is fun", myFunObject::toString)
->
logger.debug("This is fun {}", myFunObject::toString)

Gary


On Thu, Jan 25, 2024, 11:55 AM Gary D. Gregory  wrote:

> Hi All,
>
> I'd like to ask how to if we can devise advice around an issue I ran into
> this week.
>
> One of our test suites processes about 40K files of test fixtures. These
> inputs are parsed, processed, and asserted. This randomly fails on a call
> to Logger#debug(), randomly in that it happens usually once per build,
> somewhere in a logging call. But it usually fails with a call that looks
> like this:
>
> logger.debug("This is fun" + myFunObject);
>
> To simplify things, let's say that it turns out that after an underlying
> third party jar file version upgrade the call to myFunObject#toString() no
> longer returns Object#toString() but rather (again to simplify) the
> contents of the file that was parsed to create myFunObject. This toString()
> can be megabytes. The solution is obvious:
>
> logger.debug("This is fun", myFunObject::toString)
>
> And our CI builds no longer randomly fail since our default logging does
> not log at the debug level.
>
> A better solution could be:
>
> logger.debug("This is fun", () -> myFunObject.toString().substring(0, 100))
>
> where I still want _some_ information better than making my own toString()
> with System#identityHashCode(Object) or somesuch. Sure, .toString() is
> still called but it does not make it down into logging. In my case the OOME
> happened in myFunObject::toString so the substring() example would not have
> worked.
>
> My question is: Should we document some general advice on this pattern and
> what should the advice be? Would it make sense to have some features where
> we truncate/reject Strings above a threshold. And yes, calling
> myFunObject.toString() can still still get me in trouble.
>
> Gary
>
>

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Gary Gregory]

Using the same API jar for 3.x core is intriguing. I like the idea of
a cleaned-up API jar (no custom Supplier) that can front 2.x and 3.x.

I'd love to hash this out in a call.

Gary

On Thu, Jan 18, 2024 at 12:02 AM Ralph Goers  wrote:
>
> The quick answer to this question is “I don’t know”. When we first started on 
> the 3.x adventure I can assure you that log4j-api was very different in the 
> 3.x branch because of the changes we needed to make for JPMS and to the 
> build. However, since we have since carried those changes back to 2.x to a 
> large degree it may be that you are correct and we don’t need to create a 3.x 
> version of the API.
>
> We would need to compare the two branches of log4j-api and see what the 
> differences are.
>
> Ralph
>
> > On Jan 17, 2024, at 9:11 AM, Volkan Yazıcı  wrote:
> >
> > Given Ralph and Piotr are strongly opinionated about keeping
> > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release
> > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x`
> > instead? (We can move the contents of the `spi` package in `log4j-api-3.x`
> > to a separate `log4j-spi` module in `main`.) This will make everything
> > crystal clear:
> >
> >   - Log4j 3 is just a major improvement over the backend
> >   - Log4j 3 still supports Log4j 2 API
> >   - We can move the Log4j 2 API to a separate repository with its own
> >   release life cycle (ala SLF4J)
> >   - When time comes to make a new Log4j API where PMC agrees to make
> >   breaking changes, we can call that one Log4j 3 API
> >
> > I would appreciate it if you can help me to understand if I am
> > missing something. Otherwise, I would like to know why we need to make a
> > major release for a project that is identical to its previous version.
>

Re: [log4j] Performance figures

[Gary Gregory]

Hi Remko! Just saying "Hi".

Gary

On Tue, Jan 16, 2024, 1:40 AM Remko Popma  wrote:

> I’m open to improvements in this area.
>
> Before going into details or specifics though, I’m curious:
>
> What do we (users, developers and PMC members) consider to be the “value
> proposition” of Log4j? Why should people choose Log4j over the
> alternatives?
>
> This is a positioning question; what are the strengths and weaknesses of
> Log4j and how should Log4j position itself in the market of logging
> solutions?
>
> Remko
>
>
> > On Jan 15, 2024, at 22:05, Gary Gregory  wrote:
> >
> > We should IMO keep this information available _somewhere_, maybe in a
> new
> > stable historical-archival section of the site. I'm not a fan of using
> the
> > wiki because that's yet another place to look for information and it
> feels
> > transitory, unstable (as far as information permanance), and more like
> > something we should use (if at all) as a scratch pad.
> >
> > Gary
> >
> >> On Mon, Jan 15, 2024, 7:34 AM Volkan Yazıcı  wrote:
> >>
> >> *TLDR:* I want to remove performance figures from the Log4j website,
> >> because they don't serve any practical value anymore.
> >>
> >> Log4j website shares performance figures in several pages; Performance
> >> <https://logging.apache.org/log4j/2.x/performance.html#benchmarks>,
> >> Asynchronous
> >> Logging
> >> <
> >>
> https://logging.apache.org/log4j/2.x/manual/async.html#asynchronous-logging-performance
> >>> ,
> >> Garbage-free Logging
> >> <https://logging.apache.org/log4j/2.x/manual/garbagefree.html> are
> among
> >> the well-known ones. I want to remove all performance figures and only
> keep
> >> pragmatic recommendations due to following reasons:
> >>
> >>   - *Insufficient relevancy* – Shared figures were mostly produced using
> >>   Log4j version `2.5` and `2.6`. These releases date back from late 2016
> >> and
> >>   *a lot* has changed since then.
> >>   - *Insufficient reliability* – There were many occasions PMC members
> >>   stated they weren't able to reproduce these figures.
> >>   - *Error prone* – As tipped in the website, measuring performance
> >>   correctly is very difficult
> >>   <https://www.infoq.com/presentations/latency-response-time>.
> >>   - *Context dependent* – Performance is an extremely subjective term.
> It
> >>   requires context. What kind of an application? What is the application
> >>   load? What is the logging load? What is the logging setup? etc.
> Sharing
> >> a
> >>   meaningful figure here that users can benefit in any way is, IMHO,
> >>   impossible.
> >>   - *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt
> if
> >>   any of the existing performance figures (produced using ~8 year old
> >> Log4j)
> >>   are applicable to Log4j 3.
> >>
> >> Will we have no performance figures at all? AFAIC, we need to have a
> >> continuous performance testbed that would not only give users an
> indication
> >> about performance of Log4j over time (in a reproducible way!), but also,
> >> maybe more importantly, guide maintainers on making changes affecting
> >> performance. Some of you might recall: I already had implemented some
> stuff
> >> on this subject and had a "a continuous performance testbed"  project
> in my
> >> first STF projects draft. But we needed to drop it due to other pressing
> >> issues and insufficient budget. We can bring it up again if need (and
> >> budget?) arises. Let me know if you and/or your employer would be
> >> interested in funding such an effort.
> >>
>

Re: [log4j] `.asf.yaml` between branches

[Gary Gregory]

Should these files contain comments to this effect?

Gary

On Tue, Jan 16, 2024, 1:18 AM Piotr P. Karwasz 
wrote:

> Hi Ralph,
>
> On Tue, 16 Jan 2024 at 01:56, Ralph Goers 
> wrote:
> >
> > I don’t understand what it means to keep both staging and publish in
> “asf-site”. By definition, the asf-site branch is the live web-site and
> asf-staging is the staging web site.  Are you talking about the build
> scripts or something?
>
> We are talking about this `.asf.yaml` content:
>
> publish:
>   profile: ~
>   whoami: asf-site
>   subdir: content/logging-parent
>
> staging:
>   profile: ~
>   whoami: asf-staging
>   subdir: content/logging-parent
>
> Due to the `whoami` attribute, the `.asf.yaml` file on both the
> `asf-site` and `asf-staging` branch can be the same. INFRA will ignore
> the `staging` instruction on `asf-site` and the `publish` instruction
> on `asf-staging`.
>
> Piotr
>

Re: [log4j] Performance figures

[Gary Gregory]

We should IMO keep this information available _somewhere_, maybe in a new
stable historical-archival section of the site. I'm not a fan of using the
wiki because that's yet another place to look for information and it feels
transitory, unstable (as far as information permanance), and more like
something we should use (if at all) as a scratch pad.

Gary

On Mon, Jan 15, 2024, 7:34 AM Volkan Yazıcı  wrote:

> *TLDR:* I want to remove performance figures from the Log4j website,
> because they don't serve any practical value anymore.
>
> Log4j website shares performance figures in several pages; Performance
> ,
> Asynchronous
> Logging
> <
> https://logging.apache.org/log4j/2.x/manual/async.html#asynchronous-logging-performance
> >,
> Garbage-free Logging
>  are among
> the well-known ones. I want to remove all performance figures and only keep
> pragmatic recommendations due to following reasons:
>
>- *Insufficient relevancy* – Shared figures were mostly produced using
>Log4j version `2.5` and `2.6`. These releases date back from late 2016
> and
>*a lot* has changed since then.
>- *Insufficient reliability* – There were many occasions PMC members
>stated they weren't able to reproduce these figures.
>- *Error prone* – As tipped in the website, measuring performance
>correctly is very difficult
>.
>- *Context dependent* – Performance is an extremely subjective term. It
>requires context. What kind of an application? What is the application
>load? What is the logging load? What is the logging setup? etc. Sharing
> a
>meaningful figure here that users can benefit in any way is, IMHO,
>impossible.
>- *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt if
>any of the existing performance figures (produced using ~8 year old
> Log4j)
>are applicable to Log4j 3.
>
> Will we have no performance figures at all? AFAIC, we need to have a
> continuous performance testbed that would not only give users an indication
> about performance of Log4j over time (in a reproducible way!), but also,
> maybe more importantly, guide maintainers on making changes affecting
> performance. Some of you might recall: I already had implemented some stuff
> on this subject and had a "a continuous performance testbed"  project in my
> first STF projects draft. But we needed to drop it due to other pressing
> issues and insufficient budget. We can bring it up again if need (and
> budget?) arises. Let me know if you and/or your employer would be
> interested in funding such an effort.
>

Re: [log4j] ProGuard support in `log4j-api`

[Gary Gregory]

It feels wrong to add support for a special development time tool in our
runtime.

Gary

On Thu, Jan 11, 2024, 1:58 PM Ralph Goers 
wrote:

> Yeah - if we add it to the code base that implies that we are testing it.
> I really don’t want to be in the position where we start adding
> customizations for every tool a user might be using. This is very much in
> line with our not wanting to keep adding more and more integrations .
>
> Ralph
>
> > On Jan 11, 2024, at 11:36 AM, Volkan Yazıcı  wrote:
> >
> > ProGuard  – a GPL2-licensed,
> > widely used JAR optimizer and obfuscator in the Android world – doesn't
> > work with `log4j-api` out of the box. In summary, since Log4j uses
> > reflection, ProGuard needs to be configured to avoid removing certain
> Log4j
> > classes. A user has submitted (#2182)
> >  the ProGuard
> > configuration addressing the issue. We can either distribute it in
> > `META-INF/proguard/log4j.pro` and make `log4j-api` work out-of-the-box
> with
> > ProGoard or simply document this. Given how certain PMC members are
> > strongly allergic to breaking backward compatibility even in major
> > releases, I am afraid distributing this as a part of `log4j-api` will
> > become a liability we cannot get rid of in our lifetime. I will share
> this
> > with the user and ask him to convert his PR to a documentation update. If
> > you disagree, please let me know.
>
>

Re: Spring 3 and Log4j 3

[Gary Gregory]

Nice! 

On Tue, Jan 9, 2024, 4:45 PM Ralph Goers  wrote:

> FYI - in
> https://github.com/spring-projects/spring-boot/issues/33450#issuecomment-1883014368
> has confirmed that Log4j 3.0.0-beta1 now works correctly with Spring 3.x.
>
> Ralph

Re: PropertyKey abstraction

[Gary Gregory]

FWIW, I'm NOT a fan of the static analysis option. Good design should be
reflected in the code. We should not pick suboptimal abstractions (or no
abstraction in this case) plus static analysis to validate odd design
choices.

Gafy

On Thu, Jan 4, 2024, 11:29 AM Piotr P. Karwasz 
wrote:

> Hi Ralph,
>
> On Thu, 4 Jan 2024 at 16:20, Ralph Goers 
> wrote:
> >
> > PropertyKey was created so that all “components” could be specified as
> an enum value, thus ensuring consistency.
> >
> > The split between component and key is used in every declaration of a
> property.
> >
> > It is unfortunate that the keys also had to be specified as static
> constants so they could be used in @SetSystemProperty. I would have
> preferred to be able to use the getSystemKey method.
> >
> > I do have objections. While the interface and enum usage isn’t perfect
> moving back to static constants is much worse in my opinion. If I hadn’t
> thought that I would have done that in the first place.
> >
> > If you can figure out a better approach just propose that but please
> leave it the way it is until then.
>
> If consistency is the only requirement, we could use a static analysis
> tool to check it. It should be rather easy to write an Error Prone
> plugin that checks that:
>
> 1. The parameters of all calls to `PropertyEnvironment` methods are
> public constant strings annotated with a specific annotation (e.g.
> @Log4jPropertyKey),
> 2. The strings are of the format "." with a
> limited number of possibilities for .
>
> Remark that the list of components is not necessarily closed:
> additional Maven modules or even third-party extensions could need to
> define new component types. E.g. if we split
> `DisruptorBlockingQueueFactory` into a separate Maven module, it will
> still require an entry in `PropertyComponent` to have its own
> properties.
>
> Piotr
>

Re: Reproducibility checks

[Gary Gregory]

Hi Piotr,

Please include whatever instructions you want folks to run in the vote
email to prove reproducibility. Then at least we can agree on what it
means to do the reproducibility check and when it passes or fails,
assuming it's a binary property.

A long-standing pet peeve of mine is PMC members (in many projects,
I'm not singling out Log4j here) that vote on a release candidate
without stating _what_ they did to check the viability of said
release.

If this matters, it should be an Apache requirement, which it is not ATM AFAIK.

Gary



On Wed, Dec 27, 2023 at 4:26 AM Piotr P. Karwasz
 wrote:
>
> Hi Gary,
>
> On Sat, 23 Dec 2023 at 17:45, Gary Gregory  wrote:
> >
> > +1
> > - Tested src zip file
> > - ASC OK
> > - SHA512 OK
> > - `mvn clean verify` OK
> > - Using:
> > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> > Java version: 17.0.9, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.2.1", arch: "x86_64", family: "mac"
> > Darwin  23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10
> > PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64
>
> Could you also add a reproducibility check in your next votes?
>
> For security reasons we can not release artifacts generated by the CI
> unless we can reproduce them locally or we know what exactly is the
> reason they can not be reproduced.
> This burden obviously falls on the Release Manager, but it would be
> nice to have independent confirmations before performing the release.
>
> After an actual release the Hervé's Reproducible Central project also
> verifies our artifacts, the results can be found here:
>
> https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/logging/log4j/log4j/README.md
>
> Additional projects (like Commons Logging) can be added with PRs like this 
> one:
>
> https://github.com/jvm-repo-rebuild/reproducible-central/pull/134
>
> Piotr
>
> PS: I'll try to add PRs for your recent Commons releases, when I'll
> have some time.

Re: [VOTE] Release Apache Log4j Kotlin API 1.4.0

[Gary Gregory]

+1
- Tested src zip file
- ASC OK
- SHA512 OK
- Building 'mvn clean verify' OK
- Using:
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.9, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.2.1", arch: "x86_64", family: "mac"
Darwin  23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10
PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64

Gary

On Wed, Dec 20, 2023 at 1:08 PM Matt Sicker  wrote:
>
> This is a vote to release the Apache Log4j Kotlin API 1.4.0.
>
> Website: https://logging.staged.apache.org/log4j/kotlin
> GitHub: https://github.com/apache/logging-log4j-kotlin
> Commit: ee2d4a8efa16bb2223252329531c94e98ed6d1e6
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1113
> 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.
>
> === Review kit
>
> The minimum set of steps needed to review the uploaded distribution
> files in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> svn co https://dist.apache.org/repos/... && cd $_
>
> # Verify checksums
> shasum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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/...
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
>
> === Release notes
>
>
> This minor release fixes incorrect coroutine context map and stack.
>
>
>  Added
>
> * Started generating CycloneDX SBOM with the recent update of 
> `logging-parent` to version `10.2.0`
>
>  Changed
>
> * Coroutine context is not cleared properly, only appended to (#54)
> * Update `org.apache.logging:logging-parent` to version `10.2.0`
> * Update `org.apache.logging.log4j:log4j-bom` to version `2.22.0` (#52)
> * Update `org.apache.logging:logging-parent` to version `10.4.0` (#53)
> * Update `org.codehaus.mojo:build-helper-maven-plugin` to version `3.5.0` 
> (#51)
> * Update `org.codehaus.mojo:exec-maven-plugin` to version `3.1.1` (#50)
> * Update `org.junit:junit-bom` to version `5.10.1` (#49)

Re: [VOTE] Release Apache Log4j 2.22.1 RC1

[Gary Gregory]

Hi Piotr,

I'm pretty sure there aren't any Apache requirements around tagging in git
(or svn) but it seems nice to me to have tags for release candidates. Not
that big of a deal probably.

Gary

On Sat, Dec 23, 2023, 2:51 PM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Sat, 23 Dec 2023 at 17:47, Gary Gregory  wrote:
> >
> > Question: Where is the git tag in these VOTE emails? I see a "Commit"
> > but no named tag.
>
> The CI does not create tags, but it works on a separate branch
> `release/x.y.z` and the commit should be the last commit of the
> branch.
> Of course providing a SHA1 is safer. Should we also add a tag?
>
> Piotr
>

Re: [VOTE] Release Apache Log4j 2.22.1 RC1

[Gary Gregory]

TY for the references.

Gary

On Sat, Dec 23, 2023 at 2:20 PM Piotr P. Karwasz
 wrote:
>
> Hi Gary,
>
> On Sat, 23 Dec 2023 at 16:23, Gary Gregory  wrote:
> >
> > Can this noise be made quiet in the future please (mvn clean verify -U):
>
> This is a temporary workaround for three `cyclonedx-maven-plugin` limitations.
> We are still waiting for two fixes and a release of the plugin:
>
> https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/419
> https://github.com/CycloneDX/cyclonedx-maven-plugin/pull/428
>
> Piotr

Re: [VOTE] Release Apache Log4j 2.22.1 RC1

[Gary Gregory]

Question: Where is the git tag in these VOTE emails? I see a "Commit"
but no named tag.

Gary

On Fri, Dec 22, 2023 at 1:01 PM Piotr P. Karwasz
 wrote:
>
> This is a vote to release the Apache Log4j 2.22.1.
>
> Website: https://logging.staged.apache.org/log4j/2.x/
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 8469975a4f2b1f8f1bd4f25ca6d1989a52aefc1b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1254
> 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 in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> wget --recursive --no-parent --no-host-directories --cut-dirs=5
> https://dist.apache.org/repos/dist/dev/logging/log4j
>
> # Verify checksums
> sha512sum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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-1254
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
>
> == Release Notes
>
> This release contains only dependency upgrades and bug fixes, which do
> not change the behavior of the artifacts.
>
> While maintaining compatibility with Java 8, the artifacts in this
> release where generated using JDK 17, unlike version `2.22.0` that
> used JDK 11.
>
>
> [#release-notes-2-22-1-fixed]
> === Fixed
>
> * Mark `JdkMapAdapterStringMap` as frozen if map is immutable. (#2098)
> * Fix NPE in `CloseableThreadContext`. (#1426)
> * Use the module name of Conversant Media Disruptor from version
> `1.2.16+` of the library.
> * Fix NPE in `RollingFileManager`. (#1645)
> * Fix `log4j-to-slf4j` JPMS and OSGi descriptors. (#1983)
> * Workaround a Coursier/Ivy dependency resolution bug affecting
> `log4j-slf4j-impl` and `log4j-mongodb3`. (#2065)
>
> [#release-notes-2-22-1-updated]
> === Updated
>
> * Bumped the minimum Java version required for the build to Java 17.
> Runtime requirements remain unchanged. (#2021)
> * Update `com.github.luben:zstd-jni` to version `1.5.5-11` (#2030)
> * Update `com.google.guava:guava` to version `33.0.0-jre` (#2110)
> * Update `commons-codec:commons-codec` to version `1.16.0` (#2042)
> * Update `commons-io:commons-io` to version `2.15.1` (#2034)
> * Update `commons-logging:commons-logging` to version `1.3.0` (#2050)
> * Update `io.netty:netty-bom` to version `4.1.104.Final` (#2095)
> * Update `org.apache.commons:commons-compress` to version `1.25.0` (#2045)
> * Update `org.apache.commons:commons-dbcp2` to version `2.11.0` (#2048)
> * Update `org.apache.commons:commons-lang3` to version `3.14.0` (#2047)
> * Update `org.apache.commons:commons-pool2` to version `2.12.0` (#2057)
> * Update `org.apache.kafka:kafka-clients` to version `3.6.1` (#2068)
> * Update `org.apache.logging:logging-parent` to version `10.5.0` (#2119)
> * Update `org.jctools:jctools-core` to version `4.0.2` (#1984)
> * Update `org.springframework.boot:spring-boot` to version `2.7.18` (#1998)
> * Update `org.springframework.cloud:spring-cloud-dependencies` to
> version `2021.0.9` (#2109)

Re: [VOTE] Release Apache Log4j 2.22.1 RC1

[Gary Gregory]

+1
- Tested src zip file
- ASC OK
- SHA512 OK
- `mvn clean verify` OK
- Using:
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.9, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.2.1", arch: "x86_64", family: "mac"
Darwin  23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10
PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64

Gary

On Fri, Dec 22, 2023 at 1:01 PM Piotr P. Karwasz
 wrote:
>
> This is a vote to release the Apache Log4j 2.22.1.
>
> Website: https://logging.staged.apache.org/log4j/2.x/
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 8469975a4f2b1f8f1bd4f25ca6d1989a52aefc1b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1254
> 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 in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> wget --recursive --no-parent --no-host-directories --cut-dirs=5
> https://dist.apache.org/repos/dist/dev/logging/log4j
>
> # Verify checksums
> sha512sum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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-1254
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
>
> == Release Notes
>
> This release contains only dependency upgrades and bug fixes, which do
> not change the behavior of the artifacts.
>
> While maintaining compatibility with Java 8, the artifacts in this
> release where generated using JDK 17, unlike version `2.22.0` that
> used JDK 11.
>
>
> [#release-notes-2-22-1-fixed]
> === Fixed
>
> * Mark `JdkMapAdapterStringMap` as frozen if map is immutable. (#2098)
> * Fix NPE in `CloseableThreadContext`. (#1426)
> * Use the module name of Conversant Media Disruptor from version
> `1.2.16+` of the library.
> * Fix NPE in `RollingFileManager`. (#1645)
> * Fix `log4j-to-slf4j` JPMS and OSGi descriptors. (#1983)
> * Workaround a Coursier/Ivy dependency resolution bug affecting
> `log4j-slf4j-impl` and `log4j-mongodb3`. (#2065)
>
> [#release-notes-2-22-1-updated]
> === Updated
>
> * Bumped the minimum Java version required for the build to Java 17.
> Runtime requirements remain unchanged. (#2021)
> * Update `com.github.luben:zstd-jni` to version `1.5.5-11` (#2030)
> * Update `com.google.guava:guava` to version `33.0.0-jre` (#2110)
> * Update `commons-codec:commons-codec` to version `1.16.0` (#2042)
> * Update `commons-io:commons-io` to version `2.15.1` (#2034)
> * Update `commons-logging:commons-logging` to version `1.3.0` (#2050)
> * Update `io.netty:netty-bom` to version `4.1.104.Final` (#2095)
> * Update `org.apache.commons:commons-compress` to version `1.25.0` (#2045)
> * Update `org.apache.commons:commons-dbcp2` to version `2.11.0` (#2048)
> * Update `org.apache.commons:commons-lang3` to version `3.14.0` (#2047)
> * Update `org.apache.commons:commons-pool2` to version `2.12.0` (#2057)
> * Update `org.apache.kafka:kafka-clients` to version `3.6.1` (#2068)
> * Update `org.apache.logging:logging-parent` to version `10.5.0` (#2119)
> * Update `org.jctools:jctools-core` to version `4.0.2` (#1984)
> * Update `org.springframework.boot:spring-boot` to version `2.7.18` (#1998)
> * Update `org.springframework.cloud:spring-cloud-dependencies` to
> version `2021.0.9` (#2109)

Re: [VOTE] Release Apache Log4j 2.22.1 RC1

[Gary Gregory]

Can this noise be made quiet in the future please (mvn clean verify -U):

...
[INFO] --- bsh:1.4:run (process-sbom) @ log4j-api-java9 ---
[INFO] Executing Script
[INFO] file class java.lang.Object
[INFO] script class java.lang.String
[INFO] evaluating script import java.io.*;
import java.nio.file.*;
import java.util.*;
import javax.xml.transform.*;
import javax.xml.transform.stream.*;
import org.apache.commons.codec.digest.*;

// Compute parameters
final String xslt = project.getProperties().getProperty("sbom.xslt");
final File pomFile = project.getModel().getPomFile();
final byte[] digest = new
DigestUtils(MessageDigestAlgorithms.SHA_256).digest(pomFile);
final UUID bomSerialNumber = UUID.nameUUIDFromBytes(digest);
final String vdrUrl =
Objects.requireNonNull(project.getProperties().getProperty("vdr.url"),
"vdr.url");

// Move original SBOM file
final Path basedir = project.getBasedir().toPath();
final Path destPath = basedir.resolve("target/bom.xml");
final Path sourcePath = basedir.resolve("target/bom.orig.xml");
if (!Files.isReadable(destPath)) {
  System.out.println("No CycloneDX SBOM file found, skipping
transformation.");
  return;
}
Files.move(destPath, sourcePath, new CopyOption[]
{StandardCopyOption.REPLACE_EXISTING});

// Apply XSLT transformation
final StreamSource xsltSource = new StreamSource(new StringReader(xslt));
final TransformerFactory factory = TransformerFactory.newInstance();
final Transformer transformer = factory.newTransformer(xsltSource);
transformer.setParameter("sbom.serialNumber", bomSerialNumber.toString());
transformer.setParameter("vdr.url", vdrUrl);
final StreamSource source = new
StreamSource(sourcePath.toUri().toASCIIString());
final StreamResult result = new
StreamResult(destPath.toUri().toASCIIString());
transformer.transform(source, result);
No CycloneDX SBOM file found, skipping transformation.
[INFO]
[INFO] >>> spotbugs:4.8.2.0:check (default-spotbugs) > :spotbugs @
log4j-api-java9 >>>


Gary

On Fri, Dec 22, 2023 at 1:01 PM Piotr P. Karwasz
 wrote:
>
> This is a vote to release the Apache Log4j 2.22.1.
>
> Website: https://logging.staged.apache.org/log4j/2.x/
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 8469975a4f2b1f8f1bd4f25ca6d1989a52aefc1b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1254
> 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 in the Subversion repository can be summarized as follows:
>
> # Check out the distribution
> wget --recursive --no-parent --no-host-directories --cut-dirs=5
> https://dist.apache.org/repos/dist/dev/logging/log4j
>
> # Verify checksums
> sha512sum --check *.sha512
>
> # Verify signatures
> wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> 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-1254
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
>
> == Release Notes
>
> This release contains only dependency upgrades and bug fixes, which do
> not change the behavior of the artifacts.
>
> While maintaining compatibility with Java 8, the artifacts in this
> release where generated using JDK 17, unlike version `2.22.0` that
> used JDK 11.
>
>
> [#release-notes-2-22-1-fixed]
> === Fixed
>
> * Mark `JdkMapAdapterStringMap` as frozen if map is immutable. (#2098)
> * Fix NPE in `CloseableThreadContext`. (#1426)
> * Use the module name of Conversant Media Disruptor from version
> `1.2.16+` of the library.
> * Fix NPE in `RollingFileManager`. (#1645)
> * Fix `log4j-to-slf4j` JPMS and OSGi descriptors. (#1983)
> * Workaround a Coursier/Ivy dependency resolution bug affecting
> `log4j-slf4j-impl` and `log4j-mongodb3`. (#2065)
>
> [#release-notes-2-22-1-updated]
> === Updated
>
> * Bumped the minimum Java version required for the build to Java 17.
> Runtime requirements remain unchanged. (#2021)
> * Update `com.github.luben:zstd-jni` to version `1.5.5-11` (#2030)
> * Update `com.google.guava:guava` to version `33.0.0-jre` (#2110)
> * Update `commons-codec:commons-codec` to version `1.16.0` (#2042)
> * Update `commons-io:commons-io` to version `2.15.1` (#2034)
> * Update `commons-logging:commons-logging` 

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

[Gary Gregory]

In these universes (projects): Over the years, many RCs in many projects
have created zip and tars with missing files because assembly descriptors
for the Maven assembly plugin where not updated correctly or created
properly in the first place. The src zip and tar is NOT (usually) a dump of
EVERYTHING is a svn/git repository. A project might contain many extra
files that are not required to build. For example, IIRC I saw an RC once
that included the .git hidden folder.

Gary

On Wed, Dec 20, 2023, 6:56 AM Jochen Wiedmann 
wrote:

> On Tue, Dec 19, 2023 at 2:05 PM Gary Gregory 
> wrote:
>
> > Do note that building from sources, not git, is an Apache requirement.
>
> Okay, but in what universe is building from a Git tag on the sources
> (which is, what the release:perform goal does) different from
> "building from sources"?
>
> Jochen
>

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

[Gary Gregory]

Hi all,

Do note that building from sources, not git, is an Apache requirement. IIRC
reproducibility is a nice-to-have for Apache, but are we making this a
Logging or Log4J requirement? So a review should not be based on a git tag
IMO, it should be based on downloading the src zip or tar and building from
that, which is what a Linux distribution that builds everything from first
principles would do.

Gary

On Tue, Dec 19, 2023, 3:31 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Thu, 14 Dec 2023 at 21:39, Gary Gregory  wrote:
> > If you write "Please don't release this.", then you should vote -1. Or
> am I
> > missing something?
>
> You are right. I am voting -1, because of the `*-test-sources.jar`
> artifacts in the Maven repository.
>
> Reproducibility is not an issue, we just need to use the Git tag
> instead of the source archive.
>
> Piotr
>

Re: [log4j] Revamping Log4j website & manual structure

[Gary Gregory]

Hi all,

Thank you V for putting this together.

>From a high level, I don't like that the proposal is split into a website
and a manual. The material should be the same and obviously optionally
differently as a site vs a manual. For example, why is the tutorial
excluded from the manual? Anyway, this might all be quicker to discuss in a
meeting.

Maybe the proposal refers to the current state of things?

The text refers to 3 major versions being widely used, obviously only 2 are
in play ATM.

Gary

On Tue, Dec 19, 2023, 5:03 AM Volkan Yazıcı  wrote:

> *TLDR:* Log4j website & manual structure (i.e., sectioning) will be
> changed. Please reply for feedback and/or support.
>
> As a part of the planned Log4j website & manual revamp
> , I ask
> for your feedback on the structure Christian, Piotr, and I had worked out
> earlier:
>
> https://docs.google.com/document/d/10Fu7oqDzdM_D6LbexzwX9arh51Tic7AGvkWTQrL6jjQ
> PMC
> members have editor rights to the document, the rest can only view.
> Ideally, first the discussion should take place here rather than directly
> updating the document.
>
> Please take into account that this discussion is only about the structural
> organization. It is **not** about tooling (Markdown, AsciiDoc, Antora,
> Maven, etc.), which repository/repositories to store the sources, or URLs.
>

Re: [log4j] Revamping Log4j website & manual

[Gary Gregory]

When I read "pages", "site", and do on, I am reminded of the model-view
paradigm. I would offer that we focus on _content_ first, and write that
content in some general format that tooling can then be used to generate a
site, a PDF, Javadoc, whatever.

FWIW, when I worked on the "Java Persistence with Hibernate" book, we wrote
everything in XHTML and used tooling called lemma to produce a PDF. This
was all in a Maven project, which contained all of the book's Java code,
which was compiled and tested like a plain old Java app. The Java source
code contains special comments that allowed the tooling to "code slurp" the
Java source and combine it with the XHTML to produce the book output.

All very cool since the Java examples for the book were as "real" as
possible, guaranteed to work, otherwise building the book would fail!.

2c,
Gary

On Mon, Dec 18, 2023, 2:15 PM Volkan Yazıcı  wrote:

> *TLDR:* Log4j websites & manual will be rewritten. Feedback and support are
> more than welcome.
>
> Starting from February, Christian, Piotr, and I will be working on
> reorganizing the Log4j websites (Log4j, Log4j Scala, Log4j Tools, etc.) and
> rewriting the Log4j manual. Many implementation details are still yet to be
> decided and we look forward to pursuing this big undertaking with the help
> of other PMC members and our community.
>
> I want to kick-off this project using the following agenda:
>
>1. An email thread on *website & manual reorganization* – What are the
>current shortcomings? Shall we have global support, security, etc.
> pages?
>Do we need separate pages for distribution details of each project?
> Where
>shall we place `logging-parent`? What about release instructions?
>2. An email thread on *tooling* – What are the requirements? What are
>the available solutions in the market?
>3. A *video call* for resolution – Q Fleshing out a plan forward.
>4. An email sharing the *conclusive plan* in detail.
>
> If you have general feedback that doesn't fit into aforementioned
> reorganization- and tooling-related discussions, please go ahead and share
> them in response to this post.
>

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

[Gary Gregory]

Since Piotr asked for a fix and Matt can reproduce the issue, I'm not going
to take the time.to review this RC.

Gary

On Mon, Dec 18, 2023, 3:21 AM Volkan Yazıcı  wrote:

> Even though the vote was intended for 72 hours, it has been 5 days and
> there hasn't been any official votes on the release. I will wait for
> another 24 hours and cancel the release. I will appreciate PMC members'
> participation in the voting.
>
> On Wed, Dec 13, 2023 at 4:26 PM Volkan Yazıcı  wrote:
>
> > This is a vote to release the Apache Log4j 3.0.0-beta1.
> >
> > Website: https://logging.staged.apache.org/log4j
> > GitHub: https://github.com/apache/logging-log4j2
> > Commit: c5dbdcfeb0216e1e3e333436e9b4d04cc3b8e6fd
> > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> > Nexus:
> > https://repository.apache.org/content/repositories/orgapachelogging-1246
> > 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 in the Subversion repository can be summarized as follows:
> >
> > # Check out the distribution
> > svn co https://dist.apache.org/repos/... && cd $_
> >
> > # Verify checksums
> > shasum --check *.sha512
> >
> > # Verify signatures
> > wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> > 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/...
> > sh mvnw -Prelease \
> > verify artifact:compare \
> > -Dreference.repo=$NEXUS_REPO \
> > -Dcyclonedx.skip
> >
> > Some SBOM discrepancy is causing reproducibility mismatch, hence the
> > `-Dcyclonedx.skip`. Since `2.x` and `main` are greatly diverged, I
> couldn't
> > figure out the missing piece yet.
> >
> > == Release Notes
> >
> > This is the first beta release of the upcoming major release, i.e.,
> > `3.0.0`.
> >
> > === Added
> >
> > * Add annotations for nullability. (LOG4J2-1477)
> > * Remove deprecated code. (LOG4J2-2493)
> > * Add a more generalized dependency injection system to plugins inspired
> > by JSR 330. (LOG4J2-2803)
> > * Add and enhance structured properties for per-context settings outside
> > configuration files. (1473)
> > * Automate artifact publishing and release preparation. (LOG4J2-3466)
> > * Add support for dependency injection of plugins into container types
> > such as `Optional`, `Collection`, `Set`, `Stream`, `List`,
> > and `Map`. (LOG4J2-3496)
> > * Add support for `ConstraintValidator` in plugin classes. (LOG4J2-3497)
> >
> > === Changed
> >
> > * Remove liquibase-log4j2 maven module (#1193)
> > * Make the output of annotation processing reproducible. (#1520)
> > * Replace `synchronized` blocks with locks for improved performance with
> > virtual threads. (#1532)
> > * Removes additional `isFiltered` checks in `AsyncLoggerConfig`. (#1550)
> > * Ignore exceptions thrown by PropertySources. Eliminate
> > ClassCastException when SimpleLoggerContext is used.
> > (spring-projects/spring-boot#33450, #1799)
> > * Update `com.lmax:disruptor` to version `4.0.0` (#1829)
> > * Migrate most tests to JUnit 5. This includes a more powerful set of
> test
> > extensions. (LOG4J2-2653)
> > * Make Log4j use its own BOM. (LOG4J2-3511)
> > * Change encoding of HTTP Basic Authentication to UTF-8. (#1970)
> > * Upgraded the required compiler version to Java 17
> > * Upgraded the required runtime version to Java 17
> > * Update `actions/checkout` to version `4.1.1` (#1869)
> > * Update `actions/setup-java` to version `3.13.0` (#1809)
> > * Update `actions/setup-python` to version `4.7.1` (#1831)
> > * Update `ch.qos.logback:logback-classic` to version `1.4.14` (#2028)
> > * Update `com.datastax.cassandra:cassandra-driver-core` to version
> > `3.11.5` (#1889)
> > * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.0` (#1974)
> > * Update `com.github.luben:zstd-jni` to version `1.5.5-11` (#2032)
> > * Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.7.3.6`
> > (#1879)
> > * Update `com.github.tomakehurst:wiremock-jre8` to version `2.35.1`
> (#1765)
> > * Update `com.google.errorprone:error_prone_core` to version `2.23.0`
> > (#1871)
> > * Update `com.google.guava:guava-testlib` to version `32.1.3-jre` (#1934)
> > * Update `com.h2database:h2` to version `2.2.224` (#1917)
> > * Update `commons-codec:commons-codec` to version `1.16.0` (#2054)
> > * Update `commons-io:commons-io` to version `2.15.1` 

Re: [VOTE] Release Apache Log4j Tools 0.7.0

[Gary Gregory]

+1

Tested src zip
ASC OK, SHA512 OK, build 'mvn clean verify' OK.

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.9, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.2", arch: "x86_64", family: "mac"

Darwin  23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10
PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64

Gary

On Thu, Dec 14, 2023 at 4:05 PM Piotr P. Karwasz
 wrote:
>
> On Thu, 14 Dec 2023 at 13:40, Volkan Yazıcı  wrote:
> >
> > This is a vote to release the Apache Log4j Tools 0.7.0.
> >
> > Website: https://logging.staged.apache.org/log4j/tools
> > GitHub: https://github.com/apache/logging-log4j-tools
> > Commit: 04d9a79fb5cadb791c9e66fc671d6c0ffedf7e1e
> > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
> > Nexus:
> > https://repository.apache.org/content/repositories/orgapachelogging-1247
> > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
> >
> > Please download, test, and cast your votes on this mailing list.
> >
> > [ ] +1, release the artifacts
> > [ ] -1, don't release, because...
>
> As usual I checked:
>
>  * that tests are not failing,
>  * that artifacts are reproducible from the source archive,
>  * that the artifacts in the binary archive are identical to those in
> the Maven repo.
>
> Version 0.7.0 successfully understands the new "updated" change type: +1
>
> Piotr

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

[Gary Gregory]

Hi Piotr,

If you write "Please don't release this.", then you should vote -1. Or am I
missing something?

Gary

On Thu, Dec 14, 2023, 3:33 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Wed, 13 Dec 2023 at 16:26, Volkan Yazıcı  wrote:
> >
> > This is a vote to release the Apache Log4j 3.0.0-beta1.
> >
> > Website: https://logging.staged.apache.org/log4j
> > GitHub: https://github.com/apache/logging-log4j2
> > Commit: c5dbdcfeb0216e1e3e333436e9b4d04cc3b8e6fd
> > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> > Nexus:
> > https://repository.apache.org/content/repositories/orgapachelogging-1246
> > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
> >
> > Please download, test, and cast your votes on this mailing list.
> >
> > [ ] +1, release the artifacts
> > [ ] -1, don't release, because...
>
> Thanks for preparing the release, unfortunately:
>
>  * The Maven Source Plugin is misconfigured and it publishes **test**
> source artifacts. I fixed in in commit
> a8dcc55fc37e3a332101dcf0d5833273708b583b, you can cherry-pick it onto
> the release branch,
>  * Since test sources are generated we have reproducibility problems:
> the source artifact does not preserve the chmod of each file and some
> files have an executable flag...
>
> Please don't release this.
>
> Piotr
>

Re: Versioning scheme

[Gary Gregory]

IMO:

A new protected or public anything needs a minor version bump. I think that
follows sem ver.

Gary

On Mon, Dec 11, 2023, 1:56 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Mon, 11 Dec 2023 at 10:26, Volkan Yazıcı  wrote:
> > *Given a version number `MAJOR.MINOR.PATCH`, increment the:*
> >
> >
> >- *MAJOR version when you make incompatible API changes*
> >   - *MINOR version when you add functionality in a backward
> compatible
> >   manner*
> >   - *PATCH version when you make backward compatible bug fixes*
> >
> > I think we all agree on what warrants a major version bump. The
> definition
> > of what constitutes an API, etc. are all open to interpretation, but we
> > have a common sense of it in the PMC.
>
> I think we can split this into a:
>
>  * minimal version dump, dictated by technical reasons (changes in the
> methods exposed to the public),
>  * and a component that can not be automatically detected, which is
> due to change of behavior. E.g. I can modify the behavior of the `%i`
> converter without touching the public API.
>
> > We mostly have a problem whether the next release needs a minor or patch
> > version bump. I propose to refine the official semantics as follows:
> >
> > Are we making a release to *only* address a set of particular issues?
> That
> > is, does the following hold?
> >
> > [next release] = [last release] + [fix1] + [fix2] + ... + [fixN]
> >
> > If so, this needs a patch version bump. Otherwise, this is a minor
> version
> > bump.
>
> What I am having a problem with is the default type of change:
>
>  * for me every release should be a **patch** release, unless there
> are reasons to publish a minor release. For example the next Log4j
> release should be 2.22.1. This is the old strategy used by Log4j;
>  * recently this strategy shifted to: every release is a **minor**
> release, unless someone justifies that it can be a patch release. All
> our repos are currently using a snapshot version that is a minor
> version bump from the previous release.
>
> In the end the result (release version number) might be the same, but
> the burden of proof falls on those advocating for a patch release.
>
> The concrete example of `logging-parent` is hard to discuss, since it
> is not written in Java, but a mix of Maven plugins, bash scripts and
> Github action workflows. Your fix of the problem we were having with
> `META-INF/services/` is pretty nice, but for me it constitutes a bug
> fix, not a new feature children project can rely upon. The value of
> the contribution does not depend on the version bump it generates,
> patch contributions require usually more effort.
>
> On the other hand if we consider that the `bnd:jar` execution
> disappeared from `logging-parent`, this might be considered a major
> version change.
>
> Piotr
>

Re: [log4j] Is `bnd` a curse or a blessing?

[Gary Gregory]

The optional bit I hope can be solved by refactoring Maven modules to have
zero optional dependencies.

Gary

On Thu, Dec 7, 2023, 10:32 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Thu, 7 Dec 2023 at 15:46, Gary Gregory  wrote:
> >
> > Note that there is also the Maven moditect plugin but I don't know if it
> > deals with OSGi which brings up the issue of how much we should care
> about
> > OSGi (I don't know).
>
> We can disable JPMS descriptor generation in BND and switch to
> Moditect. From what I have seen it has less problems than BND 6.x,
> since it uses official tools like `jdeps` to compute module names and
> module dependencies.
>
> Optional dependencies **still** require a configuration override, but
> we probably can not do anything about that.
>
> Piotr
>

Re: [log4j] Is `bnd` a curse or a blessing?

[Gary Gregory]

Note that there is also the Maven moditect plugin but I don't know if it
deals with OSGi which brings up the issue of how much we should care about
OSGi (I don't know).

Gary

On Thu, Dec 7, 2023, 9:41 AM Volkan Yazıcı  wrote:

> We use `bnd`, in particular, `bnd-maven-plugin`
> <
> https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-maven-plugin
> >
> to programmatically declare JPMS/OSGi module exports and service providers.
> Effectively, it generates `module-info.class`, `META-INF/services`, and
> (OSGi-related) `MANIFEST.MF` files. We also enhance this experience with
> `bnd-baseline-maven-plugin`
> <
> https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin
> >
> to enforce API compatibility between versions.
>
> I really like this! We use `@Export`, `@Version`, `@ServiceConsumer`,
> `@ServiceProvider`, etc. annotations in the code and `bnd` takes care of
> the rest. Though in the last couple of months, I have noticed several
> nuances that started to make me consider pros/cons of this convenience.
>
> *Good: Programmatic configuration*
>
> No need to manually populate `module-info.java`, `META-INF/services`,
> `MANIFEST.MF` files. Everything is in the code. Great!
>
> *Bad: Programmatic configuration is not enough*
>
> We still need to tweak the generated `module-info.class` in several places.
> We have hundreds of lines of manual treatment: you can simply search for
> `
> *Good: Absence of `module-info.java`*
>
> We use `bnd:jar` goal to populate `module-info.class` and attach it to the
> generated JAR. That is, there are no `module-info.java` and
> `module-info.class` files anywhere in the `target` folder. This makes life
> with IDEs a lot easier. IDEs simply work [not really, but I will talk about
> that later], since they think there are no JPMS descriptors to deal with.
>
> *Bad: IDEs cannot discover services*
>
> Since `META-INF/services` is only available in the generated JAR, IDEs are
> not able to discover services.
>
> *Bad: `bnd:jar` attaches the generated files always at the end*
>
> Currently, if the `package` phase has multiple plugin executions, `bnd:jar`
> removes the Maven Jar plugin execution and adds its own at the end (not
> sure if that is fixable). E.g.: adding `spring-boot:repackage` in a naive
> way, causes `spring-boot:repackage` to be executed before `bnd:jar` and
> effectively missing all `bnd:jar`-generated files.
>
> *Bad: Switching to `bnd:bnd-process` is not a cure either*
>
> Piotr and I have been thinking about switching from `bnd:jar` to
> `bnd:bnd-process`, since the latter will output everything generated to the
> `target` folder. Though this is not a cure without any side effects either.
> <
> https://github.com/apache/logging-parent/issues/69#issuecomment-1845373576
> >
>
> *Bad: Mismatch with the community and ecosystem*
>
> AFAIK, almost no major project uses `bnd-maven-plugin`. (This is more of a
> gut feeling, I haven't done an empirical study on this.) We are alone with
> our problems and others' solutions (catered against mainstream which
> hand-craft `module-info.java`, etc. files) don't work for us.
>
> *What now?*
>
> `bnd-maven-plugin` is a great tool with an active community. It delivers
> its promises perfectly. Though the surrounding ecosystem (IDEs,
> not-JPMS'ed-yet libraries, etc.) doesn't always play nice with it and
> eventually we end up tweaking it, *a lot*. I am sitting on the fence
> whether it is a curse or a blessing. I will appreciate your thoughts on the
> matter.
>

Re: [log4j] Upgrade `main` compiler and runtime to Java 17

[Gary Gregory]

I could see us building and running on LTS versions only (17, 21) but not
anything else feels restrictive. Building on Java 21 will also let us avoid
trouble (maybe) with running on 21. IOW, I hope-wish for that GitHub builds
run and test on 17, 21, and 22-EA as a nice-to-have.

Gary


On Tue, Dec 5, 2023, 7:49 AM Volkan Yazıcı  wrote:

> I disagree with having an open-ended compiler baseline requirement due to
>
>1. It is not a minor task to bump the compiler version. The Java 17
>upgrade task was on hold already for several months due to its
> intricacies.
>As a matter of fact, you were the one who dropped the ball after the
> Java
>11 upgrade. (It was a rightful decision and I am glad you did the hard
> work
>of Java 11 upgrade. )
>2. Fixing the baseline will keep everybody (maintainers, individual
>contributors, etc.) on the same page due to no moving parts. Less "Are
> you
>using Java 17?"-kind questions while troubleshooting.
>3. Those who want to test Log4j against new JDKs still can easily:
>`-Denforcer.skip`
>4. `.java-version` doesn't support ranges (AFAIK)
>5. I don't find it annoying. On the contrary, several other major
>projects adopt this pattern: Spring Boot
><
> https://github.com/spring-projects/spring-boot/blob/main/buildSrc/build.gradle#L13
> >,
>JUnit
><
> https://github.com/junit-team/junit5/blob/main/gradle/plugins/settings.gradle.kts#L4
> >,
>JCTools ,
>Guava , etc.
>6. I don't see a compelling use case.
>
> All that said, I am not strongly opinionated about this and I wouldn't stop
> you from replacing `[17,18)` with `[17,)` in `/pom.xml`.
>
> On Tue, Dec 5, 2023 at 1:19 PM Piotr P. Karwasz 
> wrote:
>
> > Hi Volkan,
> >
> > On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı  wrote:
> > >
> > > I have just updated `main` to require Java 17 for compiling and to
> target
> > > Java 17. Previously both were Java 11. If you have objections, please
> > > discuss in this thread.
> >
> > I am Ok with bumping the bytecode to Java 17.
> >
> > Regarding the build requirements I would give by **default** a larger
> > spectrum of possible JDKs.
> > Right now we only accept JDK 17 in the default Maven profile. A Log4j
> > contributor is forced to install JDK 17 for a build to succeed, which
> > might be annoying. Therefore it might be better to:
> >
> >  * set the Enforcer plugin to accept
> > [minimum_JDK_required_by_Maven_plugins,)
> >  * set [17,18) **only** in the `release` plugin.
> >
> > BTW: when we bump BND to 7.x, minimum_JDK_required_by_Maven_plugins will
> > be 17.
> >
> > Piotr
> >
>

Re: [log4j] Upgrade `main` compiler and runtime to Java 17

[Gary Gregory]

I'm OK with Java 17 as the runtime minimum.

Gary

On Tue, Dec 5, 2023, 7:19 AM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Tue, 5 Dec 2023 at 11:50, Volkan Yazıcı  wrote:
> >
> > I have just updated `main` to require Java 17 for compiling and to target
> > Java 17. Previously both were Java 11. If you have objections, please
> > discuss in this thread.
>
> I am Ok with bumping the bytecode to Java 17.
>
> Regarding the build requirements I would give by **default** a larger
> spectrum of possible JDKs.
> Right now we only accept JDK 17 in the default Maven profile. A Log4j
> contributor is forced to install JDK 17 for a build to succeed, which
> might be annoying. Therefore it might be better to:
>
>  * set the Enforcer plugin to accept
> [minimum_JDK_required_by_Maven_plugins,)
>  * set [17,18) **only** in the `release` plugin.
>
> BTW: when we bump BND to 7.x, minimum_JDK_required_by_Maven_plugins will
> be 17.
>
> Piotr
>

Re: Logstash and Filebeat guaranteed delivery

[Gary Gregory]

Of course RE Volkan, my first sentence must have been poorly written. I
meant to say that I know who Volkan is and that he is great, but, that's
not the point. I was trying to say that a peronal GitHub account, in
general, can't be compared to an official Apache account.

Gary

On Fri, Dec 1, 2023, 12:25 PM Matt Sicker  wrote:

> I may be biased, but I wouldn’t consider Volkan a random GitHub user!
> However, that does raise an interesting point: we could link to third party
> plugins and such to help curate it.
>
> > On Dec 1, 2023, at 5:00 AM, Gary Gregory  wrote:
> >
> > Hi all,
> >
> > (Don't take his the wrong way Volkan ;-)
> > Assuming that I don't know who you are, why would I pick a random github
> > user's custom appender instead of an official Log4j appender? If your
> > appender is "battle-tested", why not move it to Log4j (or Redis?)
> >
> > Gary
> >
> >
> > On Fri, Dec 1, 2023, 4:08 AM Volkan Yazıcı  wrote:
> >
> >> I appreciate your thoughts on this subject. We can eventually convert
> this
> >> into a chapter in the Log4j manual. My goal is to be able to make a
> >> statement as follows:
> >>
> >> *When Log4j is configured with Y, Y, Z settings, it can provide
> guaranteed
> >> delivery against certain types of log sinks such as A, B, C.*
> >>
> >> *A – You need to make sure A has ... feature enabled. Further, it has
> ...
> >> caveat.*
> >> *B – You need to make sure B has ... feature enabled and ...*
> >> *C – ...*
> >>
> >>
> >> That is, a cookbook for users with recipes for guaranteed delivery.
> >>
> >> [I respond to your message below inline.]
> >>
> >> On Thu, Nov 30, 2023 at 9:34 PM Ralph Goers  >
> >> wrote:
> >>
> >>> Notice that neither of the links you have provided use the term
> >>> “guaranteed delivery”. That is because that is not really what they are
> >>> providing. In addition, notice that Logstash says "Input plugins that
> do
> >>> not use a request-response protocol cannot be protected from data
> loss”,
> >>
> >>
> >> But see the rest of that statement
> >> <
> >>
> https://www.elastic.co/guide/en/logstash/current/persistent-queues.html#persistent-queues-limitations
> >>>
> >> : *"Plugins such as beats and http, which do have an acknowledgement
> >> capability, are well protected by this [Logstash persistent] queue."*
> >>
> >>
> >>> and "Data may be lost if an abnormal shutdown occurs before the
> >> checkpoint
> >>> file has been committed”.
> >>
> >>
> >> See the following statement further down in that page: *"To avoid losing
> >> data in the persistent queue, you can set `queue.checkpoint.writes: 1`
> to
> >> force a checkpoint after each event is written."*
> >>
> >> These two make me conclude that, if configured correctly (e.g., using
> >> `http` plugin in combination with `queue.checkpoint.writes: 1`),
> Logstash
> >> can deliver guaranteed delivery. Am I mistaken?
> >>
> >>
> >>> As for using Google Cloud that would default the whole point. If your
> >> data
> >>> center has lost contact with the outside world it won’t be able to get
> to
> >>> Google Cloud.
> >>>
> >>
> >> But that cannot be an argument against using Google Cloud as a log sink
> >> with guaranteed delivery. An in-house Flume server can go down too. Let
> me
> >> know if I miss your point here.
> >>
> >>
> >>> While Redis would work it would require a) an application component
> that
> >>> interacts with Redis such as a Redis Appender (which we don’t have) b)
> a
> >>> Redis deployment c) a Logstash (or some other Redis consumer) to
> forward
> >>> the event. It is a lot simpler to configure Flume than to do all of
> that.
> >>>
> >>
> >> For one, there is a battle-tested Log4j Redis Appender
> >> <https://github.com/vy/log4j2-redis-appender>, which enabled us to
> remove
> >> `log4j-redis` in `main`.
> >>
> >> Indeed, Flume can deliver what Redis+Logstash do. Though my point is,
> not
> >> that Redis has a magical feature set, but there *are* several log sink
> >> stacks one can build using modern stock components and provide
> guaranteed
> >> delivery. I would like to document some of those, if n

Re: Logstash and Filebeat guaranteed delivery

[Gary Gregory]

Hi all,

(Don't take his the wrong way Volkan ;-)
Assuming that I don't know who you are, why would I pick a random github
user's custom appender instead of an official Log4j appender? If your
appender is "battle-tested", why not move it to Log4j (or Redis?)

Gary


On Fri, Dec 1, 2023, 4:08 AM Volkan Yazıcı  wrote:

> I appreciate your thoughts on this subject. We can eventually convert this
> into a chapter in the Log4j manual. My goal is to be able to make a
> statement as follows:
>
> *When Log4j is configured with Y, Y, Z settings, it can provide guaranteed
> delivery against certain types of log sinks such as A, B, C.*
>
> *A – You need to make sure A has ... feature enabled. Further, it has ...
> caveat.*
> *B – You need to make sure B has ... feature enabled and ...*
> *C – ...*
>
>
> That is, a cookbook for users with recipes for guaranteed delivery.
>
> [I respond to your message below inline.]
>
> On Thu, Nov 30, 2023 at 9:34 PM Ralph Goers 
> wrote:
>
> > Notice that neither of the links you have provided use the term
> > “guaranteed delivery”. That is because that is not really what they are
> > providing. In addition, notice that Logstash says "Input plugins that do
> > not use a request-response protocol cannot be protected from data loss”,
>
>
> But see the rest of that statement
> <
> https://www.elastic.co/guide/en/logstash/current/persistent-queues.html#persistent-queues-limitations
> >
> : *"Plugins such as beats and http, which do have an acknowledgement
> capability, are well protected by this [Logstash persistent] queue."*
>
>
> > and "Data may be lost if an abnormal shutdown occurs before the
> checkpoint
> > file has been committed”.
>
>
> See the following statement further down in that page: *"To avoid losing
> data in the persistent queue, you can set `queue.checkpoint.writes: 1` to
> force a checkpoint after each event is written."*
>
> These two make me conclude that, if configured correctly (e.g., using
> `http` plugin in combination with `queue.checkpoint.writes: 1`), Logstash
> can deliver guaranteed delivery. Am I mistaken?
>
>
> > As for using Google Cloud that would default the whole point. If your
> data
> > center has lost contact with the outside world it won’t be able to get to
> > Google Cloud.
> >
>
> But that cannot be an argument against using Google Cloud as a log sink
> with guaranteed delivery. An in-house Flume server can go down too. Let me
> know if I miss your point here.
>
>
> > While Redis would work it would require a) an application component that
> > interacts with Redis such as a Redis Appender (which we don’t have) b) a
> > Redis deployment c) a Logstash (or some other Redis consumer) to forward
> > the event. It is a lot simpler to configure Flume than to do all of that.
> >
>
> For one, there is a battle-tested Log4j Redis Appender
> , which enabled us to remove
> `log4j-redis` in `main`.
>
> Indeed, Flume can deliver what Redis+Logstash do. Though my point is, not
> that Redis has a magical feature set, but there *are* several log sink
> stacks one can build using modern stock components and provide guaranteed
> delivery. I would like to document some of those, if not best-practices,
> known-to-work solutions. This way we can enable our users to make a
> well-informed decision and pick the best approach that fits into their
> existing stack.
>
> On Thu, Nov 30, 2023 at 9:34 PM Ralph Goers 
> wrote:
>
> > Volkan,
> >
> > Notice that neither of the links you have provided use the term
> > “guaranteed delivery”. That is because that is not really what they are
> > providing. In addition, notice that Logstash says "Input plugins that do
> > not use a request-response protocol cannot be protected from data loss”,
> > and "Data may be lost if an abnormal shutdown occurs before the
> checkpoint
> > file has been committed”. Note that Flume’s FileChannel does not face the
> > second issue while the first would also be a problem if it is using a
> > source that doesn’t support acknowledgements.However, Log4j’s
> FlumeAppender
> > always gets acks.
> >
> > To make this clearer let me review the architecture for my implementation
> > again.
> >
> > First the phone system maintains a list of ip addresses that can handle
> > Radius accounting records. We host 2 Flume servers in the same data
> center
> > as the phone system and configure the phone system with their ip
> addresses.
> > The Radius records will be sent to those Flume servers which will accept
> > them with our custom Radius Source. That converts them to JSON and passes
> > the JSON to the File Channel. Once the File Channel has written them to
> > disk the source responds back to the phone system with an ACK that the
> > record was received. It the record is not processed quickly enough (I
> > believe it is 100ms) then the phone system will try a different ip
> address
> > assuming it couldn’t be delivered by the first server.  Another thread
> > 

Re: [log4j] Upgrade `2.x` compiler baseline to Java 17

[Gary Gregory]

Nice! That means that 2.23.0 will require Java 17 at runtime right?

Gary


On Thu, Nov 30, 2023, 11:05 AM Volkan Yazıcı  wrote:

> Heads up! #2021  bumps
> the `2.x` baseline to Java 17. Everything works locally. If CI agrees too,
> I will merge it tomorrow and start porting to `main`.
>

Re: [Flume] Integration with OpenTelemetry

[Gary Gregory]

A key feature for me is guaranteed delivery, which is why is sometimes I
use JMS with Log4j.

Gary

On Wed, Nov 29, 2023, 11:54 PM Ralph Goers 
wrote:

> This is a great post Matt!
>
> Fluentbit, Fluentd, Logstash, and Filebeat are the main tools used for log
> forwarding. While they all have some amount of plugability none of the are
> as flexible as Flume. In addition, as I have mentioned before, none of them
> provide guaranteed delivery so I would never recommend them for forwarding
> audit logs.
>
> I have also previously explained my use case for using Flume, which is for
> forwarding Call Detail Records that start off as records in the Radius
> protocol [1] across data centers, which also requires guaranteed delivery.
> I wouldn’t be able to use any of those other tools to do that without
> significant modification.
>
> I am all for supporting standards. If you can outline what you are
> proposing on a Confluence page I would wholeheartedly support it.
>
> As you probably know, I started work on separating out things that I don’t
> consider to be “core” to Flume into separate repos. That work is only half
> completed. I would suggest that you consider whether what you are proposing
> also be in its own repo. As it is, the CI for Flume fails because the
> generated logs are exceeding the available disk space. In addition, the
> build takes a long time.
>
> Also, I have never really been a big fan of the configuration mechanism
> Flume uses. I was able to somewhat bypass it by implementing support for
> Spring Boot, but it would be great if the Log4j Plugin system could somehow
> be used to simplify configuring Flume for those who don’t want to use
> Spring boot. I know that is right up your alley.
>
> Ralph
>
>
> 1. https://networkradius.com/doc/current/introduction/RADIUS.html
>
> > On Nov 29, 2023, at 5:32 PM, Matt Sicker  wrote:
> >
> > One of the main reasons why I supported Flume joining this PMC was that
> I noticed it has significant overlap with projects in the observability
> space despite not being advertised as such. For example, the project
> FluentBit is extremely similar to Flume, but its main purpose is for
> collecting, processing, forwarding, etc., logs, metrics, and traces (i.e.,
> observability data). FluentBit is not the only thing in this space, though
> it seems to be fairly popular. These sorts of tools are used for ultimately
> publishing observability data to one or more observability tools like
> Prometheus, Splunk, Jaeger, Grafana, etc., and with a unified collector and
> processor, it becomes possible to publish all your observability data into
> one tool rather than three or more disparate tools (and the added
> operational costs of storing tons of duplicated log data from three or more
> methods of generating log data).
> >
> > A project at the CNCF, OpenTelemetry, has become the sort of de facto
> standard for interoperability in this space. In particular, they’ve
> published the OTLP specification <
> https://opentelemetry.io/docs/specs/otlp/> for general telemetry data
> delivery and the OpenTelemetry specification <
> https://opentelemetry.io/docs/specs/otel/> for various common APIs. While
> I’m still researching in this space, I think it would be useful for Flume
> to integrate with some of these APIs and SDKs (while other parts might be
> more relevant in our logging libraries instead). There is also the Open
> Agent Management Protocol 
> which is still in beta status that might also be relevant here (and
> potentially relevant in the logging libraries).
> >
> > Supporting common standards for our projects seems like a useful thing
> to do, and despite the popularity of some existing solutions there, I
> believe there is plenty of space for us to contribute. I also think that
> this can provide opportunity for the various components in this PMC to
> interoperate as these specs are fairly language neutral with some sample
> versions in many different languages.
>
>
>

Re: Optional dependencies and JPMS

[Gary Gregory]

I can tell you that some people I work with would use property files for
everything under the sun if they could...

Gary

On Wed, Nov 29, 2023, 9:29 AM Ralph Goers 
wrote:

> I agree with this. IMO the only configuration syntaxes we should support
> are those we can implement with no dependencies. At the moment that is JSON
> and Properties (Ugh!). I would love to deprecate properties but I know that
> is a non-starter since we didn’t support them for years and were constantly
> asked for it.
>
> Ralph
>
> > On Nov 29, 2023, at 5:14 AM, Gary Gregory 
> wrote:
> >
> > I think the overall goal should be to have no optional dependencies, no
> > surprises. I personally hope to never force YAML on anyone.
> >
> > Gary
> >
> > On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz 
> > wrote:
> >
> >> Hi all,
> >>
> >> I have been using a modularized sandbox project to test Log4j and
> >> optional dependencies are a nightmare.
> >>
> >> Small example: if I use Log4j API in my project and I add:
> >>
> >> requires org.apache.logging.log4j;
> >>
> >> then when I run the app, the JVM will automatically add `log4j-api` to
> >> the boot layer.
> >>
> >> It will also add `log4j-core`, since it provides a service that
> >> `log4j-api` uses.
> >>
> >> However it will **not** load `jackson-datatype-yaml`, because it is an
> >> **optional** dependency of `log4j-core` and provides no services
> >> `log4j-core` is interested in. The user must go to the additional pain
> >> of specifying `--add-modules` or the application developer must add a
> >> bogus `requires` statement.
> >>
> >> Therefore I would propose to:
> >>
> >> * move the YAML configuration factory to a separate module and delete
> >> one of the JSON configuration factories (the one that uses Jackson).
> >>
> >> What do you think?
> >>
>
>

Re: Optional dependencies and JPMS

[Gary Gregory]

I think the overall goal should be to have no optional dependencies, no
surprises. I personally hope to never force YAML on anyone.

Gary

On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> I have been using a modularized sandbox project to test Log4j and
> optional dependencies are a nightmare.
>
> Small example: if I use Log4j API in my project and I add:
>
> requires org.apache.logging.log4j;
>
> then when I run the app, the JVM will automatically add `log4j-api` to
> the boot layer.
>
> It will also add `log4j-core`, since it provides a service that
> `log4j-api` uses.
>
> However it will **not** load `jackson-datatype-yaml`, because it is an
> **optional** dependency of `log4j-core` and provides no services
> `log4j-core` is interested in. The user must go to the additional pain
> of specifying `--add-modules` or the application developer must add a
> bogus `requires` statement.
>
> Therefore I would propose to:
>
>  * move the YAML configuration factory to a separate module and delete
> one of the JSON configuration factories (the one that uses Jackson).
>
> What do you think?
>

Re: [log4j] Releasing Log4j `3.0.0`

[Gary Gregory]

I'm OK with either direction for merges for anything between 2.x and 3.x
branches for now and certainly until 3.x makes it out as a release. I won't
argue for or against either.

As a semi aside, in Commons, I circumvented the whole JPMS garbage, its
split module horror show for tests by letting the Moditect Maven plug in
generate module info files at build time.

Maybe that could be an interesting investigation for Log4j, not that I want
to take the time to do it ATM.

Gary


On Tue, Nov 28, 2023, 5:20 AM Volkan Yazıcı  wrote:

> I plan to work on `main` until February, finalize recycler implementation,
> carry out whatever improvement I can, and release `3.0.0`.
>
> *If you have any objections with this plan, or if you have things to do on
> `main` and you cannot comply with this schedule, etc., let's discuss.* I
> want to agree on a plan and timeline that works for you.
>
> *Personal remark:* I am against releasing `3.0.0` from `main`. `2.x`
> changes that didn't go into `main` are titanic. `main` also contains
> several incomplete code, doc, or both. I support the idea of forking `3.x`
> from `2.x`, backporting crucial features from `main` to `3.x`, and then
> releasing `3.0.0`. I had several email, Slack, and video conversations with
> Ralph, Matt, and Piotr. They don't agree with me. Ralph even threatened to
> veto all non-bugfix changes on `2.x`
> . I am
> outnumbered and I accept the defeat. Let's release `3.0.0` from `main` and
> move on. I don't want to spend time discussing this subject further.
>

Re: [log4j] Unstable tests on Windows

[Gary Gregory]

I think JUnit can group tests in categories with annotations (AFK).

Gary

On Tue, Nov 28, 2023, 12:01 AM Ralph Goers 
wrote:

> I would be -1 if the issues are going to be ignored or not tracked in any
> way. I don’t know if GitHub has something like a Jira Epic or if they can
> be tagged in some way so that they can be easily located but something like
> that would be fine. Even tracking them in Confluence would be fine.
>
> It would also be great if only the failing tests could be run under a
> profile making it easy to fix them.
>
> Hopefully you get what I mean. I am not looking for something complicated,
> just a way to make it easy to find them when someone has the urge to fix
> them.
>
> Ralph
>
> > On Nov 27, 2023, at 3:28 AM, Volkan Yazıcı  wrote:
> >
> > Ralph did not agree, but did not strongly object either. Ralph, are you
> -1
> > on disabling tests only Windows that are failing frequently on Windows
> and
> > capturing them in tickets to be addressed?
> >
> > On Thu, Nov 23, 2023 at 12:23 AM Christian Grobmeier <
> grobme...@apache.org>
> > wrote:
> >
> >> Ralph said, nobody would ever fix these tests if you do it like this. I
> >> think you should create the ticket but keep the tests until we find the
> >> issue. Otherwise there issues will rot
> >>
> >> On Wed, Nov 22, 2023, at 09:13, Volkan Yazıcı wrote:
> >>> AFAIC, nobody[1] shows a strong opposition against the idea of
> disabling
> >>> frequently failing Windows tests only on Windows and creating a ticket
> >> for
> >>> each one. I will proceed with that.
> >>>
> >>> [1] Except Piotr, whom I discussed the issue with in Slack and he
> agreed
> >>> with the above shared approach.
> >>>
> >>> On Mon, Nov 20, 2023 at 12:57 PM 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 Gregory]

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: [VOTE] Release Apache Log4j 2.22.0

[Gary Gregory]

I tried on macOS and I got a good build on the first try.

Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /usr/local/Cellar/maven/3.9.5/libexec
Java version: 11.0.21, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@11/11.0.21/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac"
Darwin  23.1.0 Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:27
PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64

Gary

On Fri, Nov 17, 2023 at 4:06 PM Gary D. Gregory  wrote:
>
> Hi,
>
> The only way I could get the build to pass is to let 'mvn clean verify' run 
> while I went to lunch and nothing else was running.
>
> I would not in want to vote without running all the tests.
>
> +1
>
> Gary
>
> On 2023/11/17 14:16:14 Volkan Yazıcı wrote:
> > File-based tests on Windows are not stable.
> > Occasionally they have hiccups.
> > Would you mind retrying, please?
> >
> > You can speed up the process as follows:
> >
> > # Install everything without any checks
> > ./mvnw install -DskipTests -Dspotbugs.skip -Dspotless.skip
> >
> > # Verify everything except `log4j-core-test`
> > ./mvnw verify -pl \!:log4j-core-test
> >
> > # Verify only `log4j-core-test`
> > ./mvnw verify -pl :log4j-core-test
> >
> > On Fri, Nov 17, 2023 at 3:03 PM Gary D. Gregory  wrote:
> > >
> > > 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 

Re: [log4j] `2.22.0` release

[Gary Gregory]

Go for it and thank you!

Gary


On Mon, Nov 13, 2023, 9:24 AM Volkan Yazıcı  wrote:

> I would like to do the Log4j `2.22.0` release in a couple of days;
> there are some bug fixes and SBOM is ready to be shipped. Let me know
> if you have objections.
>

Re: Deterministic formatter

[Gary Gregory]

The latest: 4.29.0

Gary


On Mon, Nov 6, 2023, 6:55 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Mon, 6 Nov 2023 at 11:45, Gary Gregory  wrote:
> >
> > Well, I use Eclipse, so... I won't be using whatever this does or when it
> > does it.
>
> What version of Eclipse do you use? The Eclipse plugin is one class, I
> can probably fix it, compile it and release it.
>
> Piotr
>

Re: Features for 3.x was: Why is JNDI still necessary?

[Gary Gregory]

It seems like a good idea to keep releasing alpha-beta-milestones (whatever
we want to call these) for pre-3.0 for now. TBH, I've not even tried it in
my work projects yet. I'd rather do that on a very recent alpha. It feels
like our alpha1 is "old".

Gary

On Mon, Nov 6, 2023, 4:37 AM Piotr P. Karwasz 
wrote:

> Hi Ralph,
>
> On Sun, 5 Nov 2023 at 05:39, Ralph Goers 
> wrote:
> > If we have changes in 2.x that are not in 3.x they aren’t many and we
> will never find that out without releasing. In general users don’t want to
> use alphas or betas. The alphas and betas are there so we can get feedback
> on issues such as these but the majority of them won’t appear until a GA
> release. To be clear, we MUST have one or two betas before a GA release
> precisely because we WILL have issues to deal with. This is completely
> normal and expected.
>
> Looking at the commit pattern, changes to 2.x are not immediately
> followed by changes to 3.x. This does not mean they are neve applied,
> but it is hard to check if they were ever applied.
>
> The easiest way to check for regressions is `git diff -w` as Matt
> says, but this only makes sense after we reformat the code using a
> deterministic formatter.
>
> > Lack integration tests? Yes 2.x lacks integration tests and always has.
> Why would we delay 3.x for something 2.x doesn’t have. All the integration
> tests will prove is that various log4j modules can coexist together because
> some of them use different dependencies. The unit tests are what matter and
> they by and large pass. That said, I did make the request to create
> integration tests because Gary has always been afraid of breaking Log4j
> into multiple repos because he believes having everything compile and build
> together provides assurance that everything will work together. If
> everything was using managed depdendencies that would be true. But they
> don’t so it isn’t.
>
> It's true, 2.x does not have integration tests or better, most unit
> tests are in fact integration tests (they test the entire stack). The
> tests are performed on the classpath, which is enough for 2.x.
>
> However, the main feature of 3.x is JPMS. We can not possibly test
> JPMS with tests that run on the classpath or in the same module as the
> code being tested. We need real integration tests that use the module
> path and test each optional dependency at a time.
>
> Remark: I am against releasing 3.x in its current state, but I am
> flexible on the amount of features required to release it. I second
> Christian's proposal for a meeting on November 12th: if the PMC agrees
> on a set of tasks required to release 3.x, I might convince my
> employer to allow me to implement them as part of my job.
>
> Piotr
>

Re: Deterministic formatter

[Gary Gregory]

Well, I use Eclipse, so... I won't be using whatever this does or when it
does it.

Gary

On Mon, Nov 6, 2023, 3:00 AM Piotr P. Karwasz 
wrote:

> Hi Matt,
>
> On Fri, 3 Nov 2023 at 19:44, Matt Sicker  wrote:
> >
> > Alright, after looking at the differences, I’m strongly in favor of the
> Palantir version. The differences in how it handles lambdas solves one of
> the main complaints I ever had about the Google version.
>
> The only disadvantage of the Palantir version is that it does not
> provide/support an Eclipse plugin:
> https://github.com/palantir/palantir-java-format/issues/833
>
> The code for Eclipse is still there, it just isn't published anywhere
> (AFAIK):
> https://github.com/palantir/palantir-java-format/tree/develop/eclipse_plugin
>
> Gary, would it be a big inconvenience using Palantir instead of the
> Google AOSP format?
>
> Piotr
>

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

[Gary Gregory]

Hi Volkan,

I only care about XML.

Gary


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

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

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

[Gary Gregory]

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

Gary

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

> Gary, have you ever heard of JNoSQL before? <http://www.jnosql.org/> It’s
> basically a JDBC-like effort to create a generic NoSQL API. Been around for
> a few years at least, and I had considered adding an appender for this back
> when I learned about it, but I think this was by the point where I stopped
> making proof of concept appenders.
> —
> Matt Sicker
>
> > On Nov 3, 2023, at 09:08, Gary Gregory  wrote:
> >
> > What I mean is this: When I want to work with a DB-like thing from Java,
> I
> > look 1st for a JDBC driver, when there is no FOSS option, I have to use a
> > DB-specifc API, for example MongoDB. Granted Cassandra is NoSQL doc store
> > but there are commercial JDBC drivers IIRC.
> >
> > All of this to say that I feel it is nice for us to support non-JDBC
> stores
> > when there are no FOSS JDBC drivers available for that datastore type.
> >
> > 2. I got it backward then, thank you for explaining it again. +1 to
> remove
> > in 3.0 but keep in 2.x.
> >
> > Gary
> >
> > On Thu, Nov 2, 2023, 11:04 AM Ralph Goers 
> > wrote:
> >
> >> Gary, a couple of comments:
> >>
> >> 1. I don’t understand what “there is no official JDBC access” has to do
> >> with Cassandra or CouchDB. Could you please elaborate?
> >> 2. The functionality in log4j-spring-boot is directly incorporated into
> >> Spring 3 due to a PR I submitted. So with Spring Boot 3
> log4j-spring-boot
> >> should NOT be included. Since Log4j 3.x (at least in my mind) goes hand
> in
> >> hand with Spring Boot 3 then removing log4j-spring-boot in 3.x makes
> sense.
> >>
> >> Ralph
> >>
> >>> On Nov 2, 2023, at 7:42 AM, Gary Gregory 
> wrote:
> >>>
> >>> My votes:
> >>>
> >>> On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >>>  wrote:
> >>>>
> >>>> This is a vote to deprecate the following `2.x` modules and features
> >>>> and remove them from the `3.x` release:
> >>>>
> >>>> * `log4j-cassandra`:
> >>> -0: Prefer keeping since there is no official JDBC access that I know
> >>> of but I have not looked for a while.
> >>>
> >>>> * CouchDB appended:
> >>> -0: Prefer keeping since there is no official JDBC access that I know
> >>> of but I have not looked for a while.
> >>>
> >>>> * `log4j-docker`
> >>> -1 Docker seems too important.
> >>>
> >>>> * GELF appended:
> >>> +0
> >>>
> >>>> * Kafka appended:
> >>> -0: Prefer keeping since there is no official JMS access that I know
> >>> of but I have not looked for a while.
> >>>
> >>>> * `log4j-kubernetes`:
> >>> -1: This should match what we do with Docker.
> >>>
> >>>> * JeroMQ appender:
> >>> -0: Prefer keeping since there is no official JMS access that I know
> >>> of but I have not looked for a while.
> >>>
> >>>> * JNDI-related features:
> >>> -1: Needed in enterprise environments, OK to split out in a separate
> >>> Maven module.
> >>>
> >>>> * `log4j-jpa`:
> >>> -0: JDBC Appender is good enough for me. Use-case seems narrow except
> >>> for a JPA shop.
> >>>
> >>>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> >>> -1: I want the ability to log to XML (narrow use-case, sure, but
> handy).
> >>>
> >>>> * `log4j-mongodb3`:
> >>> +1: I use mongodb4
> >>>
> >>>> * `log4j-spring-boot`:
> >>> -1: Spring seems too important.
> >>>
> >>>> * Java EE SMTP appended:
> >>> +1: Use the Jakarta version.
> >>>
> >>>> * Jakarta EE SMTP appended:
> >>> -1: Handy, sometimes.
> >>>
> >>>> * `log4j-taglib`:
> >>> +1, never used it.
> >>>
> >>> Gary
> >>>
> >>>>
> >>>> Please cast votes for each module/feature separately on this mailing
> >> list:
> >>>>
> >>>> [ ] +1,  drop the artifact/module,
> >>>> [ ] +/-0
> >>>> [ ] -1,  keep the artifact/module, because...
> >>>>
> >>>> This vote is open for 168 hours (i.e. one week) and each deprecation
> >>>> will pass unless getting a net negative vote count. All votes are
> >>>> welcome, but only the Logging Services PMC votes are officially
> >>>> counted.
> >>>>
> >>>> Piotr
> >>
> >>
>
>

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

[Gary Gregory]

What I mean is this: When I want to work with a DB-like thing from Java, I
look 1st for a JDBC driver, when there is no FOSS option, I have to use a
DB-specifc API, for example MongoDB. Granted Cassandra is NoSQL doc store
but there are commercial JDBC drivers IIRC.

All of this to say that I feel it is nice for us to support non-JDBC stores
when there are no FOSS JDBC drivers available for that datastore type.

2. I got it backward then, thank you for explaining it again. +1 to remove
in 3.0 but keep in 2.x.

Gary

On Thu, Nov 2, 2023, 11:04 AM Ralph Goers 
wrote:

> Gary, a couple of comments:
>
> 1. I don’t understand what “there is no official JDBC access” has to do
> with Cassandra or CouchDB. Could you please elaborate?
> 2. The functionality in log4j-spring-boot is directly incorporated into
> Spring 3 due to a PR I submitted. So with Spring Boot 3 log4j-spring-boot
> should NOT be included. Since Log4j 3.x (at least in my mind) goes hand in
> hand with Spring Boot 3 then removing log4j-spring-boot in 3.x makes sense.
>
> Ralph
>
> > On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
> >
> > My votes:
> >
> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >  wrote:
> >>
> >> This is a vote to deprecate the following `2.x` modules and features
> >> and remove them from the `3.x` release:
> >>
> >> * `log4j-cassandra`:
> > -0: Prefer keeping since there is no official JDBC access that I know
> > of but I have not looked for a while.
> >
> >> * CouchDB appended:
> > -0: Prefer keeping since there is no official JDBC access that I know
> > of but I have not looked for a while.
> >
> >> * `log4j-docker`
> > -1 Docker seems too important.
> >
> >> * GELF appended:
> > +0
> >
> >> * Kafka appended:
> > -0: Prefer keeping since there is no official JMS access that I know
> > of but I have not looked for a while.
> >
> >> * `log4j-kubernetes`:
> > -1: This should match what we do with Docker.
> >
> >> * JeroMQ appender:
> > -0: Prefer keeping since there is no official JMS access that I know
> > of but I have not looked for a while.
> >
> >> * JNDI-related features:
> > -1: Needed in enterprise environments, OK to split out in a separate
> > Maven module.
> >
> >> * `log4j-jpa`:
> > -0: JDBC Appender is good enough for me. Use-case seems narrow except
> > for a JPA shop.
> >
> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).
> >
> >> * `log4j-mongodb3`:
> > +1: I use mongodb4
> >
> >> * `log4j-spring-boot`:
> > -1: Spring seems too important.
> >
> >> * Java EE SMTP appended:
> > +1: Use the Jakarta version.
> >
> >> * Jakarta EE SMTP appended:
> > -1: Handy, sometimes.
> >
> >> * `log4j-taglib`:
> > +1, never used it.
> >
> > Gary
> >
> >>
> >> Please cast votes for each module/feature separately on this mailing
> list:
> >>
> >> [ ] +1,  drop the artifact/module,
> >> [ ] +/-0
> >> [ ] -1,  keep the artifact/module, because...
> >>
> >> This vote is open for 168 hours (i.e. one week) and each deprecation
> >> will pass unless getting a net negative vote count. All votes are
> >> welcome, but only the Logging Services PMC votes are officially
> >> counted.
> >>
> >> Piotr
>
>

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

[Gary Gregory]

My votes:

On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
 wrote:
>
> This is a vote to deprecate the following `2.x` modules and features
> and remove them from the `3.x` release:
>
>  * `log4j-cassandra`:
-0: Prefer keeping since there is no official JDBC access that I know
of but I have not looked for a while.

>  * CouchDB appended:
-0: Prefer keeping since there is no official JDBC access that I know
of but I have not looked for a while.

>  * `log4j-docker`
-1 Docker seems too important.

>  * GELF appended:
+0

>  * Kafka appended:
-0: Prefer keeping since there is no official JMS access that I know
of but I have not looked for a while.

>  * `log4j-kubernetes`:
-1: This should match what we do with Docker.

>  * JeroMQ appender:
-0: Prefer keeping since there is no official JMS access that I know
of but I have not looked for a while.

>  * JNDI-related features:
-1: Needed in enterprise environments, OK to split out in a separate
Maven module.

>  * `log4j-jpa`:
-0: JDBC Appender is good enough for me. Use-case seems narrow except
for a JPA shop.

>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
-1: I want the ability to log to XML (narrow use-case, sure, but handy).

>  * `log4j-mongodb3`:
+1: I use mongodb4

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

>  * Java EE SMTP appended:
+1: Use the Jakarta version.

>  * Jakarta EE SMTP appended:
-1: Handy, sometimes.

>  * `log4j-taglib`:
+1, never used it.

Gary

>
> Please cast votes for each module/feature separately on this mailing list:
>
> [ ] +1,  drop the artifact/module,
> [ ] +/-0
> [ ] -1,  keep the artifact/module, because...
>
> This vote is open for 168 hours (i.e. one week) and each deprecation
> will pass unless getting a net negative vote count. All votes are
> welcome, but only the Logging Services PMC votes are officially
> counted.
>
> Piotr

Re: Why is JNDI still necessary?

[Gary Gregory]

JPMS is something to work _around_, not _with_ IMO.

Gary

On Thu, Nov 2, 2023, 12:25 AM Christian Grobmeier  wrote:

>
>
> On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote:
> > Christian, I was at least 3 years ahead of you on this one.This is
>
> Sorry I was not active for a while. Good you were here.
>
> > precisely why in 3.x we extracted a LOT of stuff from log4j-core into
> > their own modules.
>
> Why not 2.x?
>
> > To be honest the main driver was JPMS - our goal for
> > 3.x Is for log4j-core to only have a hard dependency on java.base and
> > as few optional dependencies as possible.
>
>  I understand, Jpms support was added to 2.x recently. Can we do the same
> thing for 2.x?
>
> > So when Log4Shell hit we
> > moved all the JNDI stuff out of log4j-core AND require a property to be
> > set to use it even if you include the jar containing the JNDI support.
> > In addition, JNDI can now only access the java protocol or no protocol.
> >  So yes, it is very safe now.
>
> In this case we need to improve our communication a lot. The main website
> is still showing all cves and I didn’t find the information easily that I
> just asked for.
> As you mentioned, this issue is history for three years but the website
> still looks like all hell is loose.
>
> I believe you it is safe (always did after all the countless reviews), but
> people still don’t.
>
> With all that said splitting the repos for2.x still feels right.
>
> Christian
>
>
>
> > Ralph
> >
> >> On Nov 1, 2023, at 12:22 PM, Christian Grobmeier 
> wrote:
> >>
> >> As some might know, I am writing a book and the publisher gathers a lot
> of feedback. Also I talk to many people in my classrooms and also to many
> pros at my clients side.
> >>
> >> What I hear is usually:
> >> - is log4j really secure?
> >> - can’t I disable certain features?
> >> - are you sure you get jndi right this time?
> >>
> >> It always comes up why I don’t recommend some competition instead.
> >>
> >> We should not underestimate the impact log4shell had. Jndi was at the
> epi center. Us, providing a giant jar including so much stuff with
> potential security holes don’t do us a favor.
> >>
> >> If we think we have to maintain it, ok, but why can’t we extract it to
> its own dependency?
> >>
> >> Btw, re your comment on -1: I do not plan to do anything against
> consensus. Actually I seek consensus and try to understand better why we
> still have this stuff and what we can do to improve perception . In general
> I feel the atmosphere in this project has heated up more than it should.
> >>
> >>
> >> On Wed, Nov 1, 2023, at 17:29, Matt Sicker wrote:
> >>> I don’t see any reason why we shouldn’t publish the JNDI support in
> its
> >>> own module as we’re planning in main already. Whether we eventually
> >>> split out anything from the main repo is another story, but in 3.x,
> >>> JNDI, like most of the optional features, will require downloading
> >>> additional dependencies to explicitly opt in to using the feature
> (plus
> >>> the JNDI stuff has an additional property you have to set to enable
> it,
> >>> so you can’t end up with JNDI integration by accident even if the
> >>> dependency is available). That seems fairly safe to me, and the
> >>> naysayers at that point tend to be the same people who prefer
> >>> printf-logging or using C because they’re elite programmers who never
> >>> make mistakes and always design things perfectly decades ahead of time.
> >>>
>  On Nov 1, 2023, at 7:18 AM, Apache 
> wrote:
> 
> 
>  If you want separate logging config files in an EJB environment
> using JNDI is pretty much required. The same would be true for any
> properties needed in the configuration.
> 
>  In any case, despite Piotr saying this is a majority vote, it is not.
> I will veto any attempt to remove JNDI components so one really needs to
> view this vote in the light that any component receiving a -1 vote cannot
> be removed as it will simply get a -1 when the PR/commit is attempted from
> whomever gave the -1 vote. In other words, this is NOT a procedural vote
> but a code modification vote that is taking place before the code is
> modified.
> 
>  Ralph
> 
> > On Nov 1, 2023, at 3:13 AM, Christian Grobmeier <
> grobme...@apache.org> wrote:
> > 
> > On Wed, Nov 1, 2023, at 00:01, Ralph Goers wrote:
> >> There is a difference between a JEE application that only uses
> servlets
> >> vs one that uses EJBs. At a former employer we often used JBoss to
> run
> >> servlets even though we had no EJBs. In an environment with EJBs I
> am
> >> not sure how you can distinguish the various components from each
> other
> >> without JNDI.
> >
> > I understand that in the EJB world you would need JNDI, but I fail
> to understand how your EJBs would use Log4j JNDI features? It appears to me
> that while EE world needs it, the Logging world does not necessary need it
> >
> >>
> >> Ralph
> >>
> 

Re: Features for 3.x was: Why is JNDI still necessary?

[Gary Gregory]

Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
17 seems to me as well a good thing.

Gary

On Thu, Nov 2, 2023, 7:04 AM Ralph Goers  wrote:

> I should add that I am concerned that we are missing a huge opportunity
> with Spring 3. A lot of folks will start their migration to Spring 3 early
> next year. Tying Log4J 3.x to that is a big opportunity for people to
> upgrade at the same time.
>
> Ralph
>
> > On Nov 2, 2023, at 3:53 AM, Ralph Goers 
> wrote:
> >
> > Piotr, I haven’t committed much to 3.x since June because it already
> has everything I set out to do. It is everyone else who keeps adding crap
> that “must” be done before it can be released. Yet another year is far too
> long. If that is the case my vote is to skip the additional stuff. And I
> will always be fine other oving things if they are no longer supportable or
> need to be separated into a new module so long as end user code doesn’t
> have to be changed.
> >
> > Releases do not have to be perfect. In fact, someone advised me once
> that you don’t want them to be as that is how you draw in new committers.
> >
> > Ralph
> >
> >> On Nov 2, 2023, at 2:10 AM, Piotr P. Karwasz 
> wrote:
> >>
> >> Hi Ralph,
> >>
>  On Thu, 2 Nov 2023 at 09:42, Apache 
> wrote:
> >>> I’m confused. 3.0.0 hasn’t even been released so how can I be
> preventing adding anything. Personally I would prefer the monitoring to be
> in a separate repo but I am ok with adding it to the main build. IAM all
> for moving async out but unless it can be done quickly I’d rather do it in
> a future 3.x release. The same is generally true for your other bullets as
> well.
> >>
> >> What I meant: we can not **remove** anything after 3.0.0 GA is
> >> released, this includes module refactorings.
> >> I know that you are pushing hard to have a beta by the end of this
> >> year and GA shortly after.
> >>
> >> The problem is: the development of 3.x has been stagnating since June.
> >> Since then I have only seen Matt, Volkan and myself committing
> >> something.
> >> Since most of these changes can not be done in our day jobs, a more
> >> realistic release date for 3.x is the end of the year 2024.
> >> Right now the JLink project I added to Samples works with 2.x, but
> >> **fails** with 3.x (besides, 3.x snapshots are not getting published
> >> since a month and I don't have the faintest idea why).
> >>
> >> Piotr
>
>

Re: Java version usage

[Gary Gregory]

FWIW, at work, we have been conservative with Java version requirements for
a long time, mostly because some of our customers run on old school
hardware. So it's been Java 8 forever. But, we have have just completed the
migration to Java 17 for the three products I work on.

Gary

On Thu, Nov 2, 2023, 1:20 AM Ralph Goers  wrote:

> As a follow up to Christian’s question, here are the usage statistics I
> could find for the Java LTS versions
>
> Java 8Java 11. Java 17
> 33&   56%9%.[1]
> 31%  28%.  19%.   [2]
>
> Unfortunately, Jetbrains has not published a report for 2023 -
> https://www.jetbrains.com/lp/devecosystem-2022/java/.
>
> FWiW, I tend to believe New Relic’s numbers over JRebel since it was
> measured from applications actually using their product instead of a
> survey, but I do wish there was a third survey to compare them to.
> I am expecting that the usage of Java 17 is going to grow very quickly and
> Java 8 will likely go below my 10% threshold by 2025.
>
> Ralph
>
>
> 1. https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem
> 2. https://www.jrebel.com/success/java-developer-productivity-report-2023
>
>

Re: [log4net] Project state

[Gary Gregory]

Not quite IMO, the "project" here is "Loggging Services". The components
inside LS, like Log4j, and so on are different types of items and I don't
think we need to address the state of each. It might be nice to do but I do
not think it is needed.

Gary

On Wed, Nov 1, 2023, 7:47 AM Volkan Yazıcı  wrote:

> In the board report guidelines
> , project
> state is required to be described using the following keywords:
>
>- *New:* a top-level project that's just getting started
>- *Ongoing*, with high, moderate or low activity, which you might
>quantify if appropriate
>- *Dormant:* not much happening on the code, but at least 3 PMC members
>ready to engage if needed
>- *At risk:* not enough active PMC members, or a significant number of
>contributors left the project, etc.
>- *Considering moving to the Attic:* a project that's about to move to
>the Attic, or discussing that
>
> IMO, Log4net can be classified as "at risk", right?
>

Re: [VOTE][LAZY] Release Apache Logging Parent 10.3.0

[Gary Gregory]

Nice PR Piotr!

Gary

On Mon, Oct 30, 2023, 3:57 PM Volkan Yazıcı  wrote:

> I will cancel this RC1, since a `cyclonedx-maven-plugin` bug we have found
> and fixed has been merged and released. Piotr and I will meet with
> some people from the OWASP & CycloneDX front on Friday. I will probably
> issue the RC2 soon after that meeting.
>
> On Thu, Oct 26, 2023 at 11:58 AM Volkan Yazıcı  wrote:
>
> > This is a lazy-vote to release the Apache Logging Parent 10.3.0.
> >
> > Website: https://logging-parent.staged.apache.org/logging-parent
> > GitHub: https://github.com/apache/logging-parent
> > Commit: 55614e3a0beaf44e8c4591b7c530874ed6f524cb
> > Distribution:
> > https://dist.apache.org/repos/dist/dev/logging/logging-parent
> > Nexus:
> > https://repository.apache.org/content/repositories/orgapachelogging-1215
> > 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.
> >
> > === Release Notes
> >
> > This minor release contains several small improvements.
> >
> >  Added
> >
> > * Add support to extend the `bnd-maven-plugin` configuration with
> > `bnd-extra-config` property (apache/logging-log4j2#1895)
> > * Add support to replace `project.build.outputTimestamp` Maven
> > property in CI (#50)
> >
> >  Changed
> >
> > * `deploy-release-reusable.yaml` is improved to automatically derive
> > deployed artifacts as attachments. This renders both
> > `distribution-attachment-filepath-pattern` and
> > `distribution-attachment-count` input arguments redundant for almost
> > all cases.
> > * Convert `bnd-maven-plugin` API leakage warnings to errors
> > (apache/logging-log4j2#1895)
> > * Update `com.google.errorprone:error_prone_core` to version `2.23.0`
> (#49)
> >
> >  Fixed
> >
> > * Fix broken changelog entry validation
> > * Attach `flatten:clean` to `clean` phase
> >
>

Re: SBOM

[Gary Gregory]

FYI to Logging and Brian,

Over at Apache Commons, I added generating of CycloneDX and SPDX SBOMs
that we publish along with our artifacts. So I'd be curious if "we're
doing it wrong" ;-)

My take is that it is still early in the SBOM game and that we're
getting ahead of the game but just producing these files.

We are also discussing publishing OSV and/or VEX files.

Gary

On Fri, Oct 27, 2023 at 7:04 AM Piotr P. Karwasz
 wrote:
>
> Hi all,
>
> On Thu, 19 Oct 2023 at 15:08, Volkan Yazıcı  wrote:
> > > We probably also need to fill in other keys in the SBOM:
> >
> > As far as I can read from sources, custom "keys" (i.e., "external
> > references") are not supported by `cyclonedx-maven-plugin`. I am
> > double-checking this with Hervé Boutemy (`cyclonedx-maven-plugin`
> > maintainer) as we speak. I might create a ticket (maybe even along with a
> > PR) depending on the outcome.
>
> We can probably post-process the output of `cyclonedx-maven-plugin` to
> add additional externalReferences[1] to our artifacts.
>
> The main question is: how useful will that be to current and future
> SBOM processing tools?
>
> Brian, do you have any tips on how to make our SBOM available to the
> largest possible audience? What we are currently planning is:
>
> 1. To generate a CycloneDX SBOM for each of our artifacts using
> `cyclonedx-maven-plugin`, which will add the SBOMs with a classifier
> of `cyclonedx` and a type of `xml` and `json`.
> 2. To add to each of our components in the SBOM two external
> references (that list the vulnerabilities in our own products and how
> we are affected by known vulnerabilities in our dependencies):
>
> 
>   https://logging.apache.org/security/vulnerabilities
> 
> 
>   https://logging.apache.org/security/exploitability
> 
>
> The URLs will profit from HTTP content negotiation and will be
> provided in three formats:
>
>  * CycloneDX XML, if the client accepts 'application/vnd.cyclonedx+xml',
>  * CycloneDX JSON, if the client accepts 'application/vnd.cyclonedx+json',
>  * a plain HTML web page for the 'text/html` format.
>
> My questions regarding this procedure are:
>
> 1. Are CycloneDX attachments in Maven Central processed by some tools?
> Unless I am mistaken, at least Sonatype uses them,
> 2. Are the `vulnerability-assertion` and `exploitability-statement`
> references the right way to provide users with information about
> security-related issues? For example if our `foobar` dependency 1.0.0
> publishes a vulnerability and we update our VEX file with our
> recommendations, will this info reach someone?
> 3. Can we use HTTP content negotiation or should we provide multiple
> external references for each of the supported formats?
>
> Piotr
>
> [1] https://cyclonedx.org/docs/1.5/json/#externalReferences

Re: Serializable gone for 3.0?

[Gary Gregory]

Music to my ears :-)

On Fri, Oct 27, 2023 at 7:06 AM Piotr P. Karwasz
 wrote:
>
> Hi Gary,
>
> On Fri, 27 Oct 2023 at 12:45, Gary Gregory  wrote:
> >
> > Should we remove implements Serializable from classes for 3.0?
>
> Matt already did it as far as I know.
> Anyway it's a +1024 from me: it is technically a breaking change even
> in `log4j-api`, but it is a change most users can live with.
>
> Piotr

Serializable gone for 3.0?

[Gary Gregory]

Should we remove implements Serializable from classes for 3.0?

Gary

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Gary Gregory]

Pin it good! 

On Tue, Oct 24, 2023, 2:04 PM Volkan Yazıcı  wrote:

> I'd like to pin this post in case somebody wants to add yet another manual
> step to the release instructions. 
>
> On Tue, Oct 24, 2023 at 1:58 PM Piotr P. Karwasz 
> wrote:
>
> > Hi Gary,
> >
> > On Tue, 24 Oct 2023 at 13:41, Gary D. Gregory 
> wrote:
> > >
> > > Odd, I do not even see 2.21.1 on
> >
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-api/
> > >
> > > ?
> >
> > I have forgotten about one step of the release process. ;-)
> >
> > Piotr
> >
>

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Gary Gregory]

Ah! ;-)

On Tue, Oct 24, 2023, 7:58 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Tue, 24 Oct 2023 at 13:41, Gary D. Gregory  wrote:
> >
> > Odd, I do not even see 2.21.1 on
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-api/
> >
> > ?
>
> I have forgotten about one step of the release process. ;-)
>
> Piotr
>

Re: [log4j] Project URLs per major version

[Gary Gregory]

Blow up -> become very large, not corrupted.

Gary

On Tue, Oct 24, 2023, 6:45 AM Volkan Yazıcı  wrote:

> Let me elaborate on what I want to achieve with CI automation.
>
> *[I will focus on Log4j, but my statements apply to other Maven-based
> products as well; Log4j Tools, Log4j Kotlin, etc.]*
>
>1. When a new Log4j `release/A.B.C` branch is detected, `logging
>*-log4j-A_B_C.staged*.apache.org` will be automatically populated using
>`./mvnw site`
>2. When a new Log4j release of version `A.B.C` is detected, `
>logging.apache.org*/log4j/A.B.C*` will be automatically populated using
>`./mvnw site`
>3. When a change in `A.x` branch is detected, `logging.apache.org
>*/log4j/A.x*` will be automatically populated using `./mvnw site
>-Drevision=A.B.C`, where `A.B.C` will be determined at runtime as the
>latest published release of major version `A`
>
> #2, I initially didn't want to. Though had calls with Piotr, Ralph, Gary,
> and Matt yesterday, and decided to keep that. #2 causes the Git repository
> to blow up. Matt had some tips, I will propose a workaround soon.
>
> On Mon, Oct 23, 2023 at 1:38 PM Christian Grobmeier 
> wrote:
>
> > This sounds pretty cool Volkan, if I didn't get anything I pretty much
> > like it.
> > One question - you wrote:
> >
> > "we all will enjoy automatically populated Log4j websites."
> >
> > Does this mean we will see our website is updated automatically by CI so
> > we can see in example /log4j/dev?
> > Or what else is "automatically updated"?
> >
> >
> >
> > On Sun, Oct 22, 2023, at 22:20, Volkan Yazıcı wrote:
> > > Currently, we have the following folder structure in the
> > > `logging-log4j-site` repository for the Log4j project:
> > >
> > >- `log4j-1.2.17` – the website generated by the last Log4j 1
> release,
> > >i.e, `1.2.17`
> > >- `log4j-1.2` – symlinks to `log4j-1.2.17`
> > >- `1.x` – symlinks to `log4j-1.2.17`
> > >- ...
> > >- `log4j-2.19.0` – the website generated by the `2.19.0` release
> > >- `log4j-2.20.0` – the website generated by the `2.20.0` release
> > >- `log4j-2.21.0` – the website generated by the `2.21.0` release
> > >- `2.x` – symlinks to `log4j-2.21.0` (the latest Log4j 2 release)
> > >
> > > I propose keeping existing folders as is (hence, *no changes to the
> > > existing URLs!*) and applying following practices:
> > >
> > >1. *Add a `latest` symlink* pointing to the latest stable version.
> > Today
> > >it will point to `2.x`, sometime in the future it will point to
> `3.x`.
> > >   - This will make following URLs possible:
> > >   https://logging.apache.org/log4j/latest
> > >   - This convention is practiced by several other projects, e.g.,
> > >   Spring Boot: https://docs.spring.io/spring-boot/docs/current
> > >2. *Redirect root to `latest`*, i.e., `logging.apache.org/log4j`
> 
> >  will
> > >redirect to `logging.apache.org/log4j/latest`
> 
> > 
> > >3. *Don't create a new folder for every release, but override the
> > `2.x`
> > >folder.*
> > >   - This is okay, since we keep backward compatibility in
> minor+patch
> > >   releases and explicitly provide version for features that are
> > added later
> > >   on (e.g., "starting from 2.17.0 Log4j provides X...")
> > >   - We can set up CI jobs to periodically populate `1.x`, `2.x`,
> > `3.x`,
> > >   `4.x`, etc. websites and avoid the need to generate the website
> > once and
> > >   for all.
> > >   - We will stop polluting the folder structure.
> > >
> > > As a matter of fact, I already implemented this convention for some
> > > projects. All the following URLs work:
> > >
> > >- `logging-parent`
> > >   - logging.apache.org/logging-parent
> > >   - logging.apache.org/logging-parent/latest
> > >   - logging.apache.org/logging-parent/10.x
> > >- `logging-log4j-kotlin`
> > >   - logging.apache.org/log4j/kotlin
> > >   - logging.apache.org/log4j/kotlin/latest
> > >   - logging.apache.org/log4j/kotlin/1.x
> > >- `logging-log4j-scala`
> > >   - logging.apache.org/log4j/scala
> > >   - logging.apache.org/log4j/scala/latest
> > >   - logging.apache.org/log4j/scala/13.x
> > >- `logging-log4j-tools`
> > >   - logging.apache.org/log4j/tools
> > >   - logging.apache.org/log4j/tools/latest
> > >   - logging.apache.org/log4j/tools/0.x
> > >- `logging-log4j-transform`
> > >   - logging.apache.org/log4j/transform
> > >   - logging.apache.org/log4j/transform/latest
> > >   - logging.apache.org/log4j/transform/0.x
> > >
> > > Unless there are objections, I will update the CI in this direction and
> > we
> > > all will enjoy automatically populated Log4j websites.
> >
>

Re: [log4j] Annotation processing alternatives

[Gary Gregory]

Staying from the built-in Service Loader is a recipe for even more
custom code and complications. I say we stick with the built-in
Service Loader.

Gary

On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz
 wrote:
>
> Hi Matt,
>
> On Sun, 22 Oct 2023 at 22:49, Matt Sicker  wrote:
> > So now we come to your question about a factories file. That’s an 
> > interesting idea, though it’s extremely similar to what we’re doing here 
> > with ServiceLoader (though the split between META-INF/services/ files and 
> > module-info.java provides/uses entries is confusing). Moving away from 
> > ServiceLoader to a custom mechanism might be more flexible, though I’m not 
> > very knowledgeable about how Java modules work with them.
>
> I think that `ServiceLoader` is the only standard feature that is
> supported by both OSGi and JPMS. If we move away from it, we'll need
> some custom code to support it (or `opens`, etc). I wouldn't go that
> way.
>
> Piotr

Re: [VOTE] Release Apache Log4j 2.21.1 RC1

[Gary Gregory]

+1

Windows is running on my other PC but all is well on macOS with 'mvn
clean verify' using:

Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /usr/local/Cellar/maven/3.9.5/libexec
Java version: 11.0.21, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@11/11.0.21/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
Darwin gdg-mac-mini.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep
15 14:42:42 PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64

Gary

On Mon, Oct 23, 2023 at 8:50 AM Gary Gregory  wrote:
>
> On Mon, Oct 23, 2023 at 8:10 AM Piotr P. Karwasz
>  wrote:
> >
> > Hi Gary,
> >
> > On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory  wrote:
> > >
> > > I reran again yesterday, got the same 2 failures we know about plus a new 
> > > one:
> >
> > Parallel tests on Windows must be worse than I imagined. Can you run
> > with `-Psequential-tests` in the meantime and I'll try to fix those
> > problems in a future release?
>
> Testing...
>
> Gary
>
> >
> > Piotr

Re: [VOTE] Release Apache Log4j 2.21.1 RC1

[Gary Gregory]

On Mon, Oct 23, 2023 at 8:10 AM Piotr P. Karwasz
 wrote:
>
> Hi Gary,
>
> On Mon, 23 Oct 2023 at 13:33, Gary D. Gregory  wrote:
> >
> > I reran again yesterday, got the same 2 failures we know about plus a new 
> > one:
>
> Parallel tests on Windows must be worse than I imagined. Can you run
> with `-Psequential-tests` in the meantime and I'll try to fix those
> problems in a future release?

Testing...

Gary

>
> Piotr

Re: [VOTE][LAZY] Release Apache Logging Parent 10.2.0

[Gary Gregory]

FWIW, the normal way to proceed is 72 hours but can be reduced, usually for
security issues. There is no rush IMO, especially for a normal release,
time zones and do on.

Gary


On Thu, Oct 19, 2023, 10:40 AM Ralph Goers 
wrote:

> I am confused. I thought even lazy consensus votes needed to stay open for
> 72 hours so people still have time to look at them if they want to. I
> personally do not like limiting a vote to 24 hours except in extraordinary
> circumstances (i.e.critical security fixes).
>
> Ralph
>
> > On Oct 18, 2023, at 12:54 PM, Volkan Yazıcı  wrote:
> >
> > This is a lazy-vote to release the Apache Logging Parent 10.2.0.
> >
> > Website: https://logging-parent.staged.apache.org/logging-parent
> > GitHub: https://github.com/apache/logging-parent
> > Commit: 13ee5ca880ef515b69fb1fc6b5fe2e1807e48be6
> > Distribution:
> https://dist.apache.org/repos/dist/dev/logging/logging-parent
> > Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1204
> > 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.
> >
> > === Release Notes
> >
> > This minor release contains several small improvements.
> >
> >  Added
> >
> > * Added support for auto-generating CycloneDX Software Bill of Materials
> (SBOM)
> >
> >  Changed
> >
> > * Add a compulsory `bnd-baseline-maven-plugin` execution to check for
> > breaking API changes
> > * Apply the default `bnd-maven-plugin` configuration to all the plugin's
> goals
> > * Moves `.flattened-pom.xml` to the same directory as `pom.xml` to
> > preserve the relative parent path. This requires adding
> > `.flattened-pom.xml` to the `.gitignore` file of the repository.
> > * Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
> > version `0.5.0`
> > * Update `log4j-changelog` XSD (used for validating changelog entries)
> > to version `0.1.2`
> > * Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.0`
> (#44)
> >
> >  Fixed
> >
> > * Prioritize definitions in `bnd-extra-*` variables over those inherited
> (#39)
> > * Keep parent in `flatten-bom` configuration (#37)
> > * Remove `build` in `flatten-bom` configuration
> > * Fixed the archiving of symbolically linked directories in the
> > `distribution` Maven profile (#43)
> > * Used specific execution IDs in ``defaultGoal``s to avoid running
> > unwanted plugins
>
>

Re: Log4j JMX GUI (was: [ANNOUNCE] Apache Log4j 2.21.0 released)

[Gary Gregory]

I am OK with either version but the m.m.m one seems better to me.

Gary

On Tue, Oct 17, 2023, 3:54 PM Volkan Yazıcı  wrote:

> Please don't! The entire versioning scheme in the IT universe is
> already sophisticated enough. Let's stick to the good old school
> `major.minor.patch` convention that every person and tool understands.
>
> I support Piotr's `2.21.1` proposal, since this is a "patch" for those
> who download a GUI tool from Maven Central.
>
> On Tue, Oct 17, 2023 at 4:18 PM Ralph Goers 
> wrote:
> >
> > Well, you cannot reuse the tag since you have to modify the pom.xml. You
> could go with 2.21.0.1.
> >
> > Ralph
> >
> > > On Oct 17, 2023, at 5:24 AM, Piotr P. Karwasz 
> wrote:
> > >
> > > Hi Ralph,
> > >
> > > On Tue, 17 Oct 2023 at 13:58, Apache 
> wrote:
> > >>
> > >> Yes
> > >>
> > >> Ralph
> > >
> > > Same release number or 2.21.1? The `rel/2.21.0` tag on the repository
> > > was already used by the faulty release.
> > >
> > > Piotr
> > >
> > >>
> > >>> On Oct 17, 2023, at 4:31 AM, Piotr P. Karwasz <
> piotr.karw...@gmail.com> wrote:
> > >>>
> > >>> Hi all,
> > >>>
> > >>>> On Tue, 17 Oct 2023 at 13:13, Piotr P. Karwasz <
> piotr.karw...@gmail.com> wrote:
> > >>>>> On Tue, 17 Oct 2023 at 12:37, Gary Gregory 
> wrote:
> > >>>>>
> > >>>>> I got hit at work with the loss of log4j-jmx-gui. Is log4j-jmx-gui
> 2.20.0
> > >>>>> compatible with log4j 2.21.0?
> > >>>>
> > >>>> Yes, it is, but there should be a `log4j-jmx-gui` version 2.21.0
> out there:
> > >>>>
> > >>>>
> https://github.com/apache/logging-log4j-jmx-gui/releases/tag/rel%2F2.21.0
> > >>>>
> > >>>> I am not sure why I can't find it on Maven Central.
> > >>>
> > >>> Due to a typo in the `pom.xml`, `log4j-jmx-gui` was published in the
> > >>> `org.apache.logging` group.
> > >>> Should we release it again with the correct Maven group?
> > >>>
> > >>> Piotr
> > >>
> >
>

Re: [ANNOUNCE] Apache Log4j 2.21.0 released

[Gary Gregory]

I got hit at work with the loss of log4j-jmx-gui. Is log4j-jmx-gui 2.20.0
compatible with log4j 2.21.0?

Gary


On Mon, Oct 16, 2023, 5:59 PM Gary Gregory  wrote:

> Thank you for RM'ing Christian!
>
> Gary
>
>
>
> On Mon, Oct 16, 2023, 4:28 PM Christian Grobmeier 
> wrote:
>
>> Apache Log4j team is pleased to announce the 2.21.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 primarily focuses on enhancements to our OSGi and JPMS
>> support and contains several bug fixes.
>> It will be the first release built and signed by the CI using the
>> https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0=index[ASF
>> Logging Services Release Manager GPG key], which is shared in
>> https://www.apache.org/dist/logging/KEYS[KEYS].
>>
>> The Log4j 2.21.0 API, as well as the other artifacts, maintains binary
>> compatibility with the previous release.
>>
>> Apache Log4j 2.21.0 requires Java 8 to run.
>> The build requires JDK 11 and generates reproducible binaries.
>>
>> For complete information on Apache Log4j 2, including instructions on how
>> to submit bug reports, patches, get support, or suggestions for
>> improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2
>> website].
>>
>> === OSGi changes
>>
>> All the published artifacts are OSGi bundles or fragments.
>>
>> This release introduces a change in the bundle symbolic names to allow
>> them to function as JPMS module name: all hyphens `-` present in the bundle
>> names of previous releases were replaced by dots `.`.
>>
>> === JPMS changes
>>
>> All the published artifacts have been migrated from automatic modules to
>> named JPMS modules.
>> All packages marked as private in the Javadoc are not exported.
>>
>> The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`,
>> `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the
>> same convention as the OSGi bundle names.
>>
>> === Added
>>
>> * Added marker parent support to `JsonTemplateLayout` (#1381)
>> * Added https://facebook.github.io/zstd/[ZStandard compression] support
>> (#1508, #1514)
>> * Added a warning for incorrect syntax of highlighting styles (#1545,
>> #1637)
>>
>> === Changed
>>
>> * Open `FileExtension` methods to allow their usage in custom
>> ``RolloverStrategy``s (#1365, #1683)
>> * Bumped the minimum Java version required for the build to JDK 11.
>> Runtime requirements remain unchanged. (#1369)
>> * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to
>> `OFF` and `ALL`, respectively (#1503)
>> * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550)
>> * Use Java version-specific warnings in `StackLocator` (#1760)
>> * Started logging a status error event instead of an NPE in
>> `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has
>> no valid `BundleContext` for a service type
>> * Implemented a CI-based release process
>> * Update Eclipse Angus Activation to version
>> https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1]
>> (#1591)
>> * Update Eclipse Angus Mail to version
>> https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2]
>> (#1591)
>> * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5
>> (#1591)
>> * Update Apache Cassandra to version
>> https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16]
>> (#1591)
>> * Update Apache Commons Compress to version
>> https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0]
>> (#1591)
>> * Update Apache Commons CSV to version
>> https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0]
>> (#1591)
>> * Update Jackson to version
>> https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2]
>> (#1591)
>> * Update Jakarta Activation API to version
>> https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2]
>> (#1591)
>> * Update Jakarta Mail API to version
>> https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591)
>> * Update JCTools to version
>

Re: [ANNOUNCE] Apache Log4j 2.21.0 released

[Gary Gregory]

Thank you for RM'ing Christian!

Gary



On Mon, Oct 16, 2023, 4:28 PM Christian Grobmeier 
wrote:

> Apache Log4j team is pleased to announce the 2.21.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 primarily focuses on enhancements to our OSGi and JPMS
> support and contains several bug fixes.
> It will be the first release built and signed by the CI using the
> https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0=index[ASF
> Logging Services Release Manager GPG key], which is shared in
> https://www.apache.org/dist/logging/KEYS[KEYS].
>
> The Log4j 2.21.0 API, as well as the other artifacts, maintains binary
> compatibility with the previous release.
>
> Apache Log4j 2.21.0 requires Java 8 to run.
> The build requires JDK 11 and generates reproducible binaries.
>
> For complete information on Apache Log4j 2, including instructions on how
> to submit bug reports, patches, get support, or suggestions for
> improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2
> website].
>
> === OSGi changes
>
> All the published artifacts are OSGi bundles or fragments.
>
> This release introduces a change in the bundle symbolic names to allow
> them to function as JPMS module name: all hyphens `-` present in the bundle
> names of previous releases were replaced by dots `.`.
>
> === JPMS changes
>
> All the published artifacts have been migrated from automatic modules to
> named JPMS modules.
> All packages marked as private in the Javadoc are not exported.
>
> The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`,
> `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the
> same convention as the OSGi bundle names.
>
> === Added
>
> * Added marker parent support to `JsonTemplateLayout` (#1381)
> * Added https://facebook.github.io/zstd/[ZStandard compression] support
> (#1508, #1514)
> * Added a warning for incorrect syntax of highlighting styles (#1545,
> #1637)
>
> === Changed
>
> * Open `FileExtension` methods to allow their usage in custom
> ``RolloverStrategy``s (#1365, #1683)
> * Bumped the minimum Java version required for the build to JDK 11.
> Runtime requirements remain unchanged. (#1369)
> * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF`
> and `ALL`, respectively (#1503)
> * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550)
> * Use Java version-specific warnings in `StackLocator` (#1760)
> * Started logging a status error event instead of an NPE in
> `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has
> no valid `BundleContext` for a service type
> * Implemented a CI-based release process
> * Update Eclipse Angus Activation to version
> https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1]
> (#1591)
> * Update Eclipse Angus Mail to version
> https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2]
> (#1591)
> * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5
> (#1591)
> * Update Apache Cassandra to version
> https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16]
> (#1591)
> * Update Apache Commons Compress to version
> https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0]
> (#1591)
> * Update Apache Commons CSV to version
> https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0]
> (#1591)
> * Update Jackson to version
> https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2]
> (#1591)
> * Update Jakarta Activation API to version
> https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] (#1591)
> * Update Jakarta Mail API to version
> https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591)
> * Update JCTools to version
> https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1]
> (#1591)
> * Update Apache Kafka to version
> https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0]
> (#1591)
> * Update Kubernetes client to version
> https://github.com/fabric8io/kubernetes-client/releases?q=5.12.4[5.12.4]
> (#1591)
> * Update `org.mongodb:mongodb-driver-core` to version 4.10.2 (#1591)
> * Update `io.netty:netty-bom` to version 4.1.97 (#1591)
> * Update Spring Boot to version
> https://github.com/spring-projects/spring-boot/releases/tag/v2.7.15[2.7.15]
> (#1591)
> * Update Spring Framework to version
> https://github.com/spring-projects/spring-framework/releases/tag/v5.3.29[5.3.29]
> (#1591)
> * Update Tomcat JULI to version 10.0.27 (#1591)
> * Update Woodstox to version
> https://github.com/FasterXML/woodstox/blob/master/release-notes/VERSION[6.5.1]
> (#1591)

Re: JDBC optimizations in 3.x

[Gary Gregory]

Below...

On Mon, Oct 16, 2023 at 7:38 AM Piotr P. Karwasz
 wrote:
>
> Hi all,
>
> While checking out the module descriptors of `3.x` I have some
> propositions of improvements to `log4j-jdbc` that I would like to run
> by you before creating the appropriate Github issues:
>
> 1. The `log4j-jdbc` module depends on the optional presence of
> `log4j-jndi`. Maybe we should split JNDI support into a
> `log4j-jdbc-jndi` artifact. This way users that do not use JNDI can be
> 100% certain that no JNDI code is present. Users that require JNDI
> have a single dependency to add (`log4j-jdbc-jndi`),

Fine with me but in general I like to only split out this kind of
dependency to avoid optional jar dependencies in a pom.xml.
I'll go with the consensus on this one.


> 2. There are two ways to map event data to columns: ColumnConfig and
> ColumnMapping. It is unclear to me which way is the recommended one.
> Since we can perform breaking changes in 3.x, could we remove one of
> these methods?

I would not REMOVE one, I would merge the functionality of both into
one, probably into ColumnMapping since it is at the "db" level instead
of the lower "jdbc" level.
Either way, merging is the way to go, at least without taking a deep
dive back into it. I can tell you that I rely on the JDBC and DBCP
variant module.

> 3. Literal values are inserted AS-IS into the prepared statement. Java
> 9 introduced `Statement#enquoteLiteral`, maybe we should use it by
> default, so users are not required to quote the value themselves. We
> can provide an additional `quoteLiteral` attribute with a default of
> true, to allow users to add whatever they want to the prepared
> statement unquoted,

I can't say without trying the API and seeing how it works in
practice. I would do 3 above first to avoid duplicating work.

> 4. The appender itself is quite wasteful in the number of connections
> it uses (one per log message). IIRC JDBC connections are not
> thread-safe, but can be used from multiple threads if synchronization
> is provided. `AbstractDatabaseManager#write` provides such a
> synchronization. With the current connection usage pattern, the
> "DriverManager" connection source is basically useless.
> 5. We should consider integrating the JDBC pooling features with PR
> 1401: https://github.com/apache/logging-log4j2/pull/1401.

Pooling is already supported by the jdbc-dbcp2 module.
What am I missing?

Gary

>
> Piotr

Re: JDBC optimizations in 3.x

[Gary Gregory]

Great questions and I will address each one, hopefully later today.

Gary

On Mon, Oct 16, 2023, 7:38 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> While checking out the module descriptors of `3.x` I have some
> propositions of improvements to `log4j-jdbc` that I would like to run
> by you before creating the appropriate Github issues:
>
> 1. The `log4j-jdbc` module depends on the optional presence of
> `log4j-jndi`. Maybe we should split JNDI support into a
> `log4j-jdbc-jndi` artifact. This way users that do not use JNDI can be
> 100% certain that no JNDI code is present. Users that require JNDI
> have a single dependency to add (`log4j-jdbc-jndi`),
> 2. There are two ways to map event data to columns: ColumnConfig and
> ColumnMapping. It is unclear to me which way is the recommended one.
> Since we can perform breaking changes in 3.x, could we remove one of
> these methods?
> 3. Literal values are inserted AS-IS into the prepared statement. Java
> 9 introduced `Statement#enquoteLiteral`, maybe we should use it by
> default, so users are not required to quote the value themselves. We
> can provide an additional `quoteLiteral` attribute with a default of
> true, to allow users to add whatever they want to the prepared
> statement unquoted,
> 4. The appender itself is quite wasteful in the number of connections
> it uses (one per log message). IIRC JDBC connections are not
> thread-safe, but can be used from multiple threads if synchronization
> is provided. `AbstractDatabaseManager#write` provides such a
> synchronization. With the current connection usage pattern, the
> "DriverManager" connection source is basically useless.
> 5. We should consider integrating the JDBC pooling features with PR
> 1401: https://github.com/apache/logging-log4j2/pull/1401.
>
> Piotr
>