[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: Context data propagation and logger-bound context data

[Matt Sicker]

https://docs.micrometer.io/context-propagation/reference/

This is more in line with what I was thinking we should support. I’m not 
suggesting that we add Micrometer as a dependency to the API or Core, but we 
can replicate the minimal API here or figure out a smaller API for integration 
purposes.

Note that similar projects like the OpenTelemetry context propagation API is 
geared toward cross-process context propagation, not cross-thread or similar 
lower level primitives. The low level primitives belong in Log4j IMO.


> On Mar 27, 2024, at 16:56, Ralph Goers  wrote:
> 
> Volkan,
> 
> No more hand waving. Please see 
> https://github.com/apache/logging-log4j2/pull/2419.
> 
> I should note that while implementing the classes I added to support this 
> makes it easier I did not have to make any changes to the logging internals 
> to make this work.
> 
> Ralph
> 
>> On Mar 22, 2024, at 1:45 AM, Volkan Yazıcı  wrote:
>> 
>> 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
>> javadoc.io
>> 
>> 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

Re: Context data propagation and logger-bound context data

[Piotr P. Karwasz]

Hi,

On Mon, 15 Apr 2024 at 18:44, Matt Sicker  wrote:

> Context Propagation support :: Micrometer Context Propagation
> 
> docs.micrometer.io
> 
> [image: favicon.ico]
> 
> 
>
> This is more in line with what I was thinking we should support. I’m not
> suggesting that we add Micrometer as a dependency to the API or Core, but
> we can replicate the minimal API here or figure out a smaller API for
> integration purposes.
>

I agree. To support `context-propagation` we don't need to add anything to
the API or SPI. To support it efficiently, we need the two methods from PR
[1].

Note that SLF4J is already supported by `context-propagation` (cf. [2]).

Piotr

[1] https://github.com/apache/logging-log4j2/pull/2442
[2] https://github.com/micrometer-metrics/context-propagation/pull/194

Re: Context data propagation and logger-bound context data

[Ralph Goers]

In theory that library could use the ContextData class I just added to get 
context data no matter how it got there. However, the Micrometer library’s 
setValue and getValue set and retrieve the full map, not values. That won’t 
play nice with a ScopedContext since once you set it you would immediately be 
leaving the context so what you set would be instantly forgotten. Under the 
covers of course it could push a new map on the queue but that would likely 
behave very differently than the way ScopedContext does - i.e. you are 
completely replacing maps not incrementally modifying them.

Ralph

> On Apr 15, 2024, at 10:07 AM, Piotr P. Karwasz  
> wrote:
> 
> Hi,
> 
> On Mon, 15 Apr 2024 at 18:44, Matt Sicker  > wrote:
>> Context Propagation support :: Micrometer Context Propagation
>> docs.micrometer.io
>> 
>>  Context 
>> Propagation support :: Micrometer Context Propagation 
>> 
>> docs.micrometer.io 
>> 
>> 
>> 
>> This is more in line with what I was thinking we should support. I’m not 
>> suggesting that we add Micrometer as a dependency to the API or Core, but we 
>> can replicate the minimal API here or figure out a smaller API for 
>> integration purposes.
> 
> I agree. To support `context-propagation` we don't need to add anything to 
> the API or SPI. To support it efficiently, we need the two methods from PR 
> [1].
> 
> Note that SLF4J is already supported by `context-propagation` (cf. [2]).
> 
> Piotr
> 
> [1] https://github.com/apache/logging-log4j2/pull/2442
> [2] https://github.com/micrometer-metrics/context-propagation/pull/194