[log4j] Request-for-review: Consolidate stack trace rendering in Pattern Layout

[Volkan Yazıcı]

In #2691 , I teamed up
with Alan to rewrite the stack trace rendering in Pattern Layout. Since
this will have a major impact on users, and even though I implemented 1579
new tests[1], I appreciate your reviews too.

[1] Yes, I replaced ~30 tests with 1579 new ones. You can check it yourself
too: `./mvnw test -pl :log4j-core-test
-Dtest="*ThrowablePatternConverterTest"`

[log4j] Where are SBOMs? (Was: [VOTE] Release Apache Log4j `2.24.1` (RC1))

[Volkan Yazıcı]

They are precisely in the binary ZIP:

$ unzip -l log4j/2.24.1/apache-log4j-2.24.1-bin.zip | grep cyclonedx
29163  2024-09-24 13:33   log4j-1.2-api-2.24.1-cyclonedx.xml
21118  2024-09-24 13:33   log4j-2.24.1-cyclonedx.xml
25085  2024-09-24 13:33   log4j-api-2.24.1-cyclonedx.xml
   139136  2024-09-24 13:33   log4j-api-test-2.24.1-cyclonedx.xml
...


On Wed, Sep 25, 2024 at 8:48 PM Gary Gregory  wrote:

> I expected to see SBOMs in the binary zip, CycloneDX and/or SPDX. Are
> they missing? Did I not find them?
>
> Gary
>
> On Tue, Sep 24, 2024 at 3:13 PM Piotr P. Karwasz
>  wrote:
> >
> > This is a vote to release the Apache Log4j `2.24.1`.
> >
> > Website: https://logging.staged.apache.org/log4j/2.24.1/index.html
> > GitHub: https://github.com/apache/logging-log4j2
> > Commit: 8ee9387d9ec2063ab11f27eaa43e44a13f4c9935
> > Distribution:
> https://dist.apache.org/repos/dist/dev/logging/log4j/2.24.1
> > Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1303
> > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
> > Review kit:
> https://logging.apache.org/logging-parent/release-review-instructions.html
> >
> > Please download, test, and cast your votes on this mailing list.
> >
> > [ ] +1, release the artifacts
> > [ ] -1, don't release, because...
> >
> > This vote is open for 72 hours and will pass unless getting a
> > net negative vote count. All votes are welcome and we encourage
> > everyone to test the release, but only the Logging Services PMC
> > votes are officially counted. At least 3 +1 votes and more
> > positive than negative votes are required.
> >
> > == Release Notes
> >
> > This release contains mainly bug fixes of problems encountered with
> > the thread context map, logger registry and configuration reloading.
> >
> > It also enhances integration tests to use Docker images of the most
> > recent releases of MongoDB and Elastic Search.
> >
> > === Changed
> >
> > * Rework `LoggerRegistry` to make it `MessageFactory`-namespaced. This
> > effectively allows loggers of same name, but different message
> > factory. (#2936)
> > * Enable Docker-based tests in CI for JSON Template Layout (#2953)
> >
> > === Fixed
> >
> > * Switch MongoDB tests to use Docker. (#2229)
> > * Fix reloading of the configuration from an HTTP(S) source (#2937)
> > * Fix `putAll()` in the default thread context map implementation (#2942)
> >
> > === Updated
> >
> > * Update `org.apache.logging:logging-parent` to version `11.3.0`
>

[log4cxx] Request-for-review: Google OSS-Fuzz integration

[Volkan Yazıcı]

OSS-Fuzz  is a Google service that
continuously runs fuzz tests of critical F/OSS projects on a beefy cluster
and reports its findings (bugs, vulnerabilities, etc.) privately to project
maintainers. In #411 ,
I implemented fuzz tests for Log4j 2 and their integration with OSS-Fuzz. I
have documented the details in `fuzzing.md`

, e.g.,

   - Running fuzz tests locally
   - Viewing fuzzing failures detected by OSS-Fuzz
   - Reproducing fuzzing failures detected by OSS-Fuzz

If you have any further questions, please let me know. If requested, I can
also provide a walkthrough in the next PMC meeting.

Re: Use RTC in Log4j and Log4Net

[Volkan Yazıcı]

On Wed, Sep 18, 2024 at 10:17 AM Piotr P. Karwasz 
wrote:

> However, we don't necessarily need to use `2.x` or `main` for those tests.
>

You cannot fix fuzz tests in another branch than `2.x` once OSS-Fuzz starts
pointing there – unless you're willing to waste +2 months for testing a
simple typo: waiting for a month on a OSS-Fuzz PR targeting from `2.x` to
`your-test-branch`, and another month for changing it back. I don't think
waiting +2 months for a one-liner is an acceptable development cycle.

Another example is INFRA issues. I forgot the count of arbitrary commits we
needed to push to `logging-site` to recover the last `logging.staged.a.o`
outage.

Re: Use RTC in Log4j and Log4Net

[Volkan Yazıcı]

I agree in principle, but...

*Exemption criteria*

I agree with Ralph on that we should specify criteria on what shall be
exempt from this PR-driven workflow policy. We should of course materialize
these criteria collaboratively. Below is my attempt for a starting point:

Changes can be exempt from this policy if and only if they suffice *only
one* of the following conditions:

   1. Grammatical corrections to the documentation (incl. Javadoc and
   release notes)
   2. Code typo fixes¹ less than 10 LoC
   3. Infrastructure fixes¹ touching to `pom.xml` or CI scripts, and less
   than 10 LoC

¹ A "fix" is assumed to not introduce a change in the expected behaviour of
the associated component. Changing the expected behaviour does not qualify
a fix.

*Scoped repositories*

I suggest extending the scope of this policy to cover the following
repositories too:

   1. `logging-parent`
   2. `logging-log4j-jakarta`
   3. `logging-jmx-gui`
   4. `logging-samples`
   5. `logging-site`
   6. `logging-log4net-site`

*Maintainer availability*

The PR-driven workflow can fly because we have full-time maintainers. But
that will not be the case anymore in 2-3 months due to funds drying out. I
suspect introducing such a policy with strict deadlines (e.g., 24 hours is
a pretty tight time budget for a project with no full-time maintainers) and
no exemptions might jeopardize the streamlining of development in the long
run. That said, as Christian noted, we can adapt/drop the policy later on
if needed.

I disagree with Matt's *"losing momentum from waiting for an unnecessary
code review"* statement. In the last three years or so – even before STF
funding and Piotr! – well-scoped PRs, where the author onboards reviewers
with sufficient navigation tips, have been processed very swiftly, AFAICT.

On Wed, Sep 18, 2024 at 12:16 AM Ralph Goers 
wrote:

> This isn’t a vote so I am not going to. If I had to vote I wouldn’t vote
> for a policy that requires RTC always. However, I would vote for a policy
> that requires RTC when specified criteria are met.
>
> Ralph
>
> > On Sep 17, 2024, at 10:28 AM, Ralph Goers 
> wrote:
> >
> > First, the obvious. I haven’t committed much in a while. The last
> several I did I used PRs primarily because it makes it easier for people to
> review the changes but I didn’t necessarily wait for a review.  For really
> simple stuff I've never use a PR. However, with the switch from Jira to
> GitHub issues it might make more sense to use a PR since you have to have
> something to track the problem. But if there is already an issue then I
> would probably just use that. Again, depending on what is being done.
> >
> > I wouldn’t classify any of the work I’ve seen you doing recently as
> trivial or minor, so you only doing PRs makes sense.
> >
> > Ralph
> >
> >> On Sep 17, 2024, at 7:52 AM, Piotr P. Karwasz 
> wrote:
> >>
> >> Hi Ralph,
> >>
> >> On Tue, 17 Sept 2024 at 15:47, Ralph Goers 
> wrote:
> >>>
> >>> Why? i.e. - what currently isn’t working?
> >>
> >> I merely wish to formalize what is already happening and set up a
> >> branch protection rule to enforce it.
> >>
> >> Note that I have never seen a PR in Log4Net being merged without a
> review.
> >>
> >> On the other hand you can probably find a couple of my recent PRs that
> >> don't have a formal review. Sure, I must have certainly consulted with
> >> someone on Slack before I merged them, but there is no sign of it.
> >> Let's make it formal, so users also see it.
> >>
> >> Piotr
> >
>
>

[log4j] Google OSS-Fuzz integration

[Volkan Yazıcı]

OSS-Fuzz  is a Google service that
continuously runs fuzz tests of critical F/OSS projects on a beefy cluster
and reports its findings (bugs, vulnerabilities, etc.) privately to project
maintainers. In #2949 ,
I implemented fuzz tests for Log4j 2 and their integration with OSS-Fuzz. I
have documented the details in `FUZZING.adoc`
, e.g.,

   - How can I run fuzz tests locally?
   - How can I view fuzzing failures detected by OSS-Fuzz?
   - How can I reproduce fuzzing failures detected by OSS-Fuzz?

If you have any further questions, please let me know. If requested, I can
also provide a walkthrough in the next PMC meeting.

Re: Can't build log4j main branch

[Volkan Yazıcı]

Gary has a failure on L361, that is, it retries every 100ms to succeed with
`logger.info()` for at most 2mins. I doubt if more waiting will solve the
problem. I tried to improve that test several times (see its history), but
Windows just behaves weird with sockets. I'd appreciate it if Windows users
can share some tips on what else we can do.

Piotr, you say "a proven history of flakiness", but the link you shared
states, out of 1.26k times, in the last 90 days, it has failed only 2
times, and was flaky only 16 times. What is our definition of flakiness
here?

On Mon, Sep 16, 2024 at 7:09 PM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Mon, 16 Sept 2024 at 16:50, Gary D. Gregory 
> wrote:
> >
> > I just pulled main since we've had changes there, now I get:
> >
> > [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 15.31 s <<< FAILURE! -- in
> org.apache.logging.log4j.core.appender.SocketAppenderReconnectTest
> > [ERROR]
> org.apache.logging.log4j.core.appender.SocketAppenderReconnectTest.repeating_reconnect_failures_should_be_propagated
> -- Time elapsed: 3.323 s <<< ERROR!
> > org.apache.logging.log4j.core.appender.AppenderLoggingException: Error
> writing to TCP:localhost:57111 for connection localhost/127.0.0.1:57111
>
> This is a test with a proven history of flakiness[1]. I guess we need
> to add more conditions to the test (e.g. wait until the server
> received a connection request from the client).
>
> Piotr
>
> [1]
> https://ge.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=Apache%20Log4j%20BOM&search.timeZoneId=Europe%2FWarsaw&tests.container=org.apache.logging.log4j.core.net.SocketAppenderReconnectTest#
>

[log4j] Spring Boot 3.4.0 will introduce structured logging

[Volkan Yazıcı]

See the related release note
.
With this change, Spring Boot will effectively be providing an
implementation-agnostic logging system abstraction featuring:

   - Level support
   - Pattern layout support
   - Structured (i.e., JSON) layout support (New!)

Note that many modern SOA deployment solutions
 expect application logs to
be written to the console, which renders the need for specialized appenders
obsolete. Given this, if I may say, Spring Boot's logging abstraction
pretty much makes the need to employ/configure a logging system obsolete –
Spring Boot aims to cover 90% of logging-related use cases with its
in-house abstractions. I can imagine a majority of its users will be able
to develop and deploy to production without any `log4j2.xml`,
`logback.xml`, or `logging.properties` configurations.

Re: [VOTE] Release Apache Log4net 3.0.0

[Volkan Yazıcı]

+1

✅ Signatures
✅ Checksums
✅ Build (using Docker)
✅ Tests (using Docker)

Congratulations to the Log4net crew (in particular, to Jan and Davyd 🙇)
for their 3rd major release! 🎉 Keep up the great work! 💯



On Thu, Sep 12, 2024 at 8:54 PM Jan Friedrich  wrote:

> This is a vote to release the Apache Log4net 3.0.0.
>
> 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/rc/3.0.0-rc1
> Commit: 42ba791745ceb7ff922d828c6c5572ed918df84b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net
> Signing key: 0x7D24496A230E29D6349A99EF583E491578F02D5D
>
>
> Please download, test, and cast your votes on this mailing list.
>
> How to run the unit tests?
> - install docker (if you haven't already)
>   - https://docs.docker.com/engine/install/
> - in logging/log4net run
>   - `docker build -t log4net-builder .`
>   - `docker run -it log4net-builder`
> - this will
>   - install all dependencies in the container
>   - build src/log4net.sln
>   - inside the container run
> - `dotnet test /logging-log4net/src/log4net.sln`
>
> [ ] +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.
>
>

Re: [ANNOUNCE] Apache Log4j `2.24.0` released

[Volkan Yazıcı]

You're right Ralph, my mistake ­– apparently I totally missed that page. I
will update email templates (of 8 repositories! 🥴) accordingly.

On Sun, Sep 8, 2024 at 12:29 AM Ralph Goers 
wrote:

> https://www.apache.org/legal/release-policy.html#release-announcements
>
> Second sentence of the second paragraph.
>
> | "Announcements must contain a link to the relevant download page
> for the source.”
>
> I quoted this I the discussion email during the vote for RC1. Referencing
> the overall web site doesn’t fulfill this requirement.
>
> However, I either didn’t look carefully enough or the page changed (more
> likely the first than the second) as I did not notice that the downloads
> page actually does have the specific links for the artifacts. In my first
> look I only saw the link to the Logging Services download page.
>
> Ralph
>
>
> > On Sep 7, 2024, at 7:03 AM, Volkan Yazıcı 
> wrote:
> >
> > Can you share where “a direct link” requirement for announcements is
> > stated, please? I know of no policy for “announcement emails”. Of the
> pages
> > I know, there is no such requirement:
> >
> > Distribution policy:
> > https://infra.apache.org/release-distribution.html
> > Dist. Creation Process:
> > https://infra.apache.org/release-publishing.html
> >
> > The only “link” related requirement I see is the following:
> >
> > “Website documentation for any Apache product must provide public
> download
> > links where interested parties may obtain current official source
> releases
> > and accompanying cryptographic files.”
> >
> > and we certainly suffice this condition. Website guides users to download
> > artifacts and in the announcement email we share a link to the website.
> > Hence, AFAIC, we comply with the ASF policy. Our release email getting
> > allowed in announce@ also backs this claim up.
> >
> > Op za 7 sep 2024 om 15:20 schreef Ralph Goers <
> ralph.go...@dslextreme.com>
> >
> >> Literally the only requirement for the announcement is that it contains
> a
> >> direct link to where the source archive can be downloaded.
> >>
> >> Personally, I like to contain a synopsis of the release (bug fix, minor
> >> enhancements, etc) with 2 or 3 significant items if there are any and
> then
> >> provide a link to the release notes.
> >>
> >> Ralph
> >>
> >>> On Sep 6, 2024, at 11:49 PM, Piotr P. Karwasz  >
> >> wrote:
> >>>
> >>> Hi Ralph,
> >>>
> >>> On Sat, 7 Sept 2024 at 07:00, Ralph Goers 
> >> wrote:
> >>>>
> >>>> As I said previously, you should expect this will NOT get moderated
> >> through the ASF announce list.
> >>>
> >>> The e-mail has the same format as the one I sent for 2.23.0[1] and is
> >>> very similar to the one for 3.0.0-alpha1[2].
> >>>
> >>> Looking at other announcement emails, we could probably modify ours by:
> >>>
> >>> * Stripping them of the release notes, except the short intro we write
> >>> manually. The entire list of changes can probably be replaced with a
> >>> link to the release notes.
> >>> * Adding the download and release notes links explicitly.
> >>>
> >>> What do you think?
> >>>
> >>> Piotr
> >>>
> >>> [1] https://lists.apache.org/thread/8fycgpb2k274bc4y8gp1zswy5jpzc2jh
> >>> [2] https://lists.apache.org/thread/z3otp9jr9bpo0r732k02g1mdlfkjb3gm
> >>
> >>
>
>

Re: [ANNOUNCE] Apache Log4j `2.24.0` released

[Volkan Yazıcı]

Good news! It survived the moderation:
https://lists.apache.org/thread/8mzhby29jcrsm8fnoodhdz2sqb72jd0z No changes
needed.

Op za 7 sep 2024 om 06:59 schreef Ralph Goers 

> As I said previously, you should expect this will NOT get moderated
> through the ASF announce list.
>
> Ralph
>
> > On Sep 6, 2024, at 3:07 PM, Piotr P. Karwasz 
> wrote:
> >
> > Apache Log4j team is pleased to announce the `2.24.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/2.x/index.html
> >
> > == Release Notes
> >
> > The `2.24.0` version of Log4j API has been enhanced with changes from
> > the 3.x branch and will be used by both Log4j 2 Core and Log4j 3 Core
> > releases.
> > The changes include:
> >
> > * A faster default `ThreadContextMap`.
> > * Enhanced GraalVM support: native binaries that use Log4j API will no
> > longer require additional GraalVM configuration.
> > * The configuration properties subsystem now only accepts the official
> > pre-2.10 property names and the normalized post-2.10 names.
> > Check your configuration for typos.
> >
> > === Documentation
> >
> > The Apache Log4j 2[1] website has been almost entirely rewritten to
> > provide improved documentation and faster access to the information
> > you need.
> >
> > [1] https://logging.staged.apache.org/log4j/2.24.0/index.html <
> https://logging.staged.apache.org/log4j/2.24.0/index.html>
> >
> > === Bridges
> >
> > The JUL-to-Log4j API and Log4j 1-to-Log4j API will no longer be able
> > to modify the configuration of Log4j Core by default.
> > If such a functionality is required, it must be explicitly enabled.
> >
> > === Modules
> >
> > The following Log4j Core additional modules have been removed:
> >
> > `log4j-flume-ng`::
> > The module is no longer part of the release process and will follow
> > its own release lifecycle.
> > Please manage your dependencies using `log4j-bom`[2] to always use its
> > latest version.
> >
> > `log4j-kubernetes`::
> > The module has been moved to the Fabric8.io Kubernetes project[3] and
> > follows the Fabric8.io release lifecycle.
> >
> > `log4j-mongodb3`::
> > The module based on MongoDB Java client version 3.x has been removed.
> > Please migrate to `log4j-mongodb`[4] (client version 5.x) or
> > `log4j-mongodb4`[5] (client version 4.x).
> >
> > [2] https://logging.apache.org/log4j/2.x/components.html#log4j-bom <
> https://logging.apache.org/log4j/2.24.0/components.html#log4j-bom>
> > [3]
> https://github.com/fabric8io/kubernetes-client/blob/main/doc/KubernetesLog4j.md
> <
> https://github.com/fabric8io/kubernetes-client/blob/main/doc/KubernetesLog4j.md
> >
> > [4] https://logging.apache.org/log4j/2.x/components.html#log4j-mongodb <
> https://logging.apache.org/log4j/2.24.0/components.html#log4j-mongodb>
> > [5] https://logging.apache.org/log4j/2.x/components.html#log4j-mongodb4
> 
> >
> > === JMX changes
> >
> > Starting in version 2.24.0, JMX support is disabled by default and can
> > be re-enabled via the `log4j2.disableJmx=false` system property.
> >
> > === Added
> >
> > * Add a faster `DefaultThreadContextMap` implementation. (#2330)
> > * Add Logback throwable-consuming semantics as an option in
> > `log4j-slf4j-impl` and `log4j-slf4j2-impl`. Users can enable it by
> > setting the property `log4j2.messageFactory` to
> > `org.apache.logging.slf4j.mess
> >
> > age.ThrowableConsumingMessageFactory`.
> > (#2363)
> > * Add trace context fields to `GcpLayout.json` (#2498)
> > * Add _"Plugin Reference"_ to the website. It is a Javadoc-on-steroids
> > focusing on Log4j plugins. (#1954)
> > * Automate website deployment using the new CI infrastructure shipped
> > with `org.apache.logging:logging-parent:11.0.0`
> >
> > === Changed
> >
> > * Fix usage of `log4j-api` in GraalVM without additional reachability
> > data. (#1539)
> > * Ignore exceptions thrown by PropertySources.
> > * Add logging to `PropertiesUtil` and fix `Duration` parser. (#1936)
> > * Disable level modification via JUL by default. (#2353)
> > * Centralize initialization in the `Provider` class and deprecate
> > `log4j2.loggerContextFactory` property. (#2374)
> > * Remove `log4j-kubernetes` lookup. User should migrate to
> > `io.fabric8:kubernetes-log4j`[6]. (#2412)
> > * Disable JMX support by default. Require `log4j2.disableJmx` to be
> > set to `false` to enable JMX support. (#2462)
> > * Replace some usages of `DateTimeFormatter#toString()` with
> > `DateTimeFormatter#formatTo(StringBuilder)` to cut down on allocations
> > (#2515)
> > * Disable programmatic configuration in Log4j 1 Bridge if
> > `log4j1.compatibility` is `false`. (#2778)
> > * Improve missing plugin descriptor warnings. (#2835)
> > * Remov

Re: [VOTE] Release Apache Log4j `2.24.0` (RC2)

[Volkan Yazıcı]

+1

I've verified this release using a Docker container documented in the
"Release review instructions" page

I've just created.

Gary, would you mind checking if the troubleshooting techniques documented
there help you any, please?

On Tue, Sep 3, 2024 at 8:15 PM Gary D. Gregory  wrote:

> Sorry to be a pain, on Windows, running 'mvn clean verify', I get:
>
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 1, Time elapsed:
> 11.48 s <<< FAILURE! -- in
> org.apache.logging.log4j.core.net.UrlConnectionFactoryTest
> [ERROR]
> org.apache.logging.log4j.core.net.UrlConnectionFactoryTest.withAuthentication
> -- Time elapsed: 0.093 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: File was not modified ==> expected:
> <200> but was: <304>
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:563)
> at
> org.apache.logging.log4j.core.net.UrlConnectionFactoryTest.withAuthentication(UrlConnectionFactoryTest.java:130)
> at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>
> I can't dig in now :-( day job calls...
>
> Gary
>
> On 2024/09/03 16:56:42 "Piotr P. Karwasz" wrote:
> > This is a vote to release the Apache Log4j `2.24.0`.
> >
> > Website: https://logging.staged.apache.org/log4j/2.24.0/index.html
> > GitHub: https://github.com/apache/logging-log4j2
> > Commit: c79ae325f6a21af45526c202f121bfced188613e
> > Distribution:
> https://dist.apache.org/repos/dist/dev/logging/log4j/2.24.0/
> > Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1294
> > 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
> > wget --cut-dirs=6 \
> >  --no-host-directories \
> >  --no-parent \
> >  --recursive \
> >  https://dist.apache.org/repos/dist/dev/logging/log4j/2.24.0/
> >
> > # Verify checksums
> > sha512sum --check *.sha512
> >
> > # Verify signatures
> > #
> > # If you didn't import the KEYS previously, run:
> > # wget -O - https://downloads.apache.org/logging/KEYS | gpg --import
> > for sigFile in *.asc; do gpg --verify $sigFile; done
> >
> > # Verify reproducibility (only Linux/MacOS X)
> > umask 0022
> > unzip *-src.zip -d src
> > cd src
> > export NEXUS_REPO=
> https://repository.apache.org/content/repositories/orgapachelogging-1294
> > sh mvnw -Prelease clean verify artifact:compare
> -Dreference.repo=$NEXUS_REPO
> >
> > # Run tests only (Windows)
> > sh mvnw -Prelease clean verify
> >
> > == Release Notes
> >
> > This release contains improvements and changes in several areas of
> Apache Log4j:
> >
> > === Log4j API
> >
> > The `2.24.0` version of Log4j API has been enhanced with changes from
> > the 3.x branch and will be used by both Log4j 2 Core and Log4j 3 Core
> > releases.
> > The changes include:
> >
> > * A faster default `ThreadContextMap`.
> > * Enhanced GraalVM support: native binaries that use Log4j API will no
> > longer require additional GraalVM configuration.
> > * The configuration properties subsystem now only accepts the official
> > pre-2.10 property names and the normalized post-2.10 names.
> > Check your configuration for typos.
> >
> > === Documentation
> >
> > The Apache Log4j 2[1] website has been almost entirely rewritten to
> > provide improved documentation and faster access to the information
> > you need.
> >
> > [1] https://logging.staged.apache.org/log4j/2.24.0/index.html
> >
> > === Bridges
> >
> > The JUL-to-Log4j API and Log4j 1-to-Log4j API will no longer be able
> > to modify the configuration of Log4j Core by default.
> > If such a functionality is required, it must be explicitly enabled.
> >
> > === Modules
> >
> > The following Log4j Core additional modules have been removed:
> >
> > `log4j-flume-ng`::
> > The module is no longer pa

Re: [VOTE] Release Apache Log4j `2.24.0`

[Volkan Yazıcı]

If you are referring to the `logging-parent`-provided features, they are
documented in the, well, Features page of the `logging-parent`
<https://logging.apache.org/logging-parent/features.html> website. It also
has a Usage page <https://logging.apache.org/logging-parent/usage.html>
explaining how one can use it for new projects. Where do these fall short
of addressing your questions?

On Wed, Sep 4, 2024 at 5:43 PM Ralph Goers 
wrote:

> Personally, I would appreciate a document I can read that documents the
> build process. Even though I am sure it is all Maven plugins of some kind
> it isn’t unusual for the order and configuration of the plugins to be
> important.
>
> I’d really like to know what I need to do to get it to work for some
> existing project or a brand new one.
>
> Ralph
>
> > On Sep 4, 2024, at 3:56 AM, Christian Grobmeier 
> wrote:
> >
> >
> > On Tue, Sep 3, 2024, at 21:51, Gary Gregory wrote:
> >> From my point of view, building has gotten worse and less reliable over
> >> time :-(
> >
> > To be fair, the new build system was, at least for me, welcoming and
> straightforward to use. Although complex under the hood, it’s a major
> improvement over the build system we had in log4j1 (like Stone Age to
> enterprise) and also lots better than the various documents with different
> content we had with early log4j2
> >
> > I am not sure why it did not build on your machine but on the others,
> but it is certainly worth to improve the system we have today.
> >
> > I see a trend within this team that only few people push forward changes
> like maintaining the build. I think it would be beneficial if others would
> learn more about how it works and the details so everyone can provide
> patches.
> >
> > Volkan already offered to help. If there is more interest we maybe could
> have video training session on the details, assuming Volkan would be
> willing to do this as well. I would be certainly interested in this.
> >
> > Cheers
> >
> >> My -1 vote reflects this.
> >>
> >> Gary
> >>
> >> On Tue, Sep 3, 2024, 2:55 PM Volkan Yazıcı  <mailto:vol...@yazi.ci.invalid>> wrote:
> >>
> >>> Gary, do you know what is the difference between RC1 and RC2? Nothing.
> >>> Piotr only kindly added a one-liner condition check to the contending
> >>> (FQDN-related) test to make it up to you. That is the only difference –
> >>> plus, he updated the review kit (shared in the email) to avoid the
> >>> reproducibility check on Windows. Put another way, RC1 is effectively
> >>> identical to RC2, bit by bit.
> >>>
> >>> My point is, 3 people verified the release and CI runs passed on all 3
> >>> platforms – there is definitely something unexpected in your setup. As
> you
> >>> know better, issuing an RC is a time and energy consuming task.
> Besides RM,
> >>> other voters put effort into it too. Would you mind asking for further
> help
> >>> instead of downvoting a release due to local failures, please? I would
> have
> >>> been more than happy to assist you in a video call, instead of
> re-issuing
> >>> the whole release.
> >>>
> >>> On Tue, Sep 3, 2024 at 4:04 PM Gary D. Gregory 
> >>> wrote:
> >>>
> >>>> -1
> >>>>
> >>>> On Windows, I deleting my entire .m2/repository folder and then ran
> >>>>
> >>>> mvnw -Prelease clean verify artifact:compare
> >>> -Dreference.repo=%NEXUS_REPO%
> >>>>
> >>>> and got:
> >>>>
> >>>> [INFO] Minimal buildinfo generated from downloaded artifacts:
> >>>>
> >>>
> C:\Users\ggregory\rc\2.24.0\src\target\reference\log4j-bom-2.24.0.buildinfo
> >>>> [ERROR] size mismatch log4j-bom-2.24.0.pom: investigate with
> diffoscope
> >>>> target\reference\org.apache.logging.log4j\log4j-bom-2.24.0.pom
> >>>> .flattened-pom.xml
> >>>> [ERROR] size mismatch log4j-bom-2.24.0-cyclonedx.xml: investigate with
> >>>> diffoscope
> >>>>
> target\reference\org.apache.logging.log4j\log4j-bom-2.24.0-cyclonedx.xml
> >>>> target\bom.xml
> >>>> [ERROR] Reproducible Build output summary: 0 files ok, 2 different
> >>>> [ERROR] see diff target\reference\log4j-bom-2.24.0.buildinfo
> >>>> target\log4j-bom-2.24.0.buildinfo
> >>>> [ERROR] see also
> >>>> https://maven.apache.org/guides/mini/guide

Re: [VOTE] Release Apache Log4j `2.24.0`

[Volkan Yazıcı]

> You're not helping the cause.

I am offering a video call to assist you. What else do you want me to do?


On Tue, Sep 3, 2024 at 9:51 PM Gary Gregory  wrote:

> Volcan,
>
> Please stop complaining about the hours I've already sunk into validation
> on 3 different operating system on two different machines. You're not
> helping the cause.
>
> I can't help but notice the irony that one of the failures is in the
> "reproducible" part of the build.
>
> From my point of view, building has gotten worse and less reliable over
> time :-(
>
> My -1 vote reflects this.
>
> Gary
>
> On Tue, Sep 3, 2024, 2:55 PM Volkan Yazıcı  wrote:
>
> > Gary, do you know what is the difference between RC1 and RC2? Nothing.
> > Piotr only kindly added a one-liner condition check to the contending
> > (FQDN-related) test to make it up to you. That is the only difference –
> > plus, he updated the review kit (shared in the email) to avoid the
> > reproducibility check on Windows. Put another way, RC1 is effectively
> > identical to RC2, bit by bit.
> >
> > My point is, 3 people verified the release and CI runs passed on all 3
> > platforms – there is definitely something unexpected in your setup. As
> you
> > know better, issuing an RC is a time and energy consuming task. Besides
> RM,
> > other voters put effort into it too. Would you mind asking for further
> help
> > instead of downvoting a release due to local failures, please? I would
> have
> > been more than happy to assist you in a video call, instead of re-issuing
> > the whole release.
> >
> > On Tue, Sep 3, 2024 at 4:04 PM Gary D. Gregory 
> > wrote:
> >
> > > -1
> > >
> > > On Windows, I deleting my entire .m2/repository folder and then ran
> > >
> > > mvnw -Prelease clean verify artifact:compare
> > -Dreference.repo=%NEXUS_REPO%
> > >
> > > and got:
> > >
> > > [INFO] Minimal buildinfo generated from downloaded artifacts:
> > >
> >
> C:\Users\ggregory\rc\2.24.0\src\target\reference\log4j-bom-2.24.0.buildinfo
> > > [ERROR] size mismatch log4j-bom-2.24.0.pom: investigate with diffoscope
> > > target\reference\org.apache.logging.log4j\log4j-bom-2.24.0.pom
> > > .flattened-pom.xml
> > > [ERROR] size mismatch log4j-bom-2.24.0-cyclonedx.xml: investigate with
> > > diffoscope
> > >
> target\reference\org.apache.logging.log4j\log4j-bom-2.24.0-cyclonedx.xml
> > > target\bom.xml
> > > [ERROR] Reproducible Build output summary: 0 files ok, 2 different
> > > [ERROR] see diff target\reference\log4j-bom-2.24.0.buildinfo
> > > target\log4j-bom-2.24.0.buildinfo
> > > [ERROR] see also
> > > https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> > > [INFO] Reproducible Build output comparison saved to
> > > C:\Users\ggregory\rc\2.24.0\src\target\log4j-bom-2.24.0.buildcompare
> > > [INFO] Aggregate buildcompare copied to
> > > C:\Users\ggregory\rc\2.24.0\src\target\log4j-bom-2.24.0.buildcompare
> > > [INFO]
> > >
> 
> > > [INFO] Reactor Summary for Apache Log4j BOM 2.24.0:
> > > [INFO]
> > > [INFO] Apache Log4j BOM ... FAILURE
> > [02:58
> > > min]
> > > [
> > >
> > > So I give up after trying macOS, Linux, and Windows.
> > >
> > > Gary
> > >
> > > On 2024/09/03 13:23:59 "Gary D. Gregory" wrote:
> > > > Note that I add "clean" *(why does the kit not use "clean"?)
> > > >
> > > > mvnw -Prelease clean verify artifact:compare
> > -Dreference.repo=$NEXUS_REPO
> > > >
> > > > Gary
> > > >
> > > > On 2024/09/03 13:21:32 "Gary D. Gregory" wrote:
> > > > > It's fails differently on Ubuntu:
> > > > >
> > > > > ...
> > > > > [INFO] --- artifact:3.5.1:compare (default-cli) @ log4j-api ---
> > > > > [WARNING]  property is inherited
> from
> > > outside the reactor, it should be defined in parent POM from reactor
> > > /mnt/c/Users/ggregory/rc/2.24.0/src/.flattened-pom.xml
> > > > > [INFO] Reference buildinfo file not found: it will be generated
> from
> > > downloaded reference artifacts
> > > > > [INFO] Reference build java.version: 17 (from MANIFEST.MF
> > > Build-Jdk-Spec)
> > > > > [INFO] Reference build os.nam

Re: [VOTE] Release Apache Log4j `2.24.0`

[Volkan Yazıcı]

Gary, do you know what is the difference between RC1 and RC2? Nothing.
Piotr only kindly added a one-liner condition check to the contending
(FQDN-related) test to make it up to you. That is the only difference –
plus, he updated the review kit (shared in the email) to avoid the
reproducibility check on Windows. Put another way, RC1 is effectively
identical to RC2, bit by bit.

My point is, 3 people verified the release and CI runs passed on all 3
platforms – there is definitely something unexpected in your setup. As you
know better, issuing an RC is a time and energy consuming task. Besides RM,
other voters put effort into it too. Would you mind asking for further help
instead of downvoting a release due to local failures, please? I would have
been more than happy to assist you in a video call, instead of re-issuing
the whole release.

On Tue, Sep 3, 2024 at 4:04 PM Gary D. Gregory  wrote:

> -1
>
> On Windows, I deleting my entire .m2/repository folder and then ran
>
> mvnw -Prelease clean verify artifact:compare -Dreference.repo=%NEXUS_REPO%
>
> and got:
>
> [INFO] Minimal buildinfo generated from downloaded artifacts:
> C:\Users\ggregory\rc\2.24.0\src\target\reference\log4j-bom-2.24.0.buildinfo
> [ERROR] size mismatch log4j-bom-2.24.0.pom: investigate with diffoscope
> target\reference\org.apache.logging.log4j\log4j-bom-2.24.0.pom
> .flattened-pom.xml
> [ERROR] size mismatch log4j-bom-2.24.0-cyclonedx.xml: investigate with
> diffoscope
> target\reference\org.apache.logging.log4j\log4j-bom-2.24.0-cyclonedx.xml
> target\bom.xml
> [ERROR] Reproducible Build output summary: 0 files ok, 2 different
> [ERROR] see diff target\reference\log4j-bom-2.24.0.buildinfo
> target\log4j-bom-2.24.0.buildinfo
> [ERROR] see also
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> [INFO] Reproducible Build output comparison saved to
> C:\Users\ggregory\rc\2.24.0\src\target\log4j-bom-2.24.0.buildcompare
> [INFO] Aggregate buildcompare copied to
> C:\Users\ggregory\rc\2.24.0\src\target\log4j-bom-2.24.0.buildcompare
> [INFO]
> 
> [INFO] Reactor Summary for Apache Log4j BOM 2.24.0:
> [INFO]
> [INFO] Apache Log4j BOM ... FAILURE [02:58
> min]
> [
>
> So I give up after trying macOS, Linux, and Windows.
>
> Gary
>
> On 2024/09/03 13:23:59 "Gary D. Gregory" wrote:
> > Note that I add "clean" *(why does the kit not use "clean"?)
> >
> > mvnw -Prelease clean verify artifact:compare -Dreference.repo=$NEXUS_REPO
> >
> > Gary
> >
> > On 2024/09/03 13:21:32 "Gary D. Gregory" wrote:
> > > It's fails differently on Ubuntu:
> > >
> > > ...
> > > [INFO] --- artifact:3.5.1:compare (default-cli) @ log4j-api ---
> > > [WARNING]  property is inherited from
> outside the reactor, it should be defined in parent POM from reactor
> /mnt/c/Users/ggregory/rc/2.24.0/src/.flattened-pom.xml
> > > [INFO] Reference buildinfo file not found: it will be generated from
> downloaded reference artifacts
> > > [INFO] Reference build java.version: 17 (from MANIFEST.MF
> Build-Jdk-Spec)
> > > [INFO] Reference build os.name: Unix (from pom.properties newline)
> > > [INFO] Minimal buildinfo generated from downloaded artifacts:
> /mnt/c/Users/ggregory/rc/2.24.0/src/log4j-api/target/reference/log4j-api-2.24.0.buildinfo
> > > [ERROR] sha512 mismatch log4j-api-2.24.0-sources.jar: investigate with
> diffoscope
> log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.24.0-sources.jar
> log4j-api/target/log4j-api-2.24.0-sources.jar
> > > [ERROR] Reproducible Build output summary: 3 files ok, 1 different
> > > [ERROR] see diff log4j-api/target/reference/log4j-api-2.24.0.buildinfo
> log4j-api/target/log4j-api-2.24.0.buildinfo
> > > [ERROR] see also
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> > > [INFO] Reproducible Build output comparison saved to
> /mnt/c/Users/ggregory/rc/2.24.0/src/log4j-api/target/log4j-api-2.24.0.buildcompare
> > > [INFO] Aggregate buildcompare copied to
> /mnt/c/Users/ggregory/rc/2.24.0/src/target/log4j-bom-2.24.0.buildcompare
> > > [INFO]
> 
> > > [INFO] Reactor Summary for Apache Log4j BOM 2.24.0:
> > > [INFO]
> > > [INFO] Apache Log4j BOM ... SUCCESS
> [02:01 min]
> > > [INFO] Apache Log4j Parent  SUCCESS [
> 1.427 s]
> > > [INFO] Apache Log4j API Java 9 support  SUCCESS [
> 29.766 s]
> > > [INFO] Apache Log4j API ... FAILURE
> [03:13 min]
> > > [INFO] Apache Log4j Implementation Java 9 support . SKIPPED
> > > [INFO] Apache Log4j Core .. SKIPPED
> > > [INFO] Apache Log4j API Tests . SKIPPED
> > > [INFO] Apache Log4j Core Tests  SKIPPED
> > > [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> 

Re: (logging-parent) branch main updated: Modify review kit

[Volkan Yazıcı]

I will remove `clean`, since there is nothing to clean.
We shouldn't add unnecessary overhead.

On Tue, Sep 3, 2024 at 7:01 PM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Tue, 3 Sept 2024 at 18:25, Gary Gregory  wrote:
> >
> > Why doesn't the maven build in the review kit (below) invoke clean goal?
> >
> > > +sh mvnw -Prelease clean verify artifact:compare
> > > -Dreference.repo=$NEXUS_REPO
> > > +
> > > +# Run tests only (Windows)
> > > +sh mvnw -Prelease clean verify artifact:compare
> > > \ No newline at end of file
>
> Normally there is nothing to clean, but as you can see I added `clean`
> to both UNIX and Windows.
>
> Piotr
>

Re: [log4net] INFRA-managed NuGet account

[Volkan Yazıcı]

Dominik, your request is still in pending state:
[image: image.png]

Would you mind checking what is wrong, please? In case of need, could you
please reach out to Gavin in #asfinfra
<https://app.slack.com/client/T4S1WH2J3/CBX4TSBQ8>.

On Mon, Sep 2, 2024 at 8:23 PM Dominik Psenner  wrote:

> I accepted with my microsoft account tied to dpsen...@gmail.com and am
> now a collaborator (pending for approval) in the organization asf.
>
> On Mon, 2 Sept 2024, 11:51 Davyd McColl,  wrote:
>
>> I've accepted; delete the other org at your convenience.
>>
>>
>> -d
>> On 2024-09-02 11:39, Volkan Yazıcı wrote:
>>
>> I have succeeded in convincing INFRA to create a NuGet organization
>> (INFRA-25617) <https://issues.apache.org/jira/browse/INFRA-25617> that
>> we can move our .NET projects to. As a result, INFRA has created the `asf`
>> NuGet organization and added existing members of the `Apache.Logging`
>> organization to there.
>>
>> *Jan, Davyd, Dominik, you should have received an invitation to join the
>> `asf` NuGet organization. Could you accept it and respond to this mail,
>> please?* Consequently, I will remove the `Apache.Logging` organization
>> and make necessary website changes.
>>
>> For those interested, this change doesn't affect the Log4Net NuGet
>> package coordinates. Hence, no visible change from users' point of view.
>> See INFRA-25617 for the rationale and other details.
>>
>>

Re: [log4net] INFRA-managed NuGet account

[Volkan Yazıcı]

I will share it in `members@` – I was expecting INFRA to add more
administrators to the organization for high-availability purposes, which
was done 5m ago.

On Mon, Sep 2, 2024 at 9:23 PM Piotr P. Karwasz 
wrote:

> Hi,
>
> FYI, I also notified the Apache ActiveMQ developers about the `asf`
> organisation. They will migrate to it too:
> https://issues.apache.org/jira/browse/AMQNET-843
>
> Do you know any other ASF projects that use NuGet?
>
> Piotr
>

[log4net] INFRA-managed NuGet account

[Volkan Yazıcı]

I have succeeded in convincing INFRA to create a NuGet organization
(INFRA-25617)  that we
can move our .NET projects to. As a result, INFRA has created the `asf`
NuGet organization and added existing members of the `Apache.Logging`
organization to there.

*Jan, Davyd, Dominik, you should have received an invitation to join the
`asf` NuGet organization. Could you accept it and respond to this mail,
please?* Consequently, I will remove the `Apache.Logging` organization and
make necessary website changes.

For those interested, this change doesn't affect the Log4Net NuGet package
coordinates. Hence, no visible change from users' point of view. See
INFRA-25617 for the rationale and other details.

Re: [VOTE] Release Apache Log4j `2.24.0`

[Volkan Yazıcı]

+1

Verification steps pass locally.

Website-related issues are not a release blocker and can easily be fixed
thanks to our new website auto-deployment infrastructure
. As a matter
of fact, I see Piotr already has the website corrections (#2912)
 ready. Once `2.24.0`
is released, we just need to cherry-pick his PR from `2.x` to
[to-be-created-during-release] `2.x-site-pro`, and voila.

More importantly... I want to take this opportunity to thank Piotr and
Christian. 🙇 We have spent ~4 months rewriting *the entire website*
(including its technical infrastructure!) and I think the result is a big
success. 🚀 I can brag about this a lot, but I will let our users be the
judge of that.

On Sat, Aug 31, 2024 at 9:31 PM Piotr P. Karwasz 
wrote:

> This is a vote to release the Apache Log4j `2.24.0`.
>
> Website: https://logging.staged.apache.org/log4j/2.24.0/index.html
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 08053687456f6be61ee8206da782a3d051928a57
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1293
> 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/dist/dev/logging/log4j/2.24.0 &&
> 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/repositories/orgapachelogging-1293
> 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 improvements and changes in several areas of Apache
> Log4j:
>
> === Log4j API
>
> The `2.24.0` version of Log4j API has been enhanced with changes from
> the 3.x branch and will be used by both Log4j 2 Core and Log4j 3 Core
> releases.
> The changes include:
>
> * A faster default `ThreadContextMap`.
> * Enhanced GraalVM support: native binaries that use Log4j API will no
> longer require additional GraalVM configuration.
> * The configuration properties subsystem now only accepts the official
> pre-2.10 property names and the normalized post-2.10 names.
> Check your configuration for typos.
>
> === Documentation
>
> The Apache Log4j 2 website has been almost entirely rewritten to
> provide improved documentation and faster access to the information
> you need.
>
> [1] https://logging.staged.apache.org/log4j/2.24.0/index.html
>
> === Bridges
>
> The JUL-to-Log4j API and Log4j 1-to-Log4j API will no longer be able
> to modify the configuration of Log4j Core by default.
> If such a functionality is required, it must be explicitly enabled.
>
> === Modules
>
> The following Log4j Core additional modules have been removed:
>
> `log4j-flume-ng`::
> The module has been moved to the Flume project and follows the Apache
> Flume release lifecycle.
>
> `log4j-kubernetes`::
> The module has been moved to the
>
> https://github.com/fabric8io/kubernetes-client/blob/main/doc/KubernetesLog4j.md[Fabric8.io
> Kubernetes project] and follows the Fabric8.io release lifecycle.
>
> `log4j-mongodb3`::
> The module based on MongoDB Java client version 3.x has been removed.
> Please migrate to `log4j-mongodb` (client version 5.x) or
> `log4j-mongodb4` (client version 4.x).
>
> === JMX changes
>
> Starting in version 2.24.0, JMX support is disabled by default and can
> be re-enabled via the `log4j2.disableJmx=false` system property.
>
> === Added
>
> * Add a faster `DefaultThreadContextMap` implementation. (#2330)
> * Add Logback throwable-consuming semantics as an option in
> `log4j-slf4j-impl` and `log4j-slf4j2-impl`. Users can enable it by
> setting the property `log4j2.messageFactory` to
> `org.apache.logging.slf4j.message.ThrowableConsumingMessageFactory`.
> (#2363)
> * Add trace context fields to `GcpLayout.json` (#2498)
> * Add _"Plugin Reference"_ to the website. It is a Javadoc-on-steroids
> focusing on Log4j plugins. (#1954)
> * Automate webs

Re: Delaying publication of `log4j-flume-ng` in 3.x

[Volkan Yazıcı]

I support the idea of removing `log4j-flume-ng` from `main` and figuring
out a resolution later. I think it is too early to decide on how to further
proceed with `log4j-flume-ng`; moving to a separate repository, merging it
back to `main`, etc. The important thing is, we can always add it back to
`main`.

On a similar matter, I am inclined to move `log4j-flume-ng` (in `2.x`) to a
separate repository. It accounts for 10% of the build time. It is a very
stable product with a happy user base. There is no need to keep its release
cadence chained to `2.x`.

On Thu, Aug 29, 2024 at 2:12 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> The `log4j-flume-ng` module _de facto_ contains 3 different appenders:
>
> * an Avro appender, that only depends on Avro and Avro IPC. Since it
> only communicates with Flume via network, it doesn't need to even
> depend on Flume, it just needs to use the same protocol.
> * a Persistent appender, which works the same way as Avro appender,
> but stores the messages to a local database first. It has an
> additional dependency on `je` (a mostly unmaintained implementation of
> BerkeleyDB).
> * an Embedded appender, which is the only one that actually depends on
> Flume.
>
> It also contains an undocumented (and untested) `Log4jEventSource`
> plugin for Flume.
>
> The use of optional dependencies is not very JPMS friendly and we
> probably would need to split it into 3 modules. To prevent delays in
> releasing 3.0.0 I would propose to:
>
> * either move the `log4j-flume-ng` module to a separate repo and
> release version `3.0.0` together with the next Flume release.
> * or move it from the `main` branch to a different branch that will be
> merged, when the module is ready.
>
> What do you think?
>
> Piotr
>

Re: Unable to locate plugin type for Custom log4j2 Appender

[Volkan Yazıcı]

Thanks for bringing this to our attention, Piotr.

[See my comments inline below.]

On Tue, Aug 13, 2024 at 8:52 PM Piotr P. Karwasz 
wrote:

> There is no special reason why `JsonTemplateLayout` does not support
> pretty print. It was simply never implemented.
>

See my response to Amanda
, there
are good reasons for not doing it. For one, we first need to start with
answering "Why shall we do it?". If we hear a compelling use case, it is
still technically not trivial due to `JsonWriter#writeRawString()` methods.
Putting that detail aside, I am in favor of guiding users to choose the
right tool for the right job, instead of trying to make every tool cater
for all jobs.


> This could be easily generalized
> (probably in `3.x`) by replacing `JsonWriter` with an interface, to
> support multiple serialization formats. There is already a JIRA issue
> for that (see LOG4J2-3082[0]).
>

Making `JsonWriter` pluggable can indeed be a nice feature. It can even be
served in Log4j 2 without breaking backward compatibility. But it is a
pretty big undertaking. My suggestion is to implement a small enhancement
that is simpler: falling back to an external serializer (e.g., Jackson) for
unknown types. We can easily ship this in Log4j 2 and it addresses the use
case stated in LOG4J2-3082
.


> Admittedly this requires quite some work, but it is within the grasp
> of a semester-long student project or Google Summer of Code.


> If you are willing to contribute such a feature, we can always assist
> you with the Log4j-related details.
>

I am not inclined to support pretty-printing in JTL, but I would
completely support an initiative for enhancing `JsonWriter` with a fallback
serializer to address LOG4J2-3082.

Re: Unable to locate plugin type for Custom log4j2 Appender

[Volkan Yazıcı]

Hello Amanda,

See my comments inline below.

On Tue, 6 Aug 2024 at 01:05, Amanda Liu  wrote:
> The reason I want a custom appender is to pretty print the JSON log
> objects produced by JsonTemplateLayout, to make it more readable.

Would you mind giving us a little bit more context, please? Why do you need
the JSON output to be readable?

> Is there any strong reason why JsonTemplateLayout does
> not support JSON pretty print?

Yes, efficiency – both from computation and bandwidth usage perspectives.
Plus, JTL output is not intended to be consumed by humans, but machines.
The recommended practice is to contain multiple logging configurations for
different use cases. That is, while developing locally, you can choose a
layout producing a more human-readable output, e.g., Pattern Layout. At
production, you can switch to JTL. You can implement such an
environment-specific Log4j configuration either using your framework
best-practices (e.g., Spring Boot has excellent support for these kinds of
scenarios) or Log4j itself (e.g., using arbiters). To guide you on choosing
the right solution, we need to know more about your context: Which
framework do you use? How do you deploy your application? etc.

> This would resolve my issue, and I think other log4j
> JsonTemplateLayout users may be interested in the pretty print feature.

I am not keen on adding such a feature without a use case, of which we
haven't been told so far.

On Tue, Aug 13, 2024 at 8:52 PM Piotr P. Karwasz 
wrote:

> Hi Amanda,
>
> I am crossposting this to dev@logging.apache.org. Please answer to
> that mailing list.
>
> On Tue, 6 Aug 2024 at 01:05, Amanda Liu  wrote:
> > The reason I want a custom appender is to pretty print the JSON log
> objects produced by JsonTemplateLayout, to make it more readable. I see in
> the log4j docs that JSON pretty print is supported in JsonLayout, but not
> JsonTemplateLayout. I don't want to use JsonLayout, since it's deprecated
> and doesn't support some other features that JSONTemplateLayout has.
> >
> > Is there any strong reason why JsonTemplateLayout does not support JSON
> pretty print? Or could I contribute to the JsonTemplateLayout file in the
> log4j repo to add this feature? (here:
> https://github.com/apache/logging-log4j2/blob/a884e991c1a551cb321b2efed770a15fbc55aa2b/log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/JsonTemplateLayout.java).
> This would resolve my issue, and I think other log4j JsonTemplateLayout
> users may be interested in the pretty print feature.
>
> There is no special reason why `JsonTemplateLayout` does not support
> pretty print. It was simply never implemented.
>
> Currently JTL only writes to a small `JsonWriter`[1] class through
> `TemplateResolver.resolve()`[2]. This could be easily generalized
> (probably in `3.x`) by replacing `JsonWriter` with an interface, to
> support multiple serialization formats. There is already a JIRA issue
> for that (see LOG4J2-3082[0]).
>
> Admittedly this requires quite some work, but it is within the grasp
> of a semester-long student project or Google Summer of Code.
>
> If you are willing to contribute such a feature, we can always assist
> you with the Log4j-related details.
>
> Piotr
>
> BTW: I added more info about shading applications that use Log4j Core
> to our documentation[3]
>
> [0] https://issues.apache.org/jira/browse/LOG4J2-3082
> [1]
> https://javadoc.io/static/org.apache.logging.log4j/log4j-layout-template-json/2.19.0/org/apache/logging/log4j/layout/template/json/util/JsonWriter.html
> [2]
> https://javadoc.io/static/org.apache.logging.log4j/log4j-layout-template-json/2.19.0/org/apache/logging/log4j/layout/template/json/resolver/TemplateResolver.html#resolve-V-org.apache.logging.log4j.layout.template.json.util.JsonWriter-
> [3]
> https://github.com/apache/logging-log4j2/blob/2.x/src/site/antora/modules/ROOT/pages/faq.adoc#how-do-i-create-a-single-jar-application-containing-log4j-core
>

[ANNOUNCE] Apache Log4j Kotlin API `1.5.0` released

[Volkan Yazıcı]

Apache Log4j Kotlin API team is pleased to announce the `1.5.0`
release. This project contains a Kotlin-friendly interface to log
against the Log4j API. For further information (support, download,
etc.) see the project website[1].

[1] https://logging.apache.org/log4j/kotlin

== Release Notes

This release contains improvements to Kotlin coroutine integration.

=== Added

* Add convenience functions for managing logging context in coroutines (#65)

=== Changed

* Migrate website to Antora (apache/logging-log4j2#2443)

=== Updated

* Update `org.apache.logging.log4j:log4j-bom` to version `2.23.1` (#70)

Re: [VOTE] Release Apache Log4j Kotlin API `1.5.0` RC1

[Volkan Yazıcı]

Adding my +1.

With that, the release passes with 3 binding +1 votes from Piotr,
Christian, and me. I will continue the release process.


On Sat, Aug 3, 2024 at 7:23 PM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j Kotlin API `1.5.0`.
>
> Website: https://logging.staged.apache.org/log4j/kotlin-1.5.0
> GitHub: https://github.com/apache/logging-log4j-kotlin
> Commit: 57bc699b9e91a94a7df279f226e4f0ae86769062
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1290
> 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/dist/dev/logging/log4j-kotlin && 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/repositories/orgapachelogging-1290
> 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 improvements to Kotlin coroutine integration.
>
> === Added
>
> * Add convenience functions for managing logging context in coroutines (#65)
>
> === Changed
>
> * Migrate website to Antora (apache/logging-log4j2#2443)
>
> === Updated
>
> * Update `org.apache.logging.log4j:log4j-bom` to version `2.23.1` (#70)

[VOTE] Release Apache Log4j Kotlin API `1.5.0` RC1

[Volkan Yazıcı]

This is a vote to release the Apache Log4j Kotlin API `1.5.0`.

Website: https://logging.staged.apache.org/log4j/kotlin-1.5.0
GitHub: https://github.com/apache/logging-log4j-kotlin
Commit: 57bc699b9e91a94a7df279f226e4f0ae86769062
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin
Nexus:
https://repository.apache.org/content/repositories/orgapachelogging-1290
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/dist/dev/logging/log4j-kotlin &&
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/repositories/orgapachelogging-1290
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 improvements to Kotlin coroutine integration.

=== Added

* Add convenience functions for managing logging context in coroutines (#65)

=== Changed

* Migrate website to Antora (apache/logging-log4j2#2443)

=== Updated

* Update `org.apache.logging.log4j:log4j-bom` to version `2.23.1` (#70)

[ANNOUNCE] Apache Logging Parent `11.1.0` released

[Volkan Yazıcı]

Apache Logging Parent team is pleased to announce the `11.1.0`
release. This project contains the parent POM for other Maven-based
Apache Logging Services projects. For further information (support,
download, etc.) see the project website[1].

[1] https://logging.apache.org/logging-parent

== Release Notes

This minor release contains small improvements and some dependency updates.

=== Changed

* Use default Java SE architecture and packaging (JDK) in workflows
* Change the JDK distribution used in workflows from Temurin to Zulu (#169)

=== Updated

* Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.5` (#174)
* Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.8.5.0` (#175)
* Update `com.google.errorprone:error_prone_core` to version `2.27.1` (#172)
* Update `com.h3xstream.findsecbugs:findsecbugs-plugin` to version
`1.13.0` (#159)
* Update `com.palantir.javaformat:palantir-java-format` to version
`2.46.0` (#173)
* Update `org.apache:apache` to version `32` (#160)
* Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
version `0.9.0` (#181)

Re: [VOTE][LAZY] Release Apache Logging Parent `11.1.0` (RC1)

[Volkan Yazıcı]

Given no objections, I will continue the release process.

On Wed, May 15, 2024 at 3:17 PM Volkan Yazıcı  wrote:
>
> This is a lazy-vote to release the Apache Logging Parent `11.1.0` (RC1).
>
> Website: https://logging.staged.apache.org/logging-parent-11.1.0
> GitHub: https://github.com/apache/logging-parent
> Commit: 97716b99d78b9ff226f70a8fb9a8b93860acbf29
> Distribution: 
> https://dist.apache.org/repos/dist/dev/logging/logging-parent/11.1.0
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1287
> 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/dist/dev/logging/logging-parent/11.1.0 
> logging-parent-11.1.0  && 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/repositories/orgapachelogging-1287
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> == Release notes
>
> This minor release contains small improvements and some dependency updates.
>
> === Changed
>
> * Change the JDK distribution used in CI from Temurin to Zulu (#169)
> * Use default Java SE architecture and packaging (JDK) in workflows
>
> === Updated
>
> * Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.5` (#174)
> * Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.8.5.0` 
> (#175)
> * Update `com.google.errorprone:error_prone_core` to version `2.27.1` (#172)
> * Update `com.h3xstream.findsecbugs:findsecbugs-plugin` to version `1.13.0` 
> (#159)
> * Update `com.palantir.javaformat:palantir-java-format` to version `2.46.0` 
> (#173)
> * Update `org.apache:apache` to version `32` (#160)
> * Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to version 
> `0.9.0` (#181)

[VOTE][LAZY] Release Apache Logging Parent `11.1.0` (RC1)

[Volkan Yazıcı]

This is a lazy-vote to release the Apache Logging Parent `11.1.0` (RC1).

Website: https://logging.staged.apache.org/logging-parent-11.1.0
GitHub: https://github.com/apache/logging-parent
Commit: 97716b99d78b9ff226f70a8fb9a8b93860acbf29
Distribution:
https://dist.apache.org/repos/dist/dev/logging/logging-parent/11.1.0
Nexus:
https://repository.apache.org/content/repositories/orgapachelogging-1287
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/dist/dev/logging/logging-parent/11.1.0
logging-parent-11.1.0  && 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/repositories/orgapachelogging-1287
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
# If preferred, augment `mvnw` with `-DskipTests` to speed things up

== Release notes

This minor release contains small improvements and some dependency updates.

=== Changed

* Change the JDK distribution used in CI from Temurin to Zulu (#169)
* Use default Java SE architecture and packaging (JDK) in workflows

=== Updated

* Update `com.github.spotbugs:spotbugs-annotations` to version `4.8.5`
(#174)
* Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.8.5.0`
(#175)
* Update `com.google.errorprone:error_prone_core` to version `2.27.1` (#172)
* Update `com.h3xstream.findsecbugs:findsecbugs-plugin` to version `1.13.0`
(#159)
* Update `com.palantir.javaformat:palantir-java-format` to version `2.46.0`
(#173)
* Update `org.apache:apache` to version `32` (#160)
* Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to version
`0.9.0` (#181)

[ANNOUNCE] Apache Log4j Tools `0.9.0` released

[Volkan Yazıcı]

Apache Log4j Tools team is pleased to announce the `0.9.0`
release. This project provides tooling internally used by the
Apache Log4j project. For further information (support, download,
etc.) see the project website[1].

[1] https://logging.apache.org/log4j/tools

== Release Notes

This minor release contains small bug fixes and improvements.

=== Added

* Add `skip` parameter to all Maven goals (#121)
* Support multiple index and type templates in the
`log4j-docgen:generate-documentation` configuration (#122)
* Add support for the `@PluginValue` annotation. (#123)

=== Changed

* Website is migrated to Antora (apache/logging-log4j2#2443)

=== Fixed

* Fix handling of subclassed plugins in Log4j Docgen (#120)

=== Updated

* Update `commons-io:commons-io` to version `2.16.1` (#114)
* Update `org.apache.logging:logging-parent` to version `11.0.0` (#115)
* Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to
version `3.13.0` (#118)
* Update `org.codehaus.modello:modello-maven-plugin` to version `2.4.0` (#119)
* Update `org.xmlunit:xmlunit-assertj3` to version `2.10.0` (#116)

Re: [VOTE] Release Apache Log4j Tools `0.9.0` RC2

[Volkan Yazıcı]

Adding my +1.

With that, the release passes with 3 binding +1 votes from Gary,
Piotr, and me. I will continue the release process.

On Thu, May 9, 2024 at 2:40 PM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j Tools `0.9.0` RC2.
>
> Website: https://logging.staged.apache.org/log4j/tools-0.9.0
> GitHub: https://github.com/apache/logging-log4j-tools
> Commit: 485e1823cd6f8ae581071e938608db21126a7af5
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1285
> 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 48 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/dist/dev/logging/log4j-tools/0.9.0
> && 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/repositories/orgapachelogging-1285
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> == Addendum
>
> Note that the vote period is 48 hours – 24 hours have already passed
> since RC1 vote and there is only a single new commit added, see issue
> #123.
>
> == Release notes
>
> This minor release contains small bug fixes and improvements.
>
> === Added
>
> * Add `skip` parameter to all Maven goals (#121)
> * Support multiple index and type templates in the
> `log4j-docgen:generate-documentation` configuration (#122)
> * Add support for the `@PluginValue` annotation (#123)
>
> === Changed
>
> * Website is migrated to Antora (apache/logging-log4j2#2443)
>
> === Fixed
>
> * Fix handling of subclassed plugins in Log4j Docgen (#120)
>
> === Updated
>
> * Update `commons-io:commons-io` to version `2.16.1` (#114)
> * Update `org.apache.logging:logging-parent` to version `11.0.0` (#115)
> * Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to
> version `3.13.0` (#118)
> * Update `org.codehaus.modello:modello-maven-plugin` to version `2.4.0` (#119)
> * Update `org.xmlunit:xmlunit-assertj3` to version `2.10.0` (#116)

[VOTE] Release Apache Log4j Tools `0.9.0` RC2

[Volkan Yazıcı]

This is a vote to release the Apache Log4j Tools `0.9.0` RC2.

Website: https://logging.staged.apache.org/log4j/tools-0.9.0
GitHub: https://github.com/apache/logging-log4j-tools
Commit: 485e1823cd6f8ae581071e938608db21126a7af5
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1285
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 48 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/dist/dev/logging/log4j-tools/0.9.0
&& 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/repositories/orgapachelogging-1285
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
# If preferred, augment `mvnw` with `-DskipTests` to speed things up

== Addendum

Note that the vote period is 48 hours – 24 hours have already passed
since RC1 vote and there is only a single new commit added, see issue
#123.

== Release notes

This minor release contains small bug fixes and improvements.

=== Added

* Add `skip` parameter to all Maven goals (#121)
* Support multiple index and type templates in the
`log4j-docgen:generate-documentation` configuration (#122)
* Add support for the `@PluginValue` annotation (#123)

=== Changed

* Website is migrated to Antora (apache/logging-log4j2#2443)

=== Fixed

* Fix handling of subclassed plugins in Log4j Docgen (#120)

=== Updated

* Update `commons-io:commons-io` to version `2.16.1` (#114)
* Update `org.apache.logging:logging-parent` to version `11.0.0` (#115)
* Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to
version `3.13.0` (#118)
* Update `org.codehaus.modello:modello-maven-plugin` to version `2.4.0` (#119)
* Update `org.xmlunit:xmlunit-assertj3` to version `2.10.0` (#116)

Re: [VOTE] Release Apache Log4j Tools `0.9.0`

[Volkan Yazıcı]

I cancel this vote.
We encountered another bug and fixed it right away
<https://github.com/apache/logging-log4j-tools/pull/123>.
I will issue an RC2 vote promptly.


On Wed, May 8, 2024 at 4:36 PM Volkan Yazıcı  wrote:

> This is a vote to release the Apache Log4j Tools `0.9.0`.
>
> Website: https://logging.staged.apache.org/log4j/tools-0.9.0
> GitHub: https://github.com/apache/logging-log4j-tools
> Commit: 9d822d3a7daa5e1e6a953b66ff12e4b87b99ef7e
> Distribution:
> https://dist.apache.org/repos/dist/dev/logging/log4j-tools/0.9.0
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1284
> 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/dist/dev/logging/log4j-tools/0.9.0
> && <https://dist.apache.org/repos/dist/dev/logging/log4j-tools/0.9.0&&;>
> 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/repositories/orgapachelogging-1284
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> == Release notes
>
> This minor release contains small bug fixes and improvements.
>
> === Added
>
> * Add `skip` parameter to all Maven goals (#121)
> * Support multiple index and type templates in the
> `log4j-docgen:generate-documentation` configuration (#122)
>
> === Changed
>
> * Website is migrated to Antora (apache/logging-log4j2#2443)
>
> === Fixed
>
> * Fix handling of subclassed plugins in Log4j Docgen (#120)
>
> === Updated
>
> * Update `commons-io:commons-io` to version `2.16.1` (#114)
> * Update `org.apache.logging:logging-parent` to version `11.0.0` (#115)
> * Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to
> version `3.13.0` (#118)
> * Update `org.codehaus.modello:modello-maven-plugin` to version `2.4.0`
> (#119)
> * Update `org.xmlunit:xmlunit-assertj3` to version `2.10.0` (#116)
>

[VOTE] Release Apache Log4j Tools `0.9.0`

[Volkan Yazıcı]

This is a vote to release the Apache Log4j Tools `0.9.0`.

Website: https://logging.staged.apache.org/log4j/tools-0.9.0
GitHub: https://github.com/apache/logging-log4j-tools
Commit: 9d822d3a7daa5e1e6a953b66ff12e4b87b99ef7e
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools/0.9.0
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1284
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/dist/dev/logging/log4j-tools/0.9.0
&& 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/repositories/orgapachelogging-1284
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
# If preferred, augment `mvnw` with `-DskipTests` to speed things up

== Release notes

This minor release contains small bug fixes and improvements.

=== Added

* Add `skip` parameter to all Maven goals (#121)
* Support multiple index and type templates in the
`log4j-docgen:generate-documentation` configuration (#122)

=== Changed

* Website is migrated to Antora (apache/logging-log4j2#2443)

=== Fixed

* Fix handling of subclassed plugins in Log4j Docgen (#120)

=== Updated

* Update `commons-io:commons-io` to version `2.16.1` (#114)
* Update `org.apache.logging:logging-parent` to version `11.0.0` (#115)
* Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to
version `3.13.0` (#118)
* Update `org.codehaus.modello:modello-maven-plugin` to version `2.4.0` (#119)
* Update `org.xmlunit:xmlunit-assertj3` to version `2.10.0` (#116)

Re: Canonicalization of URLs on our website

[Volkan Yazıcı]

All non-default `html_extension_style` options require to run a web server.

In my opinion,

   - Being able to view `target/site` with just using my browser and
   nothing else is super convenient. The development experience is much
   smoother.
   - None of the advantages you cited for switching from `/foo.html` to
   `/foo`, `/foo/index.html`, etc. is worth the trouble/complexity it will
   introduce.

In short, I am not inclined to change the current path naming scheme. That
said, I don't want to sound bossy. I would appreciate it if others can join
the discussion with their arguments.

On Wed, May 8, 2024 at 10:22 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> On Sun, 21 Apr 2024 at 20:19, Volkan Yazıcı  wrote:
> >1. Could you show us the Antora configuration option you mentioned
> >and how we can use it to achieve what you propose?
>
> I found the perfect Antora setting: `html_extension_style`[1].
>
> The option I am proposing corresponds to the `drop` style:
>
> * a `/foo/bar.html` file will be referenced as `foo/bar`,
> * a `/foo/index.html` file will be referenced as `foo/`.
>
> The `indexify` style is very similar, but it always uses a trailing
> `/` for the file names.
>
> I see both pros and cons for the two styles:
>
> ## `indexify` style
>
> Pros:
> * Doesn't make a difference between "normal" HTML files and folders.
> If we transform `foo.html` into `foo/index.html` and add subpages, the
> URL remains always `foo/`.
> * We restore the old URLs like `/log4j/2.x/log4j-api/` that became
> `/log4j/2.x/log4j-api.html`.
> * Works on every HTTP server (even Python's).
>
> Cons:
> * We need a lot of HTTP redirects like
> `/log4j/2.x/manual/configuration.html` ->
> `/log4j/2.x/manual/configuration/`
>
> ## `drop` style
>
> Pros:
> * We don't need redirects for the current pages, only a global rewrite
> rule that states that we prefer to omit the `.html` suffix.
> * It is shorter than the `indexify` style.
> * It is easier to implement on already compiled pages: no need to
> move/rename files.
>
> Cons:
> * If `foo.html` becomes `foo/index.html` the canonical URL changes
> from `foo` to `foo/`. However the redirect from the old to the new URL
> is done automatically by most servers.
> * It doesn't work with all web servers, but it works with Apache HTTP
> Server.
>
> What do you think about adopting the `drop` style?
>
> Piotr
>
> PS: Javadoc also can use the `drop` style. See e.g. Jakarta drops the
> `.html` (and apparently capital letters) from its Javadoc.
>
> [1]
> https://docs.antora.org/antora/latest/playbook/urls-html-extension-style/
> [2]
> https://jakarta.ee/specifications/servlet/6.0/apidocs/jakarta.servlet/jakarta/servlet/filter
>

[log4cxx] Board report entry

[Volkan Yazıcı]

Can a Log4cxx maintainer share what is getting cooked since March 20,
please? A short summary of 3-4 sentences would suffice. See the past reports
 for
inspiration.

Re: Closing inactive issues

[Volkan Yazıcı]

Even though it is unfortunate, I can understand where you are coming from
and I agree with you. Such forsaken tickets even started piling up in
GitHub Issues too. We should indeed trim them as we see fit. After all,
nothing is lost, everything is archived. Users can re-open old tickets if
needed.

On Wed, Apr 24, 2024 at 3:20 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> We have currently almost 1000 issues for the Log4j project alone.
>
> Let us be honest, most of these issues will **never** be solved, we
> barely have time for the issues reported against the current Log4j
> version.
>
> What do you think about automatically closing as "Won't Fix" or
> "Abandoned" the issues without any activity in the last 2 years[1]?
> The issues will not disappear from JIRA, but we will no longer spend
> time on them (we don't look at them anyway).
>
> Piotr
>
> [1]
> https://issues.apache.org/jira/browse/LOG4J2-3079?filter=-4&jql=project%20%3D%20LOG4J2%20AND%20resolution%20%3D%20Unresolved%20AND%20updated%20%3C%3D%20-104w
>

Re: Canonicalization of URLs on our website

[Volkan Yazıcı]

I have a couple of questions Piotr:

   1. Could you show us the Antora configuration option you mentioned
   and how we can use it to achieve what you propose?
   2. Are you suggesting that all `foo.html` pages should be converted to
   `foo/`?


On Sat, Apr 20, 2024 at 10: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
>

[ANNOUNCE] Apache Logging Parent `11.0.0` released

[Volkan Yazıcı]

Apache Logging Parent team is pleased to announce the `11.0.0`
release. This project contains the parent POM for other Maven-based
Apache Logging Services projects. For further information (support,
download, etc.) see the project website[1].

[1] https://logging.apache.org/logging-parent

== Release notes

This release contains a big revamp to the website build and several other
minor enhancements.

=== Website build changes

The website build system is migrated from `asciidoctor-maven-plugin` to
Antora. This implies that `src/site` and `generate-email.sh` files need to
be adapted, and `target/site` can be viewed without needing a local web
server.

The Maven `site` phase is re-engineered such that _generated sources_
(i.e., `src/site/_release_notes` and `src/site/_constants.adoc`) will be
targeted to `target/generated-site` and the website will be built from
there. This avoids the need to commit generated sources to the repository
and, hence, works around changelog merge conflict problems.

=== Website deployment changes

The newly added `site-deploy-reusable.yaml` GitHub Actions workflow enables
to automate the website deployment. Using the
`-site--out` branch naming convention, the
Maven `site` goal running on

* the `main` branch populates the `main-site-stg-out` branch serving the `
logging.staged.apache.org/logging-parent`
* the `main-site-pro` branch populates the `main-site-pro-out` branch
serving the `logging.apache.org/logging-parent`
* the `release/` branch populates the
`release/-site-stg-out` branch serving the `
logging.staged.apache.org/logging-parent-`

Refer to the usage and project release instructions pages for details.

=== Added

* Add `coverage` profile to generate a test coverage report (#140)
* Add `deploy-site-yaml` GitHub actions workflow to automate the website
deployment
* Add instructions on XML schema publication (#138)

=== Changed

* Replace `process-sbom` script with CycloneDX plugin configuration (#105)
* Support parallel releases by uploading the distribution to
`/` folders. This is needed for parallel Log4j 2 and 3
releases. (#139)
* Migrate website support from `asciidoctor-maven-plugin` to Antora

=== Updated

* Update `com.diffplug.spotless:spotless-maven-plugin` to version `2.43.0`
(#108)
* Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.8.4.0`
(#156)
* Update `com.google.errorprone:error_prone_core` to version `2.26.1` (#134)
* Update `com.palantir.javaformat:palantir-java-format` to version `2.43.0`
(#154)
* Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to version
`0.8.0` (#146)
* Update `org.apache.maven.plugins:maven-artifact-plugin` to version
`3.5.1` (#149)
* Update `org.codehaus.mojo:flatten-maven-plugin` to version `1.6.0` (#102)
* Update `org.cyclonedx:cyclonedx-maven-plugin` to version `2.8.0` (#145)

Re: [VOTE][LAZY] Release Apache Logging Parent `11.0.0`

[Volkan Yazıcı]

Adding my +1.

With that, the release passes with 1 binding +1 vote from me. I will
continue the release process.

On Mon, Apr 15, 2024 at 1:11 PM Volkan Yazıcı  wrote:

> This is a lazy-vote to release the Apache Logging Parent `11.0.0`.
>
> Website: https://logging.staged.apache.org/logging-parent-11.0.0
> GitHub: https://github.com/apache/logging-parent
> Commit: b5bbe45c0c3536e3b6532e176e038a166310df16
> Distribution:
> https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1281
> 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/dist/dev/logging/logging-parent/11.0.0 &&
> 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/repositories/orgapachelogging-1281
> sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
> # If preferred, augment `mvnw` with `-DskipTests` to speed things up
>
> If you have code-related objections, *DO NOT* share them by responding to
> this email, but start a new email thread instead, please.
>
> == Release notes
>
> This release contains a big revamp to the website build and several other
> minor enhancements.
>
> === Website build changes
>
> The website build system is migrated from `asciidoctor-maven-plugin` to
> Antora. This implies that `src/site` and `generate-email.sh` files need to
> be adapted, and `target/site` can be viewed without needing a local web
> server.
>
> The Maven `site` phase is re-engineered such that _generated sources_
> (i.e., `src/site/_release_notes` and `src/site/_constants.adoc`) will be
> targeted to `target/generated-site` and the website will be built from
> there. This avoids the need to commit generated sources to the repository
> and, hence, works around changelog merge conflict problems.
>
> === Website deployment changes
>
> The newly added `site-deploy-reusable.yaml` GitHub Actions workflow
> enables to automate the website deployment. Using the
> `-site--out` branch naming convention, the
> Maven `site` goal running on
>
> * the `main` branch populates the `main-site-stg-out` branch serving the `
> logging.staged.apache.org/logging-parent`
> <http://logging.staged.apache.org/logging-parent>
> * the `main-site-pro` branch populates the `main-site-pro-out` branch
> serving the `logging.apache.org/logging-parent`
> <http://logging.apache.org/logging-parent>
> * the `release/` branch populates the
> `release/-site-stg-out` branch serving the `
> logging.staged.apache.org/logging-parent-`
>
> Refer to the usage and project release instructions pages for details.
>
> === Added
>
> * Add `coverage` profile to generate a test coverage report (#140)
> * Add `deploy-site-yaml` GitHub actions workflow to automate the website
> deployment
> * Add instructions on XML schema publication (#138)
>
> === Changed
>
> * Replace `process-sbom` script with CycloneDX plugin configuration (#105)
> * Support parallel releases by uploading the distribution to
> `/` folders. This is needed for parallel Log4j 2 and 3
> releases. (#139)
> * Migrate website support from `asciidoctor-maven-plugin` to Antora
>
> === Updated
>
> * Update `com.diffplug.spotless:spotless-maven-plugin` to version `2.43.0`
> (#108)
> * Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.8.4.0`
> (#156)
> * Update `com.google.errorprone:error_prone_core` to version `2.26.1`
> (#134)
> * Update `com.palantir.javaformat:palantir-java-format` to version
> `2.43.0` (#154)
> * Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to
> version `0.8.0` (#146)
> * Update `org.apache.maven.plugins:maven-artifact-plugin` to version
> `3.5.1` (#149)
> * Update `org.codehaus.mojo:flatten-maven-plugin` to version `1.6.0` (#102)
> * Update `org.cyclonedx:cyclonedx-maven-plugin` to version `2.8.0` (#145)
>

[VOTE][LAZY] Release Apache Logging Parent `11.0.0`

[Volkan Yazıcı]

This is a lazy-vote to release the Apache Logging Parent `11.0.0`.

Website: https://logging.staged.apache.org/logging-parent-11.0.0
GitHub: https://github.com/apache/logging-parent
Commit: b5bbe45c0c3536e3b6532e176e038a166310df16
Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
Nexus:
https://repository.apache.org/content/repositories/orgapachelogging-1281
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/dist/dev/logging/logging-parent/11.0.0 && 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/repositories/orgapachelogging-1281
sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO
# If preferred, augment `mvnw` with `-DskipTests` to speed things up

If you have code-related objections, *DO NOT* share them by responding to
this email, but start a new email thread instead, please.

== Release notes

This release contains a big revamp to the website build and several other
minor enhancements.

=== Website build changes

The website build system is migrated from `asciidoctor-maven-plugin` to
Antora. This implies that `src/site` and `generate-email.sh` files need to
be adapted, and `target/site` can be viewed without needing a local web
server.

The Maven `site` phase is re-engineered such that _generated sources_
(i.e., `src/site/_release_notes` and `src/site/_constants.adoc`) will be
targeted to `target/generated-site` and the website will be built from
there. This avoids the need to commit generated sources to the repository
and, hence, works around changelog merge conflict problems.

=== Website deployment changes

The newly added `site-deploy-reusable.yaml` GitHub Actions workflow enables
to automate the website deployment. Using the
`-site--out` branch naming convention, the
Maven `site` goal running on

* the `main` branch populates the `main-site-stg-out` branch serving the `
logging.staged.apache.org/logging-parent`
* the `main-site-pro` branch populates the `main-site-pro-out` branch
serving the `logging.apache.org/logging-parent`
* the `release/` branch populates the
`release/-site-stg-out` branch serving the `
logging.staged.apache.org/logging-parent-`

Refer to the usage and project release instructions pages for details.

=== Added

* Add `coverage` profile to generate a test coverage report (#140)
* Add `deploy-site-yaml` GitHub actions workflow to automate the website
deployment
* Add instructions on XML schema publication (#138)

=== Changed

* Replace `process-sbom` script with CycloneDX plugin configuration (#105)
* Support parallel releases by uploading the distribution to
`/` folders. This is needed for parallel Log4j 2 and 3
releases. (#139)
* Migrate website support from `asciidoctor-maven-plugin` to Antora

=== Updated

* Update `com.diffplug.spotless:spotless-maven-plugin` to version `2.43.0`
(#108)
* Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.8.4.0`
(#156)
* Update `com.google.errorprone:error_prone_core` to version `2.26.1` (#134)
* Update `com.palantir.javaformat:palantir-java-format` to version `2.43.0`
(#154)
* Update `org.apache.logging.log4j:log4j-changelog-maven-plugin` to version
`0.8.0` (#146)
* Update `org.apache.maven.plugins:maven-artifact-plugin` to version
`3.5.1` (#149)
* Update `org.codehaus.mojo:flatten-maven-plugin` to version `1.6.0` (#102)
* Update `org.cyclonedx:cyclonedx-maven-plugin` to version `2.8.0` (#145)

Re: Monitoring discards from async logging

[Volkan Yazıcı]

*Short answer:* I would suggest using reflection for the time being. We
don't anticipate any changes in that part of the code base in the
foreseeable future.

*Slightly longer answer:* Log4j has never had a holistic observability view
to its internals. We need something new (if not, from scratch), and
preferably, applicable to not only async. logging, but all components
wherever this can be needed. This is time consuming hard work.
Piotr and I, sort of, the only active Log4j maintainers nowadays, are
swamped with other priorities. All that said, you can contract a maintainer
<https://logging.apache.org/log4j/2.x/support.html#commercial> to get this
rolling.

On Thu, Apr 11, 2024 at 6:36 PM Thomas, Adam 
wrote:

> Volkan,
>
> Not frustrating at all, I'm coming into this without any real experience
> with how log4j approaches API design.
>
> > Thinking naively: Assuming you already thought about it, why doesn't the
> following work for you?
> > 1. Cast the `LoggerContext` to `AsyncLoggerContext`
> > 2. Reflectively extract the `AsyncLoggerContext#loggerDisruptor`
> > 3. Reflectively extract the `AsyncLoggerDisruptor#asyncQueueFullPolicy`
> > 4. Call `DiscardingAsyncQueueFullPolicy.getDiscardCount()` on the policy
> instance
>
> It's something we considered a last resort. I'm always hesitant to couple
> to a non-public API (such as reflecting into private fields), and doubly so
> when it is code I do not control.
>
> -Adam
>
>
> From: Volkan Yazıcı 
> Date: Thursday, April 11, 2024 at 4:09 AM
> To: Adam Thomas 
> Cc: "dev@logging.apache.org" 
> Subject: RE: Monitoring discards from async logging
>
>
> Hello Adam,
>
> I am very sorry for the frustrating experience. I can certainly see you do
> an excellent job in getting engaged with the project to get this feature
> request rolling. Thank you so much for that.
>
> I read your conversation with Piotr and I get your point – yes, neither
> migration to Log4j 3 (which still has an unknown release date), nor
> augmenting the configuration is an option for you. I agree with your
> assessments there.
>
> Thinking naively: Assuming you already thought about it, why doesn't the
> following work for you?
> 1. Cast the `LoggerContext` to `AsyncLoggerContext`
> 2. Reflectively extract the `AsyncLoggerContext#loggerDisruptor`
> 3. Reflectively extract the `AsyncLoggerDisruptor#asyncQueueFullPolicy`
> 4. Call `DiscardingAsyncQueueFullPolicy.getDiscardCount()` on the policy
> instance
> Kind regards.
>
> On Wed, Apr 10, 2024 at 12:11 AM Thomas, Adam 
> wrote:
> I created a pull request[1] late last year for this, and was encouraged to
> start a discussion on the dev list at the time.
>
> We run log4j2 on a lot of hosts that are operated by different teams. By
> default, our users use async logging and use the Discard
> asyncQueueFullPolicy. As far as I can tell, the status logger gets one WARN
> message the first time an event is discarded, and during shutdown a TRACE
> message is emitted if any discards happened. This leaves us with
> essentially no insight as to whether or not events are actually being
> discarded, when they are being discarded, or how many we are discarding.
>
> My pull request is pretty simple; the discarding policy already tracks
> discards, and I expose a getter for this counter from
> LoggerContext/AsyncLoggerContext. Polling the counter and pushing It to our
> telemetry system is an exercise left up to the user (me). I don’t have any
> real concerns about the safety of the change, but I have no idea how
> acceptable it is as a change to the API surface.
>
> This also spawned a metrics proof-of-concept that was recently closed [2].
> I’m fine with a more complete metrics solution, but I’m not sure of the
> timeline of such a solution, if any.
>
> How can I move forward on this pull request to make it acceptable, or is
> there another way to accomplish this that would be more palatable?
>
> -Adam
>
> [1] https://github.com/apache/logging-log4j2/pull/1927
> [2] https://github.com/apache/logging-log4j2/pull/1943
>
>

Re: Monitoring discards from async logging

[Volkan Yazıcı]

Hello Adam,

I am very sorry for the frustrating experience. I can certainly see you do
an excellent job in getting engaged with the project to get this feature
request rolling. Thank you so much for that.

I read your conversation with Piotr and I get your point – yes, neither
migration to Log4j 3 (which still has an unknown release date), nor
augmenting the configuration is an option for you. I agree with your
assessments there.

Thinking naively: Assuming you already thought about it, why doesn't the
following work for you?

   1. Cast the `LoggerContext` to `AsyncLoggerContext`
   2. Reflectively extract the `AsyncLoggerContext#loggerDisruptor`
   3. Reflectively extract the `AsyncLoggerDisruptor#asyncQueueFullPolicy`
   4. Call `DiscardingAsyncQueueFullPolicy.getDiscardCount()` on the policy
   instance

Kind regards.

On Wed, Apr 10, 2024 at 12:11 AM Thomas, Adam 
wrote:

> I created a pull request[1] late last year for this, and was encouraged to
> start a discussion on the dev list at the time.
>
> We run log4j2 on a lot of hosts that are operated by different teams. By
> default, our users use async logging and use the Discard
> asyncQueueFullPolicy. As far as I can tell, the status logger gets one WARN
> message the first time an event is discarded, and during shutdown a TRACE
> message is emitted if any discards happened. This leaves us with
> essentially no insight as to whether or not events are actually being
> discarded, when they are being discarded, or how many we are discarding.
>
> My pull request is pretty simple; the discarding policy already tracks
> discards, and I expose a getter for this counter from
> LoggerContext/AsyncLoggerContext. Polling the counter and pushing It to our
> telemetry system is an exercise left up to the user (me). I don’t have any
> real concerns about the safety of the change, but I have no idea how
> acceptable it is as a change to the API surface.
>
> This also spawned a metrics proof-of-concept that was recently closed [2].
> I’m fine with a more complete metrics solution, but I’m not sure of the
> timeline of such a solution, if any.
>
> How can I move forward on this pull request to make it acceptable, or is
> there another way to accomplish this that would be more palatable?
>
> -Adam
>
> [1] https://github.com/apache/logging-log4j2/pull/1927
> [2] https://github.com/apache/logging-log4j2/pull/1943
>

Re: End-of-life date for `log4j-1.2-api`

[Volkan Yazıcı]

Agreed with Ralph.
I second the idea of dropping `log4j-1.2-api` from `3.0.0`.

On Mon, Apr 8, 2024 at 1:11 PM Apache  wrote:

> My opinion is to drop it from 3.0.0. 2.x is going to live a long time
> still. By the time it dies Log4J 1.x will have been dead well over 15
> years, maybe even 20. That would give users plenty of time to be aware that
> they need to plan to upgrade.
>
> Ralph
>
> > On Apr 8, 2024, at 3:35 AM, Piotr P. Karwasz 
> wrote:
> >
> > Hi all,
> >
> > As you are probably aware, `log4j-1.2-api` is the second largest
> > artifact we maintain. Yes, it is slightly larger than `log4j-api` and
> > twice the size of JTL.
> >
> > This library is mainly used:
> >
> > 1. By some older frameworks/libraries that want to "help" users in
> > their logging configuration. The amount of code that depends on
> > `log4j-1.2-api` is usually measured in a dozen LoCs.
> > 2. By some very old libraries that directly use Log4j 1.x for logging.
> > I know a thing or two about Java archeology, but I couldn't give you a
> > single example of such a library. The old legacy libraries I know
> > mostly use JCL as a logging interface.
> >
> > Therefore I am wondering what should we do with this library in the
> > upcoming 3.0.0 release:
> >
> > * should we drop it? The baseline of 3.0.0 is Java 17. Are there
> > really applications that use Java 17 and at the same time use
> > libraries that directly log to Log4j 1.x?
> > * should we drop most of the code and move the two Log4j 1.x
> > configuration factories to a new module?
> > * should we just set an end-of-life date for the artifact and include
> > it as it in Log4j 3.0.0?
> >
> > Piotr
> >
> > [1] https://github.com/apache/logging-log4j2/issues/2395
>
>

[ANNOUNCE] Apache Log4j Tools 0.8.0 released

[Volkan Yazıcı]

Apache Log4j Tools team is pleased to announce the 0.8.0 release. This
project provides tooling internally used by the Apache Log4j project.
For further information (support, download,
etc.) see the project website[1].

[1] https://logging.apache.org/log4j/tools

=== Release Notes

This 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)

[RESULT][VOTE] Release Apache Log4j Tools 0.8.0 (RC3)

[Volkan Yazıcı]

Adding my +1.

With that, the release passes with 3 binding +1 votes from Piotr,
Matt, and me. I will continue the release process.

On Thu, Mar 21, 2024 at 4:42 PM 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: Context data propagation and logger-bound context data

[Volkan Yazıcı]

No, it is not the same thing Matt. Let me be as explicit as I can:

var logger0 = getLogger();  // MDC: {}
var logger1 = logger0.withContextData("x", 1);  // MDC: {x: 1}
var logger2 = logger1.withContextData("y", 2);  // MDC: {x: 1, y: 2}

This is the functionality being requested. Whoever claims this can be done
using a `MessageFactory`, they need to share a working [pseudo] code,
instead of hand waving. So far, nobody responded to this. Piotr, speculated
on a non-existing `Logger#withMessageFactory(MessageFactory)`, but there is
not one single working example shared. Hence, unless you can prove me wrong
with a working practical[1] example, *the requested feature is currently
known to be not practically possible in Log4j*.

[1] Implementing `logger.withContextData("x", 1)` with 50 LoC Java code
using the existing Log4j feature set is not a *"practical example"*.

*P.S.* For Log4j 3 API Javadocs, you can browse to
https://logging.apache.org/log4j/3.x and search for "Javadoc" in the menu.
(Obviously, same works for Log4j 2 too.)

On Thu, Mar 21, 2024 at 6:10 PM Matt Sicker  wrote:

> LogManager - log4j-api 3.0.0-alpha1 javadoc
> <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html>
> javadoc.io
> <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html>
> [image: fb2db6ea7688d54ae047109e0d71e3a0-favicon-32.png]
> <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html>
> <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html>
>
> Pass your custom MessageFactory here. It’s an optional argument when
> creating the Logger.
>
> Also, I’m not sure where to even find the current javadocs for the API.
> javadoc.io only seems to have this alpha release.
>
>
> On Mar 21, 2024, at 04:34, Volkan Yazıcı  wrote:
>
> Ralph, could you show how those two users can use a `MessageFactory` to
> create `Logger`s with predefined additional context data?
>
> On Thu, Mar 21, 2024 at 7:25 AM Ralph Goers  wrote:
>
> Unfortunately this is another message I somehow didn't get in my inbox.
> Replying to it via lists.a.o is not a great experience but is the best I
> can do.
>
> On 2024/03/20 13:51:56 Volkan Yazıcı wrote:
>
> I agree with the way Piotr dissects the problem. I think `ScopedContext`,
> even though it has its own merits, doesn't address the problem reported
>
> by
>
> users. They simply want a new logger associated with some additional
> context data.
>
>
> Two users do.  I have personally been asked for something like
> ScopedContext several times.
> As I replied to Piotr, we already solved the problem of adding data to
> Loggers. That is what MessageFactories are intended for.
>
>
> *[See my comments below.]*
>
> On Mon, Mar 18, 2024 at 10:40 AM Piotr P. Karwasz <
>
> piotr.karw...@gmail.com>
>
> wrote:
>
> * we can create a `Logger` wrapper "bound" to context data as Mikko
> does. This wrapper will take care of setting the `ThreadContext`
> before the logger call and restore it after it.
>
>
> Creating a wrapper `Logger` can work without needing to deal with
> `ThreadContext`. I can think of two different ways to carry this out:
>
>   1. Currently, `AbstractLogger` only creates `Message`s. We can rework
>
> it
>
>   to create `LogEvent`s too. Once `AbstractLogger` gets its hand on a
>   `LogEvent`, it can enrich its context data as it wishes.
>   2. We can extend `ContextDataInjector` with a new `void
>   injectContextData(Logger logger, StringMap target)` method, provide a
>   `ContextDataInjector` implementation that branches on `logger
>
> instanceof
>
>   ContextDataProvider`, and call `ContextDataInjector` with the
>
> associated
>
>   `Logger` in `LogEventFactory`.
>
>
> We can do lots of things, most of which I wouldn't recommend. As to yours:
> 1. Logger/AbstractLogger got very complex with Async, Garbage Free,
> Reliablity Strategies, etc. Trying to move creating the LogEvent sooner is
> likely to be a major PITA and could seriously impact performance. While we
> could add a context map to AbstractLogger we would have to pass that on the
> logging calls to LoggerConfig and deal with all that that means - remember,
> a LoggerConfig can be handling multiple Loggers.
> 2. I don't recommend extending ContextDataInjector. That proved difficult
> to work with which is why we now recommend using ContextDat

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

[Volkan Yazıcı]

What do you mean? That is exactly the link I shared in the very first
section of the VOTE email you responded to. See the `=== Timing &
Differences` header. Note that you don't need to trust the GitHub view, you
can diff RC2 and RC3 using their commit IDs available in the associated
VOTE emails.

On Thu, Mar 21, 2024 at 5:00 PM Gary Gregory  wrote:

> 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` <https://logging.apache.org/xml/ns> <
> https://logging.apache.org/xml/ns>
> > and `
> > https://logging.apache.org/xml/ns/log4j-changelog-0.xsd`
> <https://logging.apache.org/xml/ns/log4j-changelog-0.xsd>
> > <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)
> >
>

[VOTE] Release Apache Log4j Tools 0.8.0 (RC3)

[Volkan Yazıcı]

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)

[Volkan Yazıcı]

I need to cancel this RC2 VOTE.
Encountered another shortcoming.
I will issue an RC3 promptly.

On Tue, Mar 19, 2024 at 12:34 PM 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` <https://logging.apache.org/xml/ns>
> and
> `https://logging.apache.org/xml/ns/log4j-changelog-0.xsd`
> <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: Context data propagation and logger-bound context data

[Volkan Yazıcı]

Ralph, could you show how those two users can use a `MessageFactory` to
create `Logger`s with predefined additional context data?

On Thu, Mar 21, 2024 at 7:25 AM Ralph Goers  wrote:

> Unfortunately this is another message I somehow didn't get in my inbox.
> Replying to it via lists.a.o is not a great experience but is the best I
> can do.
>
> On 2024/03/20 13:51:56 Volkan Yazıcı wrote:
> > I agree with the way Piotr dissects the problem. I think `ScopedContext`,
> > even though it has its own merits, doesn't address the problem reported
> by
> > users. They simply want a new logger associated with some additional
> > context data.
>
> Two users do.  I have personally been asked for something like
> ScopedContext several times.
> As I replied to Piotr, we already solved the problem of adding data to
> Loggers. That is what MessageFactories are intended for.
>
> >
> > *[See my comments below.]*
> >
> > On Mon, Mar 18, 2024 at 10:40 AM Piotr P. Karwasz <
> piotr.karw...@gmail.com>
> > wrote:
> >
> > > * we can create a `Logger` wrapper "bound" to context data as Mikko
> > > does. This wrapper will take care of setting the `ThreadContext`
> > > before the logger call and restore it after it.
> >
> > Creating a wrapper `Logger` can work without needing to deal with
> > `ThreadContext`. I can think of two different ways to carry this out:
> >
> >1. Currently, `AbstractLogger` only creates `Message`s. We can rework
> it
> >to create `LogEvent`s too. Once `AbstractLogger` gets its hand on a
> >`LogEvent`, it can enrich its context data as it wishes.
> >2. We can extend `ContextDataInjector` with a new `void
> >injectContextData(Logger logger, StringMap target)` method, provide a
> >`ContextDataInjector` implementation that branches on `logger
> instanceof
> >ContextDataProvider`, and call `ContextDataInjector` with the
> associated
> >`Logger` in `LogEventFactory`.
>
> We can do lots of things, most of which I wouldn't recommend. As to yours:
> 1. Logger/AbstractLogger got very complex with Async, Garbage Free,
> Reliablity Strategies, etc. Trying to move creating the LogEvent sooner is
> likely to be a major PITA and could seriously impact performance. While we
> could add a context map to AbstractLogger we would have to pass that on the
> logging calls to LoggerConfig and deal with all that that means - remember,
> a LoggerConfig can be handling multiple Loggers.
> 2. I don't recommend extending ContextDataInjector. That proved difficult
> to work with which is why we now recommend using ContextDataProviders. You
> really can only have one ContextDataInjector. Also, please note that
> ContextDataInjector is called while constructing the LogEvent. The LogEvent
> isn't passed the Logger, only the LoggerName. Looking up the Logger to do
> this is yet another way to slow down logging.
>
> >
> > On Tue, Mar 19, 2024 at 7:45 AM Ralph Goers 
> > wrote:
> > > In the meantime, I provided
> > https://github.com/apache/logging-log4j2/pull/2385 which I very loosely
> > modeled after ScopedValues.
> >
> > The fact that `ScopedContext` tries to imitate `ScopedValue` using
> > `ThreadLocal`s is extremely confusing (from a user's pov) and risky
> > liability (from a maintainer's pov). I guess you wanted to implement *a*
> > `ScopedValue` without using *the* `ScopedValue` to be compatible with
> Java
> > 8. If so, that really sounds like the `o.a.l.log4j.util.Supplier`
> downward
> > spiral. We can rather have an *internal* `Log4jScopedValue` interface and
> > provide Java 8 (using `InheritableThreadLocal`) and Java 21+ (using
> > `ScopedValue`) compatible solutions in an MRJ (Multi-Release JAR).
>
> I am NOT trying to make ScopedContext compatible with ScopedValue. I am
> trying to make it conceptually close enough to ScopedValue that users will
> understand what it is doing.
> We can argue about naming if you want. Gary has already expressed his
> opinion.
> >
> > We can integrate `ScopedContext` to the `LogEventFactory` by providing a
> > specialized `ContextDataInjector` plugin – assuming `LogEventFactory`
> > employs all available `ContextDataInjector` plugins.
>
> ScopedContext is integrated with a ContextDataProvider, which is the
> supported way to do this. Again, you cannot have more than one
> ContextDataInjector so providing "specialized versions" is a pipe dream.
> You will simply have to enhance the one we already have.
> ContextDataInjector is NOT a plugin.
>
> >
> > I find the current ceremony also too long:
> > `ScopedContext.getCurrent().where("key1", "value1").run(...)`. I would
> > rather aim for `ScopedContext.run(key, value, runnable)` and similar
> > `ScopedContext.op(..., runnable)` interaction.
>
> Those are going to be provided as well.
>
> Ralph
>

Re: Context data propagation and logger-bound context data

[Volkan Yazıcı]

I agree with the way Piotr dissects the problem. I think `ScopedContext`,
even though it has its own merits, doesn't address the problem reported by
users. They simply want a new logger associated with some additional
context data.

*[See my comments below.]*

On Mon, Mar 18, 2024 at 10:40 AM Piotr P. Karwasz 
wrote:
> == Possible solutions
>
> As far as I know there are currently the following approaches we can
> take for problem 1:
>
> * we can add a list of `` elements in the configuration of a
> ``, which will add the given keys to all loggers using that
> configuration. This is something we can do for very static data, e.g.
> we can add to each log statement the name of the library that issued
> it.

I don't like this approach. This is simply a hack, an abuse of a component
designed for totally something else.

> * we can create a `Logger` wrapper "bound" to context data as Mikko
> does. This wrapper will take care of setting the `ThreadContext`
> before the logger call and restore it after it.

Creating a wrapper `Logger` can work without needing to deal with
`ThreadContext`. I can think of two different ways to carry this out:

   1. Currently, `AbstractLogger` only creates `Message`s. We can rework it
   to create `LogEvent`s too. Once `AbstractLogger` gets its hand on a
   `LogEvent`, it can enrich its context data as it wishes.
   2. We can extend `ContextDataInjector` with a new `void
   injectContextData(Logger logger, StringMap target)` method, provide a
   `ContextDataInjector` implementation that branches on `logger instanceof
   ContextDataProvider`, and call `ContextDataInjector` with the associated
   `Logger` in `LogEventFactory`.

On Tue, Mar 19, 2024 at 7:45 AM Ralph Goers 
wrote:
> In the meantime, I provided
https://github.com/apache/logging-log4j2/pull/2385 which I very loosely
modeled after ScopedValues.

The fact that `ScopedContext` tries to imitate `ScopedValue` using
`ThreadLocal`s is extremely confusing (from a user's pov) and risky
liability (from a maintainer's pov). I guess you wanted to implement *a*
`ScopedValue` without using *the* `ScopedValue` to be compatible with Java
8. If so, that really sounds like the `o.a.l.log4j.util.Supplier` downward
spiral. We can rather have an *internal* `Log4jScopedValue` interface and
provide Java 8 (using `InheritableThreadLocal`) and Java 21+ (using
`ScopedValue`) compatible solutions in an MRJ (Multi-Release JAR).

We can integrate `ScopedContext` to the `LogEventFactory` by providing a
specialized `ContextDataInjector` plugin – assuming `LogEventFactory`
employs all available `ContextDataInjector` plugins.

I find the current ceremony also too long:
`ScopedContext.getCurrent().where("key1", "value1").run(...)`. I would
rather aim for `ScopedContext.run(key, value, runnable)` and similar
`ScopedContext.op(..., runnable)` interaction.

I will also drop some other remarks to the PR.

[VOTE] Release Apache Log4j Tools 0.8.0 (RC2)

[Volkan Yazıcı]

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 Log4j Tools 0.8.0

[Volkan Yazıcı]

I need to cancel this vote. Figured `SchemaGenerator` needs to accept
a schema version to correctly set the `version` attribute in the
generated XSD. Sorry for the inconvenience.

On Mon, Mar 18, 2024 at 10:25 PM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j Tools 0.8.0.
>
> Website: https://logging.staged.apache.org/log4j/tools
> GitHub: https://github.com/apache/logging-log4j-tools
> Commit: 2681946896f289cd7432480712debad6af5ee684
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1264
> 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)

[VOTE] Release Apache Log4j Tools 0.8.0

[Volkan Yazıcı]

This is a vote to release the Apache Log4j Tools 0.8.0.

Website: https://logging.staged.apache.org/log4j/tools
GitHub: https://github.com/apache/logging-log4j-tools
Commit: 2681946896f289cd7432480712debad6af5ee684
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1264
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

[Volkan Yazıcı]

+1

Checked sigs, hashes, `LICENSE` files, and release notes.



On Fri, Mar 15, 2024 at 1:29 PM 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: [Feedback] Personal feedback on you last vote on Log4j 2.23.1

[Volkan Yazıcı]

I responded to the VOTE email, stated "Adding my +1", and changed the
subject to `[RESULT][VOTE]`:
https://lists.apache.org/thread/wbvg5kx3mkw4vhyp13rxlojtkrpyzsdk
Could it be that you missed my +1 due to the subject change?


On Fri, Mar 15, 2024 at 5:39 PM Christofer Dutz  wrote:

> Hi all,
>
> while going through the projects latest activity activity as part of my
> preparation for next week's board meeting, I came across a vote that was
> announced successfull even if only 2 votes were cast.
>
> I assume that the RM (Volkan) implicitly counted his vote as +1, but we do
> actually need a formal vote, as there is no such thing as an implicit vote.
>
> If you actively don't want to cast a separate vote, then please just add
> something down the line of "This email also counts as my +1 vote" or so.
>
> I just voted -1 on my latest PLC4X RC ... so I would strongly encourage
> the RM to explicitly cast a vote.
>
> And for this case ... we actually do need one last formal binding +1 vote.
> So it would be cool if someone who has not yet voted, could take care of
> that.
>
> Thanks,
> Chris
>
> PS: Please keep me in CC as I'm not subscribed to this list.
>

Re: [VOTE] Release Apache Log4Net 2.0.17

[Volkan Yazıcı]

I think this is perfectly valid, he only shared the GitHub view to the
`rel/2.0.17-rc1` tag – which is immutable due to `rel/`-prefix. He
could have maybe explicitly stated it, but not a biggie, IMHO. If you
don't like the GitHub view, you can clone the repository locally and
checkout the tag yourself.

On Fri, Mar 15, 2024 at 3:05 PM Gary D. Gregory  wrote:
>
> Hi and thank you for RM'ing this release.
>
> > https://github.com/apache/logging-log4net/releases/tag/rel/2.0.17-rc1
>
> This is no good IMO, you should provide an _apache_ link.
>
> 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
> >
> >

[ANNOUNCE] Apache Log4j 2.23.1 released

[Volkan Yazıcı]

Apache Log4j team is pleased to announce the 2.23.1
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 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)

[RESULT][VOTE] Release Apache Log4j 2.23.1

[Volkan Yazıcı]

Adding my +1.

With that, the release passes with 3 binding +1 votes from Gary,
Piotr, and me. I will continue the release process.

On Wed, Mar 6, 2024 at 2:13 PM 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: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

[Volkan Yazıcı]

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] 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
> &

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

[Volkan Yazıcı]

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: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-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 

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

[Volkan Yazıcı]

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://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
> &

Re: [VOTE] Release Apache Log4j 2.23.1

[Volkan Yazıcı]

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 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
> >

[VOTE] Release Apache Log4j 2.23.1

[Volkan Yazıcı]

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: Removal of 2.3.x and 2.12.x websites (was: Clean site repo)

[Volkan Yazıcı]

I suggest simply adding a giant banner[1] warning users and compiling a
robots.txt

for SSO.

[1] I believe we can do this by simply editing a couple of CSS files,
instead of modifying every single HTML.

On Mon, Mar 4, 2024 at 10:59 PM Piotr P. Karwasz 
wrote:

> Hi Ralph,
>
> On Mon, 4 Mar 2024 at 20:53, Ralph Goers 
> wrote:
> > > On Mar 4, 2024, at 6:24 AM, Piotr P. Karwasz 
> wrote:
> > >
> > > There is a further simplification possible: since Oracle's extended
> > > support for Java 7 has expired in July 2022, shouldn't we also
> > > redirect the `2.3.x` and `2.12.x` websites to `2.x`?
> >
> > Why would we do that? I mean we don’t officially support Java 6 or 7 yet
> we did create patches for them for Log4Shell. While I hope they never need
> to be updated again I don’t think it hurts anything to leave the doc alone.
>
> A simple Google search for `ThreadContextMap`:
>
> https://www.google.com/search?q=ThreadContextMap
>
> returns as first result a link to the javadoc of Log4j 2.4. While this
> is currently redirected permanently to `/log4j/2.12.x/`, it is still
> not the most recent documentation of the interface. How is the user
> supposed to know, that this is the documentation for an old version?
>
> We could at least add a banner to all the pages with a link to the
> most recent documentation and exclude the `/log4j/2.3.x/` and
> `/log4j/2.12.x/` websites from being indexed by search engines.
>
> Piotr
>

Re: [VOTE] Release Apache Log4net 2.0.16

[Volkan Yazıcı]

+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
>
>

Uploading release distribution for review (Was: [VOTE] Release Apache Log4net 2.0.16)

[Volkan Yazıcı]

Davyd, assuming you have `svn` in the command line, following should get
the job done:

# Checkout the `dev` distribution repository
svn co https://dist.apache.org/repos/dist/dev/logging logging-dist-dev
cd logging-dist-dev

# Delete old distribution files
svn rm log4net

# Add the new distribution of the new release
mkdir -p log4net/2.0.16
cp /path/to/distribution/files log4net/2.0.16/
svn add log4net

# Commit changes
svn commit -m 'Add `log4net` version `2.0.16` distribution files'


I presume you are using Windows. Getting `svn` in the Windows shell is
explained in this SO post.
<https://stackoverflow.com/questions/2341134/command-line-svn-for-windows>

Let me know if this does/doesn't help.

Good luck!

On Fri, Mar 1, 2024 at 5:02 PM Davyd McColl  wrote:

> Hi Volkan
>
> That was my whole point with the question on my release vote: I have put
> things in svn, bit I'm not seeing them at the url you've posted. I assume
> I've done something wrong, but I don't know what and need someone to help.
> I must admit my svn-fu is rubbish so perhaps I just messed up there. With
> the other svn repos, I use git svn bridge, but I don't want to do that here
> because that repo us huge and filled with binaries
>
> TL;DR Halp!  😅
>
> -d
>
> On 01 March 2024 15:46:24 Volkan Yazıcı  wrote:
>
>> Davyd, I am afraid it cannot qualify an official vote if the [source]
>> distribution artifacts are missing. This is the whole point of the ASF
>> release ceremony. Binary artifacts, Website, GitHub, VCS, Nuget, etc. can
>> be the most important mediums for you and/or the project, though they are
>> irrelevant from an ASF point of view.
>>
>> Could you upload the source distribution to the `
>> https://dist.apache.org/repos/dist/dev/logging /log4net` Subversion
>> folder
>> along with checksum and signature files, please?
>>
>> 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

[Volkan Yazıcı]

Davyd, I am afraid it cannot qualify an official vote if the [source]
distribution artifacts are missing. This is the whole point of the ASF
release ceremony. Binary artifacts, Website, GitHub, VCS, Nuget, etc. can
be the most important mediums for you and/or the project, though they are
irrelevant from an ASF point of view.

Could you upload the source distribution to the `
https://dist.apache.org/repos/dist/dev/logging /log4net` Subversion folder
along with checksum and signature files, please?

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: [log4net] Next release

[Volkan Yazıcı]

I think we have a deal! 🤩

Jan, if you prefer, you can also sync. with Davyd on Friday afternoon over the
ASF Slack <https://the-asf.slack.com>. We have a `#logging` public channel
there, but you can also DM each other, whatever suits you best. I think
quickly iterating over release procedure steps over chat could save both of
you from long waiting times.

I am looking forward to the outcome! 🤞

On Thu, Feb 29, 2024 at 8:56 PM Jan Friedrich  wrote:

> Hi,
>
> thanks for the opportunity, I will try my best.
>
> https://github.com/apache/logging-log4net/pull/115
>
> Regards.
>
> Jan
>
> Thursday, February 29, 2024, 12:26:55 PM, you wrote:
>
> > Hi Volkan
>
>
> > If Jan feels up to the task, it would be worthwhile to give it a go. If
> nothing else, it's a bit of a "trial by fire"
>
> > of following the RELEASING.md steps to get to a release. I'm sure there
> are bits I've missed because they
>
> > seemed obvious to me or I just missed them - having a second set of eyes
> on it, going through it, has benefits
>
> > in itself. As for the actual release, I believe Jan is more than
> capable, but I understand he may be blocked
>
> > somewhere, so if I can help, I will (: It would also be a good trial run
> to find out what, if anything, is still
>
> > required to be set up for Jan (eg svn access for the docs, etc)
>
>
> > Jan, Volkan brings up one of the sticky points - signing the release -
> which I can do from my personal
>
> > machine, with the binary artifacts in place - so I could do steps 3 and
> 4 (build and sign) - but I'll only
>
> > really have time on Friday afternoon, so I'll check it out then. In the
> mean-time, if you'd like to see
>
> > how far you can get with the RELEASING.md instructions, I'd _really_
> appreciate it. I haven't done
>
> > a log4net release in ages because it takes a reasonable amount of time
> and motivation - substances
>
> > I'm in short supply of (when I have the motivation, I don't have the
> time, and when I have the time,
>
> > it's after a long day, and I don't have the motivation any more ): )
>
>
> > -d
>
>
> > On 2024/02/29 13:02, Volkan Yazıcı wrote:
> >> Davyd, can Jan help you with the release? Since he is not a PMC member,
> >> there are certain steps he can't take. Though judging from the
> RELEASING.md
> >> <https://github.com/apache/logging-log4net/blob/master/doc/RELEASING.md
> >,
> >> maybe he can bring it to a point within the limits of access rights
> granted
> >> to him, and then you can intervene (e.g., signing artifacts, uploading
> to
> >> SVN) whenever needed.
> >>
> >> If you say this will make things more difficult, that is also
> >> understandable.
> >>
> >> On Thu, Feb 29, 2024 at 11:01 AM Davyd McColl  >
> >> wrote:
> >>
> >>> Considering my constrained time, and even though @FreeAndNil
> >>> <https://github.com/FreeAndNil> recently stepped up to be a
> maintainer, I
> >>> don't see any time really soon. You can, in the meantime, check out the
> >>> repo, build, and distribute a dll with your app if it's that important.
> >>> It's not convenient, I'll admit, but if it's urgent, it's an option.
> >>>
> >>> —
> >>> Reply to this email directly, view it on GitHub
> >>> <
> https://github.com/apache/logging-log4net/pull/103#issuecomment-1970795467
> >,
> >>> or unsubscribe
> >>> <
> https://github.com/notifications/unsubscribe-auth/AAARTSO5BS7Y4XCZS6WAOXLYV36A3AVCNFSM6ABBYRLE4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZQG44TKNBWG4
> >
> >>> .
> >>> You are receiving this because you commented.Message ID:
> >>> 
> >>>
>
>

[log4net] Next release

[Volkan Yazıcı]

Davyd, can Jan help you with the release? Since he is not a PMC member,
there are certain steps he can't take. Though judging from the RELEASING.md
,
maybe he can bring it to a point within the limits of access rights granted
to him, and then you can intervene (e.g., signing artifacts, uploading to
SVN) whenever needed.

If you say this will make things more difficult, that is also
understandable.

On Thu, Feb 29, 2024 at 11:01 AM Davyd McColl 
wrote:

> Considering my constrained time, and even though @FreeAndNil
>  recently stepped up to be a maintainer, I
> don't see any time really soon. You can, in the meantime, check out the
> repo, build, and distribute a dll with your app if it's that important.
> It's not convenient, I'll admit, but if it's urgent, it's an option.
>
> —
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> You are receiving this because you commented.Message ID:
> 
>

Re: Clean site repo

[Volkan Yazıcı]

If there are no objections, after Log4j `2.23.0` and `3.0.0-beta2`
releases, I want to proceed with replacing the contents of
`asf-{site,staging}` branches with `clean-staging`. Effectively, this
operation has the following outcomes:

   - The `logging-log4j-site` repository will contain only following files:
  - `1.x`
  - `2.12.x`
  - `2.3.x`
  - `2.x`
  - `3.x`
  - `.asf.yaml`
  - `changelog-*.xsd`
  - `extras`
  - `.htaccess`
   - `.htaccess` will take care of redirections for backward compatibility


On Tue, Feb 6, 2024 at 5:06 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> The current `asf-site` branch of the `logging-log4j-site` repo has
> about 450k files, which makes it very hard to work on it.
>
> Most of those are websites of old releases that I doubt anybody
> (except search engines) visits. Those websites also pollute search
> engine results: several times I found the page of an old release
> better ranked that the current version.
>
> Therefore I created a new branch `clean-log4j`[1] (which is published
> as [2]) that contains only these directories:
>
> * 1.x: last 1.x release.
> * 2.3: last 2.3 release. Although not strictly necessary, I thought
> that people stuck with Java 6 will appreciate a website without all
> the features from newer releases.
> * 2.12: last 2.12 release.
> * 2.x: latest 2.x release.
> * 3.x: latest 3.x release.
> * extras: last Apache Log4j Extras release.
>
> and the XML schemata for our changelog format (although they should be
> moved to `/xml/ns/changelog`).
>
> All the `log4j-` and similar directories are redirected
> (permanent 301 redirect) to one of the remaining one: e.g.
> `log4j-2.0.1` is redirected to `2.3`, `log4j-2.4` is redirected to
> `2.12`, while `2.13.0` (sic!) is redirected to `2.x`.
>
> For those that like to go down memory lane, the branch contains 65
> commits for each one of our releases.
>
> What do you think about replacing `asf-site` with this branch?
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j-site/tree/clean-staging
> [2] https://logging-clean.staged.apache.org/log4j
>

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

[Volkan Yazıcı]

+1

On Sun, Feb 18, 2024 at 9:06 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&p0=1440&font=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 frozen if map is immutable. (#2098)
> * Fix regression in `JdkMapAdapterStringMap` performance. (#2238)
> * Prevents ClassCastException when trying to assign a
> SimpleLoggerContext to a core LoggerContext (LOG4J2-1921)
> * Possible NullPointerException in MongoDb4DocumentObject,
> MongoDbDocumentObject, DefaultNoSqlObject. (LOG4J2-3392)
> * Fix NPE in `CloseableThreadContext`. (#1426)
> * Fix NPE in `RollingFileManager`. (#1645)
> * Fix `log4j-spring-cloud-config-client` dependencies to include only
> those required. (2157)
> * Workaround a Coursier/Ivy dependency resolution bug affecting
> `log4j-slf4j-impl` and `log4j-mongodb3`. (#2065)
>
> === Removed
>
> * Removed legacy `2.x` properties configuration factory.
> * Remove `DefaultLogEventFactory`
> * Remove `log4j-appserver` module (#2257)
> * Remove `org.apache.logging.log4j.core.parser` and related packages.
> (#2154)
> * Remove `log4j-jcl` module (#2257)
> * Removed JMX support.
> * Remove `log4j-layout-jackson` module (#2198)
> * Remove `log4j-layout-jackson-xml` module (#2198)
> * Remove `log4j2.enable.threadlocals` property (#2105)
>
> === Updated
>
> * Update `apache/logging-parent` to version `` (#2191)
> * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.1` (#2127)
> * Update `commons-codec:commons-

Re: [VOTE] Release Apache Log4j 2.23.0 RC1

[Volkan Yazıcı]

+1

On Sat, Feb 17, 2024 at 2:15 PM 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&p0=1440&font=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: Migrate *all* Issue Tracking and Discussions to GitHub

[Volkan Yazıcı]

As per consensus, enabled GitHub Discussions for both Log4Net and Log4cxx –
GitHub Issues were already enabled. I will submit a PR to both projects
updating their docs to reflect these changes.

On Tue, Feb 13, 2024 at 9:20 AM 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
> <https://logging.apache.org/log4j/2.x/support.html> 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: [log4j] Remove `` in `main`

[Volkan Yazıcı]

I agree with your remark on priority. Using Log4j 2 API in Log4j 3 is
indeed our focus. My recent refactoring of `StatusLogger` was a part of
that effort. Since I already have my hands dirty with it, I want to take
one last step to polish it in `main` and remove the `StatusConfiguration`
wrinkle.

As soon as I have time, I will land two PRs:

   1. One against `2.x` to warn that `StatusConfiguration` will be removed
   2. One against `main` to remove the `StatusConfiguration`

I also agree that having `StatusLogger` per `LoggerContext` is an overkill
and I am strongly opinionated on that.

On Wed, Feb 14, 2024 at 4:34 AM Ralph Goers 
wrote:

> There could be if there was a StatusLogger per LoggerContext. But you
> would still need a global StatusLogger. But doing that seems like overkill.
>
> On the one hand it is very convenient to configure the level in the config
> file, but on the other the fact that it only takes place halfway through
> configuration is a bit of a problem as that is largely when it is needed.
>
> There is also the issue of compatibility. If support for it is removed we
> would still need to tolerate its presence. In the beginning we could log an
> Info message and then after a while convert it to a warn message before
> support is removed.
>
> To be honest, this isn’t a top priority on the list of things that need to
> be addressed for me which is partly why I guess I am hesitant to do
> anything. It feels like we keep talk about making changes but aren’t really
> focused on getting 3.0 done. Of course, deciding to stick with the 2.x API
> threw a wrinkle into the works of getting 3.x out the door but I’d still
> like that to be our top focus.
>
> Ralph
>
> > On Feb 13, 2024, at 10:21 AM, Matt Sicker  wrote:
> >
> > If there were a way to allow for multiple StatusLogger configurations
> concurrently, then I’d support keeping it in the config file. Otherwise,
> I’m somewhat ambivalent about this.
> >
> >> On Feb 12, 2024, at 13:29, Volkan Yazıcı  wrote:
> >>
> >> *Abstract:* I want to remove from `main` the feature that a
> `Configuration`
> >> (e.g., `` in a `log4j2.xml`)
> >> configuring the `StatusLogger`, and instead, only allow configuration
> using
> >> properties.
> >>
> >> `StatusLogger` can be configured in following ways:
> >>
> >>  1. Passing system properties to the Java process (e.g.,
> >>  `-Dlog4j2.StatusLogger.level=INFO`)
> >>  2. Providing properties in a `log4j2.StatusLogger.properties` file in
> >>  the classpath
> >>  3. Using Log4j configuration (i.e., ` >>  dest="out">`) in a `log4j2.xml` in the classpath. This is facilitated
> by
> >>  `StatusConfiguration`.
> >>  4. Programmatically (i.e., `StatusLogger.getLogger().setLevel(...)`)
> >>
> >> `StatusConfiguration`-based configuration has certain caveats:
> >>
> >>  - There is a time between the first `StatusLogger` access and a
> >>  configuration file (e.g., `log4j2.xml`) read. Hence, there is a time
> window
> >>  that only the defaults will be effective.
> >>  - `StatusConfiguration` is created per `LoggerContext` and each LC
> >>  mutates the (globally shared!) `StatusLogger`. Hence, the last loaded
> >>  configuration always becomes the effective one.
> >>
> >> Given the purpose of `StatusLogger` (i.e., the logger of the logging
> >> system) and above shortcomings related to `StatusConfiguration`, I want
> to
> >> remove the `StatusConfiguration`-based configuration in `main`.
> Thoughts?
> >> Objections?
> >
>
>

Re: [VOTE] Move Chainsaw to dormant

[Volkan Yazıcı]

+1

On Mon, Feb 12, 2024 at 10: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
>

Migrate *all* Issue Tracking and Discussions to GitHub

[Volkan Yazıcı]

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.

[log4j] Remove `` in `main`

[Volkan Yazıcı]

*Abstract:* I want to remove from `main` the feature that a `Configuration`
(e.g., `` in a `log4j2.xml`)
configuring the `StatusLogger`, and instead, only allow configuration using
properties.

`StatusLogger` can be configured in following ways:

   1. Passing system properties to the Java process (e.g.,
   `-Dlog4j2.StatusLogger.level=INFO`)
   2. Providing properties in a `log4j2.StatusLogger.properties` file in
   the classpath
   3. Using Log4j configuration (i.e., ``) in a `log4j2.xml` in the classpath. This is facilitated by
   `StatusConfiguration`.
   4. Programmatically (i.e., `StatusLogger.getLogger().setLevel(...)`)

`StatusConfiguration`-based configuration has certain caveats:

   - There is a time between the first `StatusLogger` access and a
   configuration file (e.g., `log4j2.xml`) read. Hence, there is a time window
   that only the defaults will be effective.
   - `StatusConfiguration` is created per `LoggerContext` and each LC
   mutates the (globally shared!) `StatusLogger`. Hence, the last loaded
   configuration always becomes the effective one.

Given the purpose of `StatusLogger` (i.e., the logger of the logging
system) and above shortcomings related to `StatusConfiguration`, I want to
remove the `StatusConfiguration`-based configuration in `main`. Thoughts?
Objections?

Re: Version 2.23.0 release schedule

[Volkan Yazıcı]

+1

Once #2280  (fixing the
`2.x` build) and #2278 (Allow arbitrary position of `` element)
 are in, we can put a
ribbon around `2.23.0`.

On Mon, Feb 12, 2024 at 12:15 PM 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
>

New committer: Fred am Nil (`freeandnil`)

[Volkan Yazıcı]

The Project Management Committee (PMC) for Apache Logging Services has
invited Fred am Nil to become a committer and we are pleased to announce
that they have accepted! 🎉

They have been a long time Log4Net contributor and I am very happy to see
them stepping up to become a maintainer for it. Logging Services
 is more than Log4Net; we have Log4j, Log4cxx,
and several other projects. I am looking forward to their contributions to
all these projects! 🚀

Re: Clean site repo

[Volkan Yazıcı]

On Tue, Feb 6, 2024 at 5:46 PM Ralph Goers 
wrote:

> When you say “hard to work with it” what does that mean?


Git commands work slow (e.g., `git status` takes seconds) and it is
difficult to understand what goes where.


> Volkan has mentioned some ideas to me which would allow us to keep the
> relevant info from previous releases.
>

> I don’t like the idea of having multiple efforts going on.
>

Piotr implements the `1.x`, `2.x`, `3.x` scheme I proposed earlier. Though
I still think Log4j 1, Log4j 2, and Log4j 3 websites should be moved to the
`logging-log4j2` repository and `logging-log4j-site` repository should only
be used for stuff that doesn't belong to a particular project repository,
e.g., `log4j-extras` (since the original `log4j-extras` repository is
converted to be read-only, we cannot move its website there) and
`/xml/ns/changelog`. Nevertheless, Piotr's proposal can be a good first
step in the direction I proposed earlier.

Regarding keeping the website+manual of the old releases (e.g.,
`/log4j/log4j-2.19.0`, `/log4j/log4j-2.20.0`) without ending up in a state
which we currently are... This is doable. We can place, say, `log4j-2.22.1`
folder to a `asf-site-log4j-2.22.1` branch with its own `.asf.yaml`
targeting the output to `/log4j/log4j-2.22.1`. Though... should we?

I can see the use cases for wanting to keep the website+manual of every
single release in a dedicated directory. Though my counter arguments are:

   1. These pages were never officially linked, hence were not exposed to
   users. What is the pressing need right now to make this happen?
   2. They get search engines confused and cause users to end up in legacy
   pages.
   3. The infrastructure to realize this (putting each release to a
   separate site branch) is cumbersome, difficult to navigate for developers,
   deviates from the standard the rest of our websites follow, and hence
   complicates the release process substantially.
   4. We (almost) never break backward compatibility in a major release
   line. Hence, the docs of `2.x` is a superset of the docs of, say, `2.22.0`.
   We also always document newly added features as "Starting from version
   `2.22.0`, ..." Given these, I don't see a compelling point of having a
   separate website for `2.22.0`.

In short,

   1. Release-specific website+manual (i.e., `/log4j/log4j-2.19.0`) was
   never an official service
   2. It is difficult to implement and wrap automation around it
   3. We can postpone it to a time where a need arises

Re: Clean site repo

[Volkan Yazıcı]

+1

Nit: I would use `2.3.x` and `2.12.x` to match the `.x` suffix convention
we use in `1.x`, `2.x`, and `3.x`. Or totally the other way around, no `.x`
suffix at all: `1`,  `2`, `2.3`, `2.12`, and `3`.

On Tue, Feb 6, 2024 at 5:06 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> The current `asf-site` branch of the `logging-log4j-site` repo has
> about 450k files, which makes it very hard to work on it.
>
> Most of those are websites of old releases that I doubt anybody
> (except search engines) visits. Those websites also pollute search
> engine results: several times I found the page of an old release
> better ranked that the current version.
>
> Therefore I created a new branch `clean-log4j`[1] (which is published
> as [2]) that contains only these directories:
>
> * 1.x: last 1.x release.
> * 2.3: last 2.3 release. Although not strictly necessary, I thought
> that people stuck with Java 6 will appreciate a website without all
> the features from newer releases.
> * 2.12: last 2.12 release.
> * 2.x: latest 2.x release.
> * 3.x: latest 3.x release.
> * extras: last Apache Log4j Extras release.
>
> and the XML schemata for our changelog format (although they should be
> moved to `/xml/ns/changelog`).
>
> All the `log4j-` and similar directories are redirected
> (permanent 301 redirect) to one of the remaining one: e.g.
> `log4j-2.0.1` is redirected to `2.3`, `log4j-2.4` is redirected to
> `2.12`, while `2.13.0` (sic!) is redirected to `2.x`.
>
> For those that like to go down memory lane, the branch contains 65
> commits for each one of our releases.
>
> What do you think about replacing `asf-site` with this branch?
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j-site/tree/clean-staging
> [2] https://logging-clean.staged.apache.org/log4j
>

Re: [chainsaw] Status change?

[Volkan Yazıcı]

+1

Allow me to make some corrections:

`XmlLayout` is dropped in Log4j 3, not in Log4j 2.

Logstash (the L in the ELK, Elasticsearch-Logstash-Kibana, stack) supports
reading logs from a file formatted using a particular pattern. You combine
Filebeat with grok filter

to achieve that.


On Wed, Feb 7, 2024 at 5:19 AM Scott Deboy  wrote:

> Thank you for spending time working on it Christian.
>
> I started contributing to Chainsaw in 2003. I agree. It's time.
>
> The primary benefit of Chainsaw was its built-in support for real-time
> tailing of ssh-accessible pattern-layout based logs  - something
> Kibana doesn't support well, and something no-one ever really
> understood about it.
>
> It was always a dev-focused tool - it works great for local dev, and
> works in some prod envs, if you spend enough time to get the setup to
> work.
>
> There was no great reason to move off of the log41 deps really - they
> aren't used for anything other than parsing the patternlayout, but
> log4j1 is dead, so I get it.
>
> I use it for my work, and will continue to do so, but the
> chainsaw-with-log4j1-dep branch. I may revert master back to that,
> because why not.
>
> +1
>
> Thanks again for putting up with my persistence to try and make it
> useful to folks - I appreciate it  :)
>
> Scott
>
>
> On 2/6/24, Christian Grobmeier  wrote:
> > Hello
> >
> > we have had Chainsaw for a long time in our product list, and I can
> totally
> > see that some - myself included - are emotionally attached to it.
> However,
> > due to my work on it, I have given it some additional thought.
> >
> > After working with the Chainsaw code base for a while, I saw that many
> > features were commented out and removed when migrating to Log4j 2.
> >
> > Some basic features, such as "Open Logfile to view it directly." were
> > removed. It is already hard to recover the functionality since
> log4j-extras
> > no longer exists. In addition, as I learned recently, Log4j 2 has removed
> > the XML Formatter. The old implementation of Chainsaw could only open
> > XML-formatted log files.
> >
> > Honestly, there is much work to make Chainsaw a working product again. I
> > mostly did refactorings and clean-ups, but I am not even through. I could
> > continue like this for two more months.
> >
> > Restoring the old functionality and making it functional again requires
> even
> > more months.
> > If we had completed it, we would have restored a Swing application,
> mostly
> > replaced by Kibana stacks.
> >
> > At this point, I don't see how we can write the tons of code necessary,
> and
> > also not how useful it would be. Either all our users are using Log4j 1,
> or
> > we don't have any users at all for Chainsaw, since it didn't work.
> >
> > For that reason, I would like to propose to move Chainsaw to dormant. If
> we
> > feel for it, we can work and fix it - we should not archive the repo.
> But I
> > would like to make clear that Chainsaw is not in good shape, and people
> > should only use it only "at their own risk."
> >
> > I would like to make clear that this proposal is not something I say
> easily,
> > but I feel it is in the best interest of our users to communicate how we
> > currently see the status of this project.
> >
> > Please note, that I don't have much time to continue to work on it in the
> > next months.
> >
> > Remembering the last discussion about this: Scott, are you OK with that
> > move? I know it's your baby, but as long as we don't have a working
> product,
> > we should move it. I am open to moving it back when we somehow get rid of
> > all the problems.
> >
> > Please let me know if one of you has an alternate proposal - we can also
> > discuss it in the next call.
> >
> > Kind regards,
> > Christian
> >
> > --
> > The Apache Software Foundation
> > V.P., Data Privacy
> >
>

Re: [log4j] Nested logging and async. message formatting

[Volkan Yazıcı]

Thanks so much for thinking along with me Piotr in this pretty
sophisticated puzzler. Regarding your following statements...

On Mon, Feb 5, 2024 at 8:43 PM Piotr P. Karwasz  wrote:
> I would prefer for the two event factories **not** to call
> `Message#getFormattedMessage` at all.
> ...
> Both issues are caused by an additional
> `InternalAsyncUtil.makeMessageImmutable()` in
> `MutableLogEvent#setMessage`, that can be removed.

I don't feel comfortable enough with the async. code base to carry out
these two changes. Nevertheless, I am all in for them. I don't know if
I can spare more time on this to examine it further and implement the
necessary changes. If you would like to go ahead yourself, you are
more than welcome.

For now, I will only remove `*Nested*Test` classes blocking the
`2.x-StatusLogger-revamp` branch.

[ANNOUNCE] Apache Log4j Scala 13.1.0 released

[Volkan Yazıcı]

Apache Log4j Scala team is pleased to announce the 13.1.0
release. This project provides a Scala-friendly interface to log
against the Log4j API. For further information (support, download,
etc.) see the project website[1].

[1] https://logging.apache.org/log4j/scala

=== Release Notes

This minor release contains a bug fix, Software Bill of Materials
(SBOM) generation, and some dependency updates.

 Added

* Start generating CycloneDX SBOM

 Fixed

* Fix recursive inlining issues in Scala 3 macros (#40)

 Updated

* Update `org.apache.logging.log4j:log4j-bom` to version `2.22.1` (#43)
* Update `org.apache.logging:logging-parent` to version `10.6.0` (#44)

[RESULT][VOTE] Release Apache Log4j Scala 13.1.0

[Volkan Yazıcı]

Adding my +1.

With that, the release passes with 3 binding +1 votes from Piotr,
Christian, and me. I will continue the release process.

On Thu, Feb 1, 2024 at 11:31 AM Volkan Yazıcı  wrote:
>
> This is a vote to release the Apache Log4j Scala 13.1.0.
>
> Website: https://logging.staged.apache.org/log4j/scala
> GitHub: https://github.com/apache/logging-log4j-scala
> Commit: abf3b13d3692b45d221dc78202c34f00f8f9124f
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1257
> 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.
>
> === Reproducibility
>
> As was the case in the previous `13.0.0` release, the
> `log4j-api-scala_3.jar` artifact targeting Scala 3 in this
> release is also not reproducible due to a bug in the
> Scala 3 compiler. See `13.0.0` vote email[1] for details
> and how to verify the reproducibility by working around
> the Scala 3 compiler issue.
>
> [1] https://lists.apache.org/thread/3rrg3xj2sk6m3chx82k8kpx6nbdqb8oz
>
> === 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 contains a bug fix, Software Bill of Materials
> (SBOM) generation, and some dependency updates.
>
>  Added
>
> * Start generating CycloneDX SBOM
>
>  Fixed
>
> * Fix recursive inlining issues in Scala 3 macros (#40)
>
>  Updated
>
> * Update `org.apache.logging.log4j:log4j-bom` to version `2.22.1` (#43)
> * Update `org.apache.logging:logging-parent` to version `10.6.0` (#44)

Re: [VOTE] Release Apache Log4j Scala 13.1.0

[Volkan Yazıcı]

I need 2 +1's from PMC members to make this release happen. We are on the
5th day and I am still yet to hear a reaction. I also shared the commands
PMC members need to run to review the release. Is there anything else I
need to provide? Could you help by voting, please?

On Thu, Feb 1, 2024 at 11:31 AM Volkan Yazıcı  wrote:

> This is a vote to release the Apache Log4j Scala 13.1.0.
>
> Website: https://logging.staged.apache.org/log4j/scala
> GitHub: https://github.com/apache/logging-log4j-scala
> Commit: abf3b13d3692b45d221dc78202c34f00f8f9124f
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1257
> 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.
>
> === Reproducibility
>
> As was the case in the previous `13.0.0` release, the
> `log4j-api-scala_3.jar` artifact targeting Scala 3 in this
> release is also not reproducible due to a bug in the
> Scala 3 compiler. See `13.0.0` vote email[1] for details
> and how to verify the reproducibility by working around
> the Scala 3 compiler issue.
>
> [1] https://lists.apache.org/thread/3rrg3xj2sk6m3chx82k8kpx6nbdqb8oz
>
> === 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 contains a bug fix, Software Bill of Materials
> (SBOM) generation, and some dependency updates.
>
>  Added
>
> * Start generating CycloneDX SBOM
>
>  Fixed
>
> * Fix recursive inlining issues in Scala 3 macros (#40)
>
>  Updated
>
> * Update `org.apache.logging.log4j:log4j-bom` to version `2.22.1` (#43)
> * Update `org.apache.logging:logging-parent` to version `10.6.0` (#44)
>

Re: [log4j] Nested logging and async. message formatting

[Volkan Yazıcı]

Okay, nested logging is officially not supported. I will remove the nested
logging tests blocking the `2.x-StatusLogger-revamp` branch.

What about the other two issues I mentioned:

   1. `log4j2.formatMsgAsync` and `@AsynchronouslyFormattable` don't always
   work (`log4j2.formatMsgAsync=false` is ignored for reusable messages, which
   are formatted always eagerly)
   2. Usage of `Message#getFormattedMessage()` in
   `InternalAsyncUtil.makeMessageImmutable()` triggers an unnecessary `String`
   allocation


On Mon, Feb 5, 2024 at 4:29 PM Ralph Goers  wrote:

>
>
> On 2024/02/05 15:17:29 Volkan Yazıcı wrote:
> >
> > AFAIK, nested logging is not a documented feature. Yet one can find
> several
> > tickets people has filed issues that were fixed by us. Hence, it is safe
> to
> > conclude that it is used.
>
> You are correct that it is not documented. Nor should it be. As you are
> seeing you cannot count on how it will behave. I believe any unit tests
> that expect a particular behavior should be removed.
>
> >
> > I also don't know why recursion is not allowed in `AppenderControl`.
> > (Related history is too old and could not get in while migrating from SVN
> > to Git.)
>
> Recursion is not allowed because it creates a stack overflow exception.
> For example, The user logs a message that routes to an Appender that uses a
> framework that logs a message. That message gets routed back to the same
> Appender which again calls the same framework which logs a message. This
> will endlessly repeat. The recursion check prevents this from happening and
> the nested log message is discarded.  This is actually the ONLY behavior of
> nested logging that should be documented and guaranteed. Passing objects to
> logging that themselves perform logging as they are formatted has to result
> in the unpredictable category since the formatting cannot be guaranteed to
> occur the same way under all conditions.
>
> Ralph
>

[log4j] Nested logging and async. message formatting

[Volkan Yazıcı]

*Abstract:* Nested logging does not always work, it conflicts with
`log4j2.formatMsgAsync`, and I need help on fixing it.

*Problem description*

Nested logging – that is, while trying to `log()`,
exception/argument/message access invokes `log()` too – only works with
message factories that eagerly format the message. `LoggerConfig` contains
the following logic:

var logEvent = logEventFactory.createEvent();
log(logEvent); // goes to `AppenderControl#shouldSkip()`

Imagine the following:

private static final class ArgThatLogs {
@Override
public String toString() {
logger.trace("foo");
return "bar";
}
}

logger.info("{} buzz", new ArgThatLogs());

In `LoggerConfig`, if the `logEventFactory` of subject is
`ReusableLogEventFactory`, `createEvent()` will first try to format the
message (which will trigger `ArgThatLogs#toString()`, which will trigger
`logger.trace("foo")`), and then call `log(logEvent)`. Hence the logging
output will be as follows:

foo
bar buzz

If the `logEventFactory` of subject is `DefaultLogEventFactory`,
`createEvent()` will perform no formatting, `log(logEvent)` will be
invoked, and then `ArghThatLogs#toString()`, and then
`logger.trace("foo")`, and then `AppenderControl#shouldSkip()` will return
`true` due to `isRecursiveCall()` returning `true`. Hence the logging
output will be as follows:

bar buzz

Note the missing `foo` log line. As a matter of fact, all `*Nested*Test`
classes fail when `DefaultLogEventFactory` is used.

I thought of matching the behavior between the two log event factories by
making the `DefaultLogEventFactory` format the message at creation. This
would imply both message factories will be formatting the message eagerly.
(Formatting the message at the logger thread was also suggested by Nitsan
Wakart
,
the JVM performance celebrity, too.)

While examining the code base on this subject, I came across the
`log4j2.formatMsgAsync` property (flag that *"will make sure the message is
formatted in the caller thread"*) and the `@AsynchronouslyFormattable`
annotation. This gets the things even more complicated:

   1. These configuration knobs contradict with the *"eagerly format
   messages everywhere"* feature I suggested to implement above.
   2. If `log4j2.formatMsgAsync=true`, nested logging does not work
   anymore. That is, postponing the message formatting to `log(logEvent)`
   causes recursion and hence the nested `log(logEvent)` gets skipped.
   (`DefaultLogEventFactory` fails to log the nested call exactly due to the
   same reason.)
   3. One would expect these configuration knobs to be effective somewhere
   in my nested logging example above. But they surprisingly play no role in
   this entire flow in almost all cases. That is, there is
   `InternalAsyncUtil.makeMessageImmutable()` taking these configuration knobs
   into account, but it is only called in async. contexts (e.g.,
   `AsyncAppender` or `AsyncLogger) when a message is not reusable. It makes
   sense that the configuration is taken into account only when the context is
   async. But it should *not* depend on if-the-message-is-reusable
   condition. That is, the fact that reusable messages are *always*
   formatted eagerly violates the `log4j2.formatMsgAsync=true` condition, if
   provided.

There is a performance issue in the design
of `InternalAsyncUtil.makeMessageImmutable()` too. It invokes
`Message#getFormattedMessage()` to indicate to the message that it can
format the message and cache the result, if possible. Yet,
`getFormattedMessage()` has a return type of `String`, forcing the message
to allocate a string unnecessarily.

Formatting messages asynchronously (LOG4J2-898
) was implemented by
Remko. AFAIC, formatting messages async. and nested logging are features
that don't always work and enabling one breaks the behaviour of the other.
A user caring about logger latency (i.e., `log4j2.formatMsgAsync=true`),
cannot have nested logging. Likewise, a user caring about nested logging
cannot have async. message formatting, since postponing message formatting
is causing recursion which eventually causes the nested logging to get
dropped. Plus, none of the features work as advertised for all cases. They
both unexpectedly don't work under certain circumstances.

AFAIK, nested logging is not a documented feature. Yet one can find several
tickets people has filed issues that were fixed by us. Hence, it is safe to
conclude that it is used.

I also don't know why recursion is not allowed in `AppenderControl`.
(Related history is too old and could not get in while migrating from SVN
to Git.)

*Summary*

Let me try to recap the story:

   1. Nested logging is not a documented feature, yet expected to work by
   users
   2. Nested logging doesn't always work (when message formatting is
   postponed ei

Re: log4net maintainers

[Volkan Yazıcı]

Thanks so much Jan. In accordance with the new committer process
<https://community.apache.org/newcommitter.html#new-committer-process> I
shared earlier, I need to wait for the voting deadline: 2024-02-08 12:20
CET. Next I will announce the result, and, if it is positive, I will
proceed with creating your account, granting rights, and so on.

On Thu, Feb 1, 2024 at 10:50 PM Fred am Nil  wrote:

> Hi Volkan,
>
> my ICLA has been filed.
> I would like to have the "freeandnil" Apache id.
>
> Regards.
>
> Jan
>
>
> FaN> Hi Volkan,
>
> FaN> 1. I subscribed to dev@ yesterday and to log4j-user@ today.
> FaN> 2. yes, I already did that one or two years ago
> FaN> 3. you can call me Jan ;-)
>
> FaN> Regards.
>
> FaN> Jan
>
> VY>> Great! I have started the voting process in the private mailing list.
> I
> VY>> will share the result next week around this time.
>
> VY>> Fred, some questions:
>
> VY>>1. Are you subscribed to `dev@` and `log4j-user@` mailing lists
> VY>><https://logging.apache.org/support.html>? If not, could you
> please do
> VY>>so? (Mailing lists are the official communication channels of ASF.)
> VY>>2. Are you watching "All Activity" on logging-log4net
> VY>><https://github.com/apache/logging-log4net>? If not, could you
> please do
> VY>>so?
> VY>>3. Do you want to be referred to as Fred or Jan?
>
>
> VY>> On Thu, Feb 1, 2024 at 1:13 PM Fred am Nil 
> wrote:
>
> >>> Hi Volkan,
> >>>
> >>> I've overlooked this sentence.
> >>> I sent the pdf to secret...@apache.org.
> >>>
> >>> Regards.
> >>>
> >>> Fred
> >>>
> >>> VY> Thanks for the prompt response Fred. As stated in the 2nd
> paragraph of
> >>> the
> >>> VY> ICLA:
> >>>
> >>>
> >>> VY> *Please complete and sign this Agreement, and then email a pdf
> copy*
> >>> VY> *to secret...@apache.org  only (do not copy
> any
> >>> other
> >>> VY> persons or lists).**Read this document carefully before signing and
> >>> keep a
> >>> VY> copy for your records.*
> >>>
> >>>
> >>> VY> Hence... Could you send the PDF to `secret...@apache.org`
> **ONLY**,
> >>> please?
> >>>
> >>> VY> On Thu, Feb 1, 2024 at 11:59 AM Fred am Nil  >
> >>> wrote:
> >>>
> >>> >> Hi Volkan,
> >>> >>
> >>> >> I signed and attached the ICLA.
> >>> >>
> >>> >> Regards.
> >>> >>
> >>> >> Fred
> >>> >>
> >>> >> VY> Hello Fred,
> >>> >>
> >>> >> VY> Thank you so much for stepping up! It means a lot for the
> project.
> >>> 🙏
> >>> >>
> >>> >> VY> We will follow the ASF committer admission process
> >>> >> VY> <
> >>> https://community.apache.org/newcommitter.html#new-committer-process>.
> >>> >> You
> >>> >> VY> already shared your GitHub ID. Would you also mind signing &
> >>> >> submitting in
> >>> >> VY> the Individual Contributor License Agreement (ICLA)
> >>> >> VY> <https://www.apache.org/licenses/icla.pdf>, please? If you have
> >>> >> already
> >>> >> VY> done so, mind sharing your Apache ID(s)?
> >>> >>
> >>> >> VY> Cheers!
> >>> >>
> >>> >> VY> On Wed, Jan 31, 2024 at 12:01 PM Fred am Nil
> >>> >> 
> >>> >> VY> wrote:
> >>> >>
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> as proposed by Volkan Yazıcı in
> >>> >> >>
> >>> >>
> >>>
> https://github.com/apache/logging-log4net/pull/103#issuecomment-1918677272
> >>> >> >> I would like to become a maintainer of log4net.
> >>> >> >>
> >>> >> >> https://github.com/FreeAndNil
> >>> >> >>
> >>> >> >> Regards.
> >>> >> >>
> >>> >> >> Fred
> >>> >> >>
> >>> >> >>
> >>> >>
> >>>
> >>>
>
>

Re: log4net maintainers

[Volkan Yazıcı]

Great! I have started the voting process in the private mailing list. I
will share the result next week around this time.

Fred, some questions:

   1. Are you subscribed to `dev@` and `log4j-user@` mailing lists
   <https://logging.apache.org/support.html>? If not, could you please do
   so? (Mailing lists are the official communication channels of ASF.)
   2. Are you watching "All Activity" on logging-log4net
   <https://github.com/apache/logging-log4net>? If not, could you please do
   so?
   3. Do you want to be referred to as Fred or Jan?


On Thu, Feb 1, 2024 at 1:13 PM Fred am Nil  wrote:

> Hi Volkan,
>
> I've overlooked this sentence.
> I sent the pdf to secret...@apache.org.
>
> Regards.
>
> Fred
>
> VY> Thanks for the prompt response Fred. As stated in the 2nd paragraph of
> the
> VY> ICLA:
>
>
> VY> *Please complete and sign this Agreement, and then email a pdf copy*
> VY> *to secret...@apache.org  only (do not copy any
> other
> VY> persons or lists).**Read this document carefully before signing and
> keep a
> VY> copy for your records.*
>
>
> VY> Hence... Could you send the PDF to `secret...@apache.org` **ONLY**,
> please?
>
> VY> On Thu, Feb 1, 2024 at 11:59 AM Fred am Nil 
> wrote:
>
> >> Hi Volkan,
> >>
> >> I signed and attached the ICLA.
> >>
> >> Regards.
> >>
> >> Fred
> >>
> >> VY> Hello Fred,
> >>
> >> VY> Thank you so much for stepping up! It means a lot for the project.
> 🙏
> >>
> >> VY> We will follow the ASF committer admission process
> >> VY> <
> https://community.apache.org/newcommitter.html#new-committer-process>.
> >> You
> >> VY> already shared your GitHub ID. Would you also mind signing &
> >> submitting in
> >> VY> the Individual Contributor License Agreement (ICLA)
> >> VY> <https://www.apache.org/licenses/icla.pdf>, please? If you have
> >> already
> >> VY> done so, mind sharing your Apache ID(s)?
> >>
> >> VY> Cheers!
> >>
> >> VY> On Wed, Jan 31, 2024 at 12:01 PM Fred am Nil
> >> 
> >> VY> wrote:
> >>
> >> >> Hi,
> >> >>
> >> >> as proposed by Volkan Yazıcı in
> >> >>
> >>
> https://github.com/apache/logging-log4net/pull/103#issuecomment-1918677272
> >> >> I would like to become a maintainer of log4net.
> >> >>
> >> >> https://github.com/FreeAndNil
> >> >>
> >> >> Regards.
> >> >>
> >> >> Fred
> >> >>
> >> >>
> >>
>
>

Re: [log4cxx] Github discussions

[Volkan Yazıcı]

+1

It has been a great success for Log4j. I definitely advise doing so for
Log4cxx too! Maybe even for Log4net as well? (Get 'em done with one INFRA
ticket?)

On Thu, Feb 1, 2024 at 12:56 PM Robert Middleton 
wrote:

> Would people be in favor of enabling Github discussions for Log4cxx?
> We don't get many reports, but we do occasionally get support
> questions as issues.
>
> INFRA needs to turn this on, there's no way for us to do it manually,
> hence this question.
>
> -Robert Middleton
>

Re: log4net maintainers

[Volkan Yazıcı]

Thanks for the prompt response Fred. As stated in the 2nd paragraph of the
ICLA:


*Please complete and sign this Agreement, and then email a pdf copy*
*to secret...@apache.org  only (do not copy any other
persons or lists).**Read this document carefully before signing and keep a
copy for your records.*


Hence... Could you send the PDF to `secret...@apache.org` **ONLY**, please?

On Thu, Feb 1, 2024 at 11:59 AM Fred am Nil  wrote:

> Hi Volkan,
>
> I signed and attached the ICLA.
>
> Regards.
>
> Fred
>
> VY> Hello Fred,
>
> VY> Thank you so much for stepping up! It means a lot for the project. 🙏
>
> VY> We will follow the ASF committer admission process
> VY> <https://community.apache.org/newcommitter.html#new-committer-process>.
> You
> VY> already shared your GitHub ID. Would you also mind signing &
> submitting in
> VY> the Individual Contributor License Agreement (ICLA)
> VY> <https://www.apache.org/licenses/icla.pdf>, please? If you have
> already
> VY> done so, mind sharing your Apache ID(s)?
>
> VY> Cheers!
>
> VY> On Wed, Jan 31, 2024 at 12:01 PM Fred am Nil
> 
> VY> wrote:
>
> >> Hi,
> >>
> >> as proposed by Volkan Yazıcı in
> >>
> https://github.com/apache/logging-log4net/pull/103#issuecomment-1918677272
> >> I would like to become a maintainer of log4net.
> >>
> >> https://github.com/FreeAndNil
> >>
> >> Regards.
> >>
> >> Fred
> >>
> >>
>

[VOTE] Release Apache Log4j Scala 13.1.0

[Volkan Yazıcı]

This is a vote to release the Apache Log4j Scala 13.1.0.

Website: https://logging.staged.apache.org/log4j/scala
GitHub: https://github.com/apache/logging-log4j-scala
Commit: abf3b13d3692b45d221dc78202c34f00f8f9124f
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1257
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.

=== Reproducibility

As was the case in the previous `13.0.0` release, the
`log4j-api-scala_3.jar` artifact targeting Scala 3 in this
release is also not reproducible due to a bug in the
Scala 3 compiler. See `13.0.0` vote email[1] for details
and how to verify the reproducibility by working around
the Scala 3 compiler issue.

[1] https://lists.apache.org/thread/3rrg3xj2sk6m3chx82k8kpx6nbdqb8oz

=== 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 contains a bug fix, Software Bill of Materials
(SBOM) generation, and some dependency updates.

 Added

* Start generating CycloneDX SBOM

 Fixed

* Fix recursive inlining issues in Scala 3 macros (#40)

 Updated

* Update `org.apache.logging.log4j:log4j-bom` to version `2.22.1` (#43)
* Update `org.apache.logging:logging-parent` to version `10.6.0` (#44)

Re: log4net maintainers

[Volkan Yazıcı]

Hello Fred,

Thank you so much for stepping up! It means a lot for the project. 🙏

We will follow the ASF committer admission process
<https://community.apache.org/newcommitter.html#new-committer-process>. You
already shared your GitHub ID. Would you also mind signing & submitting in
the Individual Contributor License Agreement (ICLA)
<https://www.apache.org/licenses/icla.pdf>, please? If you have already
done so, mind sharing your Apache ID(s)?

Cheers!

On Wed, Jan 31, 2024 at 12:01 PM Fred am Nil 
wrote:

> Hi,
>
> as proposed by Volkan Yazıcı in
> https://github.com/apache/logging-log4net/pull/103#issuecomment-1918677272
> I would like to become a maintainer of log4net.
>
> https://github.com/FreeAndNil
>
> Regards.
>
> Fred
>
>

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

[Volkan Yazıcı]

*[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
> >
>
>

[log4j] `flapdoodle-embed` minor update breaks MongoDB tests

[Volkan Yazıcı]

Gary, the following `flapdoodle-embed` minor updates breaks the MongoDB
tests. Would you mind helping us to fix them, please?

   1. Bump `flapdoodle-embed.version` from `4.9.0` to `4.10.2` in `2.x` (
   #2202 )
   2. Bump `flapdoodle-embed.version` from `4.8.1` to `4.10.2` in `main` (
   #2199 )

Re: [log4j] Bump default status logger level to WARN

[Volkan Yazıcı]

I am in favor of reporting unrecognized/ignored properties, otherwise there
is no incentive for users to fix their configurations. Those who don't want
to be bothered with them, can still do so via
`-Dlog4j.StatusLogger.level=off`.

Shall we mention this issue (that is, ineffective configurations as the one
you shared about `bufferSize`-vs-`bufferedIo`) to Łukasz and see if he
would be willing to carry out that clean up? ... granted PMC agrees to
raise the default status logger level to WARN.

On Mon, Jan 22, 2024 at 2:34 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Mon, 22 Jan 2024 at 13:31, Volkan Yazıcı  wrote:
> > Piotr, could you share some examples of typical working configurations
> that
> > will start reporting errors? What kind of errors will these reports
> > contain? A message or a fully-blown stack trace? Will there be a
> multitude
> > of these? Or 1-2 occasional appearances?
>
> There are about 100 warnings in `log4j-core`. Most of them only occur
> if an error condition occurs, but it is fixed by the code.
> For example if a user has a properties configuration with a lot of
> unrecognized/ignored properties, a warning will be issued for each one
> of them.
>
> Some of these warnings are not fixable by the user, e.g. the "The
> bufferSize is set to {} but bufferedIo is false: {}" (bufferSize has
> always a value), but I am willing to go through the list of warnings
> and fix them.
>
> Piotr
>

Re: [log4j] Bump default status logger level to WARN

[Volkan Yazıcı]

Piotr, could you share some examples of typical working configurations that
will start reporting errors? What kind of errors will these reports
contain? A message or a fully-blown stack trace? Will there be a multitude
of these? Or 1-2 occasional appearances?

I know answers will vary dependending on the configuration. I am interested
in, let's say, typical Spring, Java application users with simple
`log4j2.xml`, `log4j2.yaml` files.

On Wed, Jul 26, 2023 at 12:14 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> In [1] Łukasz implemented the long-awaited bump of the default status
> logger level from ERROR to WARN.
>
> From my perspective this is a good change, since most configuration
> errors can be caught without setting `-Dlog4j2.debug=true`. On the
> other hand some users will complain that "working" configurations will
> start reporting errors on stderr now.
>
> What do you think about this?
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j2/pull/1592
>