[ANNOUNCE] Apache Log4j Tools 0.8.0 released
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)
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: [VOTE] Release Apache Log4j Tools 0.8.0 (RC3)
+1 Validated checksums, signatures, reproducible build. Small note: NOTICE.txt should get an updated copyright year, but not a blocker. > On Mar 21, 2024, at 10:42, 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
> 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.
I am working on this Volkan and with real code. It will be included in my PR
branch shortly. You simply have to be patient.
Ralph
Re: Context data propagation and logger-bound context data
Hi Volkan, On Fri, 22 Mar 2024 at 09:45, Volkan Yazıcı wrote: > *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.) > You can also Google "log4j javadoc" now! Apparently our 301 HTTP redirects are working and Google does not index `/log4j/log4j-2.3.4` any more, but the redirected resource. Piotr
Re: Context data propagation and logger-bound context data
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
>
> [image: fb2db6ea7688d54ae047109e0d71e3a0-favicon-32.png]
>
>
>
> 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 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 provide
Re: Context data propagation and logger-bound context data
Hi Ralph, On Fri, 22 Mar 2024 at 03:08, Ralph Goers wrote: > > On Mar 21, 2024, at 3:19 PM, Piotr P. Karwasz > > wrote: > > > > > > PS: In the `main` branch I plan to replace the default > > ReusableMessageFactory with ReusableLogEventFactory: > > > > * this change should have a minimal impact on memory (events are not > > much larger than messages), > > * it can skip a data transfer between ReusableMessage and MutableLogEvent, > > * it allows the message factory to collect data that is usually > > reserved for events. > > I have to question this. I don’t understand the concept of replacing a > MessageFactory with a LogEventFactory. They are completely different things. > What does this even mean? We already have two `LogEvent` implementations `MutableLogEvent` (used by `ReusableLogEventFactory`) and `RingBufferLogEvent` that also implement `ReusableMessage`. I plan to merge the two `ReusableMessageFactory` and `ReusableLogEventFactory` classes into a single entity that will produce objects of a single type: `MutableLogEvent`. Currently the default Log4j Core 3.x configuration has 4 object pools: one for `ReusableSimpleMessage`, one for `ReusableObjectMessage`, one for `ReusableParameterizedMessage` and one for `MutableLogEvent`. After the changes only one pool will remain. Piotr
