Author lines in documentation

Can we remove author lines in documentation pages? These lines are becoming crowded and somehow IntelliJ IDEA formats author lines badly (i.e. inserts a blank line before them and they end up in the text. Of course this doesn't need to be a PMC decision: when I reformat a page I'll remove the

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

On Thu, 9 May 2024 at 14:40, 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 >

Re: Canonicalization of URLs on our website

Hi Volkan, On Wed, 8 May 2024 at 14:57, Volkan Yazıcı wrote: > 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. If we use a non-default `html_extension_style`, you can

Re: Canonicalization of URLs on our website

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

Integration between `log4j-jpl` and `log4j-jul`

Hi, I just discovered that JBoss LogManager implemented a very nifty feature[1] that integrates Java 9 System.Logger with `java.util.logging`. Since: * `System.Logger` is loaded using `ServiceLoader` * JUL's `LogManager` requires a `java.util.logging.manager` system property to be set on the

Closing inactive issues

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"

Re: Canonicalization of URLs on our website

Hi Volkan, On Sun, 21 Apr 2024 at 20:19, Volkan Yazıcı wrote: > > 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? There are `:relfileprefix:` and `:relfilesuffix:` attributes[1]

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

Hi Ralph, On Mon, 22 Apr 2024 at 03:35, Ralph Goers wrote: > > Did we make a decision on this? Since apparently there is consensus in the PMC, I opened an issue[1] and I am going to remove `log4j-1.2-api` from the `main` branch. Piotr [1] https://github.com/apache/logging-log4j2/issues/2461

Re: Canonicalization of URLs on our website

Hi Gary, On Sun, 21 Apr 2024 at 00:02, Gary Gregory wrote: > > I agree with Piotr. I prefer the simplest solution, pointing to > `index.html`, no guessing required. Personally I prefer the shortest one: * no www, * no `index.html`, * no `.html`. Piotr

Canonicalization of URLs on our website

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

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

Hi Gary, On Wed, 17 Apr 2024 at 21:23, Gary Gregory wrote: > But then your config has to say AND depend on the mongodb5 > module! Still confusing  There is actually a rarely used feature of our plugin system, where a plugin named `Foo` can actually create an object of type `Bar`. See for

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

Hi Gary, On Wed, 17 Apr 2024 at 18:45, Gary Gregory wrote: > Maybe if want to only use the latest driver for main, we should rename the > module and classes and drop the "4". That or go with what I initially > suggested. Your initial proposal of having a separate `log4j-mongodb4` and

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

Hi Gary, On Wed, 17 Apr 2024 at 16:36, Gary D. Gregory wrote: > > Hello All, > > In In 2.x, I would like to: > > - drop log4j-mongodb3 and > - add log4j-mongodb5 > - then do the same in 3.x > > Any objections? It is fine with me. Regarding log4j-mongodb5: MongoDB driver has already been

Re: Context data propagation and logger-bound context data

Hi, On Mon, 15 Apr 2024 at 18:44, Matt Sicker wrote: > Context Propagation support :: Micrometer Context Propagation > > docs.micrometer.io > > [image: favicon.ico] >

Re: Monitoring discards from async logging

Hi Adam, On Fri, 12 Apr 2024 at 21:42, Thomas, Adam wrote: > That sounds appealing, but do you have to have this hook registered by the > time the disruptor is set up? That's my fundamental concern with a lot of > these interception strategies - if your library/framework is called (which >

Re: Monitoring discards from async logging

Hi Volkan, On Thu, 11 Apr 2024 at 21:26, Volkan Yazıcı wrote: > *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

Re: Monitoring discards from async logging

Hi Adam, On Wed, 10 Apr 2024 at 19:03, Thomas, Adam wrote: > I would do this if I had control of the end user's logging setup. > Unfortunately, I vend an internal library that is used by a lot of different > teams. By the time my code is invoked, AsyncLoggerDisruptor has already read > the

Re: Monitoring discards from async logging

Hi Adam, On Wed, 10 Apr 2024 at 00:11, 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. Be reassured that we didn't forget about your PR, we just have a lot of changes going on to publish Log4j

Re: Should Log4j API bridges have a 3.x release?

Hi Ralph, On Tue, 9 Apr 2024 at 23:46, Ralph Goers wrote: > You are forgetting one small thing. Plugins in 3.x use ServiceLoader while > 2.x uses the Log4j2Plugins.dat file. While 3.x supports the old format it > will be much better for users to not have to use the transformer when >

Re: Should Log4j API bridges have a 3.x release?

Hi, On Tue, 9 Apr 2024 at 21:34, Piotr P. Karwasz wrote: > * `log4j-iostreams`, > * `log4j-jpl`, > * `log4j-jul`, > * `log4j-slf4j-impl`, > * `log4j-slf4j2-impl`, > * `log4j-to-jul`, > * `log4j-to-slf4j`. Don't get me wrong: these are very good artifacts, but I really d

Should Log4j API bridges have a 3.x release?

Hi all, Since Log4j Core 3.x moved to `log4j-api` 2.24.0, many artifacts that only depend on `log4j-api` became redundant in the 3.x branch: * `log4j-iostreams`, * `log4j-jpl`, * `log4j-jul`, * `log4j-slf4j-impl`, * `log4j-slf4j2-impl`, * `log4j-to-jul`, * `log4j-to-slf4j`. Right now the `3.x`

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

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

Logger context specific configuration and properties in 3.x

Hi all, I have some concerns at the naming strategy of per-context properties files documented in: https://logging.apache.org/log4j/3.x/manual/systemproperties The naming of the properties files seems dangerously close to that of configuration files: * configuration files are named

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

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

Re: Context data propagation and logger-bound context data

Hi Raman, On Thu, 21 Mar 2024 at 22:51, Raman Gupta wrote: > > > For example, a User could configure a custom MessageFactory that > > provides an extension of MapMessage that causes the message to include data > > from the class or resource. Going to the extreme of trying to shoehorn in > >

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

+1, release the artifacts. I repeated the same checks as in RC2: * distribution hashes: OK * distribution signatures: OK * Maven artifacts are reproducible: OK * Maven artifacts are the same as binary distribution: OK * new artifacts are documented on the website. Piotr On Thu, 21 Mar 2024 at

Re: Context data propagation and logger-bound context data

Hi Ralph, On Thu, 21 Mar 2024 at 07:03, Ralph Goers wrote: > > 1. Raman and Mikko would like to bind context data to an object > > implementing the `Logger` interface or more generally to a service > > object (e.g. resource manager, DAO and variants), > > Yes, I’ve seen that. Personally, I am

Re: Context data propagation and logger-bound context data

Hi Ralph, On Wed, 20 Mar 2024 at 17:11, Ralph Goers wrote: > > 1. I am experimenting with adding Thread support to ScopedContext as we > speak. It should be straightforward. > > I am not sure we ever want to deal with ScopedValue. ScopedContext provides > the same functionality plus

Re: Context data propagation and logger-bound context data

Hi Ralph, On Tue, 19 Mar 2024 at 07:45, Ralph Goers wrote: > 2. The links you provide describe the problem of passing contexts to threads > magnificently. Unfortunately, they solve it by requiring you NOT to use > standard JDK tooling for managing threads. I am not prepared to be dependent >

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

Hi Volkan, On Tue, 19 Mar 2024 at 12:35, 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 >

Re: [VOTE] Release Apache Log4j Tools 0.8.0

Hi Volkan, On Mon, 18 Mar 2024 at 22:25, 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 >

Context data propagation and logger-bound context data

Hi, Given the ongoing context data propagation in three Github issues/PRs/discussions (cf. [1], [2] and [3]). I think we should move the debate to the mailing list, which guarantees the maximal reachout. == Problem summary We have two different problems regarding context data in log files: 1.

Re: [VOTE] Release Apache Log4net 2.0.16

Hi Davyd, On Fri, 8 Mar 2024 at 14:59, Davyd McColl wrote: > > I'll try to remember that for the future. From memory now, there was > only one person who had any holdups and that was due to outdated build > docs from me - so it should be resolved. There were no -1's, and at > least 4 +1's that I

Re: [VOTE] Release Apache Log4j 2.23.1

On Wed, 6 Mar 2024 at 14:13, 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:

Re: Removal of 2.3.x and 2.12.x websites (was: Clean site repo)

Hi Volkan, On Tue, 5 Mar 2024 at 08:52, Volkan Yazıcı wrote: > > 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

Re: Removal of 2.3.x and 2.12.x websites (was: Clean site repo)

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 w

Removal of 2.3.x and 2.12.x websites (was: Clean site repo)

Hi all, On Mon, 19 Feb 2024 at 10:34, Volkan Yazıcı wrote: > > 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

Re: Checksum of release 2.23.0 does not seem to be correct

Hi Ralph, On Fri, 1 Mar 2024 at 15:33, Ralph Goers wrote: > > Maybe we should replace the links on the web page? There are actually > > people (like me and probably you) that don't download everything > > through the browser. > > What do you think? > > Replace them with what? We are required to

Re: Checksum of release 2.23.0 does not seem to be correct

Hi Piers, On Fri, 1 Mar 2024 at 14:14, Piers Uso Walter wrote: > Thanks for the quick response. > And yes, everything is OK on your side. > > I did indeed somehow manage to download the HTML file as the zip archive. > That explains why the checksum was wrong. > > How embarrassing:-( I did the

Re: Checksum of release 2.23.0 does not seem to be correct

Hi Piers, On Fri, 1 Mar 2024 at 13:33, Piers Uso Walter wrote: > I downloaded log4j 2.23.0 from > https://logging.apache.org/log4j/2.x/download.html > Specifically I downloaded > https://www.apache.org/dyn/closer.lua/logging/log4j/2.23.0/apache-log4j-2.23.0-bin.zip > > The checksum file >

Re: [log4net] Next release

Hi Davyd, On Thu, 29 Feb 2024 at 12:29, Davyd McColl wrote: > 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 This is just a

Re: Clean site repo

Hi Matt, On Mon, 26 Feb 2024 at 23:08, Matt Sicker wrote: > > Must be a relic from when we used Subversion to publish the website instead > of Git. Maybe ask Infra? It is done: https://issues.apache.org/jira/browse/INFRA-25550 Piotr

Re: Clean site repo

Hi Matt, On Mon, 26 Feb 2024 at 18:49, Matt Sicker wrote: > > The /log4j/2.0/ link is because 2.0 is a symbolic link to 2.x, and 2.x is a > symbolic link to the latest release (or at least that’s how it was set up > originally). The links can probably use .htaccess rewrite rules instead. I

[ANNOUNCE] Apache Log4j 2.23.0 released

The Apache Log4j team is pleased to announce the 2.23.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

[ANNOUNCE] Apache Log4j 3.0.0-beta2 released

The Apache Log4j team is pleased to announce the 3.0.0-beta2 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.)

Re: Clean site repo

Hi, On Mon, 19 Feb 2024 at 10:34, Volkan Yazıcı wrote: > > 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

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

Hi, On Sun, 18 Feb 2024 at 09:06, 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: 086db24a04f905b40649666aafe3bb4778a75

Re: [VOTE] Release Apache Log4j 2.23.0 RC1

Hi, On Sat, 17 Feb 2024 at 14:14, Piotr P. Karwasz wrote: > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... And here is my +1. The vote passes with three binding +1, from Gary, Volkan and me. I

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

Hi Ralph, On Mon, 19 Feb 2024 at 05:03, Ralph Goers wrote: > > Just navigate to https://archive.apache.org/dist/logging/ and take a look. > Note that under log4j you will find version directories. Under log4j-audit > you will not find directories. Basically it is however they get added to >

Distribution location was: [VOTE] Release Apache Log4j 3.0.0-beta2 RC1

Hi Gary, On Sun, 18 Feb 2024 at 15:12, Gary Gregory wrote: > Note that the verification instructions below or the distro process or > both need changes because the wget and all commands get EVERYTHING and > work on EVERYTHING, which in this case means that BOTH release > candidates for 2.23.0

[VOTE] Release Apache Log4j 3.0.0-beta2 RC1

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:

Re: [VOTE] Release Apache Log4j 2.23.0 RC1

Hi all, > # Run build and verification > ./mvnw clean verify -Prelease > -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1258 It should be: ./mvnw clean verify artifact:compare -Prelease \

[VOTE] Release Apache Log4j 2.23.0 RC1

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:

Re: Version 2.23.0 release schedule

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

Re: [log4j] Remove `` in `main`

Hi Ralph, On Wed, 14 Feb 2024 at 04:35, Ralph Goers wrote: > 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

Usage examples of flow messages

Hi all, Our Logger interface contains 11 traceEntry/traceExit methods and 4 deprecated entry/exit methods. As far as I have seen, only the deprecated ones are documented in [1]. I understand the purpose of some of them: * entry(Object...) and its vararg-free version entry() can be used to log

Re: [VOTE] Move Chainsaw to dormant

+1 Piotr On Mon, 12 Feb 2024 at 22:32, 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

Re: [log4j] Remove `` in `main`

Hi Volkan, On Mon, 12 Feb 2024 at 20:30, Volkan Yazıcı wrote: > `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 >

Re: Version 2.23.0 release schedule

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

Version 2.23.0 release schedule

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

Re: Using the Log4j 1.2 bridge.

Hi Gary, On Sun, 11 Feb 2024 at 16:20, Gary Gregory wrote: > > To make sure I understand, you are saying the bug is in > org.apache.logging.log4j.core.Logger.setLevel(Level)? Yes, this method does not modify the `LoggerConfig`, so the children of the logger will not see the level change. It

Re: Using the Log4j 1.2 bridge.

Hi Gary, On Sat, 10 Feb 2024 at 18:14, Gary Gregory wrote: > In my branch > https://github.com/garydgregory/commons-logging/tree/log4j1-log42-api > I have test failures where all 6 events are logged instead of 4 by the > existing test that calls (mvn clean verify): Unexpected number of log >

Re: New committer: Fred am Nil (`freeandnil`)

Welcome, Jan! On Fri, 9 Feb 2024 at 20:07, Volkan Yazıcı wrote: > > 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

Re: Clean site repo

Hi Volkan, On Wed, 7 Feb 2024 at 11:05, Volkan Yazıcı wrote: > 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 >

Re: Clean site repo

Hi Ralph, On Tue, 6 Feb 2024 at 17:47, Ralph Goers wrote: > > When you say “hard to work with it” what does that mean? All that should ever > be required is to do I am mostly concerned by the great amount of files on the website. Most of them are hidden, since we don't provide links to

Clean site repo

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

Re: Revamp of asynchronous logging

Hi Matt, On Mon, 5 Feb 2024 at 22:37, Matt Sicker wrote: > > For #3, I agree that we should perform formatting on the application thread > before transferring control to an asynchronous thread. I am not sure if we always need to format the message (the `log4j2.formatMsgAsync` property and and

Re: [VOTE] Release Apache Log4j Scala 13.1.0

Hi Volkan, On Thu, 1 Feb 2024 at 11:32, 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 >

Revamp of asynchronous logging

Hi all (and especially Remko), Lately I spent some time looking at the asynchronous logger/logger config and I think it could profit from some refactoring in 3.x. The problems I am seeing are: 1. The disruptors of `AsyncLogger` and `AsyncLoggerConfig` use different structures. The disruptor of

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

Hi Volkan, On Mon, 5 Feb 2024 at 20:13, Volkan Yazıcı wrote: > 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

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

Hi Volkan, On Mon, 5 Feb 2024 at 16:18, Volkan Yazıcı wrote: > 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. >

Re: [log4j] performance issue 2.22.1 vs. 2.22.0

Hi Ralph, On Mon, 29 Jan 2024 at 20:45, Ralph Goers wrote: > It is pretty obvious that the change you made has dire consequences. I don't dispute that. ;-) I just want to make sure it is the **only** thing that killed performance. As Andreas says, only a couple of events are logged. If the

Re: [log4j] performance issue 2.22.1 vs. 2.22.0

Hi Andreas, On Mon, 29 Jan 2024 at 18:45, wrote: > Note, this happens even though effectively just two lines are really logged. > If DEBUG or TRACE were enabled in the loggers, then tens if not hundreds of > thousands of lines would be logged - so definitely, > there is a lot of logging going

Re: Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

Hi Ralph, On Tue, 16 Jan 2024 at 01:59, Ralph Goers wrote: > > I am OK with this. It would be best if we could get Tomcat to publish a > tomcat-log4j artifact. I proposed this two years ago to Tomcat, but they were not willing to take over the artifact:

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

Hi Volkan, On Tue, 23 Jan 2024 at 09:15, Volkan Yazıcı wrote: > > 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

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

Hi Matt, On Mon, 22 Jan 2024 at 19:35, Matt Sicker wrote: > > There was also the idea that if we introduce some form of a v3 API, it’ll be > alongside the existing v2 API, not a breaking change. Yes, that idea has also a PoC: https://github.com/apache/logging-log4j2/pull/2215 However right

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

Hi Volkan, On Mon, 22 Jan 2024 at 15:15, Volkan Yazıcı wrote: > 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

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

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

Re: interesting writeup of some nice engineering

Hi Remko, On Thu, 18 Jan 2024 at 23:16, Remko Popma wrote: > > https://www.uber.com/en-JP/blog/reducing-logging-cost-by-two-orders-of-magnitude-using-clp/ > > tldr: > Uber created a CLP > > appender for log4j that

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

Hi Ralph, On Thu, 18 Jan 2024 at 18:18, Ralph Goers wrote: > > Besides we already broke their code, when 2.7 introduced breaking > > changes to ConfigurationFactory. > > ? The contribution I made was done last year - long past 2.7. Yes, what I meant is that Spring Boot uses some Log4j Core

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

Hi Ralph, On Thu, 18 Jan 2024 at 16:15, Ralph Goers wrote: > Note that LogManager has > > import org.apache.logging.log4j.simple.SimpleLoggerContextFactory; > import org.apache.logging.log4j.spi.LoggerContext; > import org.apache.logging.log4j.spi.LoggerContextFactory; > import

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

Hi Ralph, On Thu, 18 Jan 2024 at 15:56, Ralph Goers wrote: > Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean > anything impacted by the property changes would have to be in the spi or > abstracted to reference something in the spi. I am assuming a log4j-spi-2.x > would

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

Hi Volkan, On Wed, 17 Jan 2024 at 17:12, Volkan Yazıcı wrote: > Given Ralph and Piotr are strongly opinionated about keeping > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` > instead? The main

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

Hi Ralph, On Tue, 16 Jan 2024 at 01:56, Ralph Goers wrote: > > I don’t understand what it means to keep both staging and publish in > “asf-site”. By definition, the asf-site branch is the live web-site and > asf-staging is the staging web site. Are you talking about the build scripts > or

Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

Hi all, While 3.x is approaching its first stable release as a meteor burning through the sky, its core is getting smaller as it approaches earth. That is why I would propose to remove two further modules from 3.x: * The functionality of `log4j-jcl` is included in `commons-logging` version

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

Hi Volkan, On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı wrote: > > * you can stage the website for a release with a simple: > > > > git checkout asf-staging > > git reset --hard asf-site > > unzip ... > > git push -f > > > > You can do the same in the existing setup too. You just need a `sed` >

Re: Website repos/branches (again)

On Mon, 15 Jan 2024 at 10:40, Volkan Yazıcı wrote: > > -1 on merging multiple websites to a single repository. > > I think documentation should reside in the same repository where sources > are. I already implemented this for *almost* every repository: > > logging-parent > logging-log4j-tools >

[ANNOUNCE] Apache Logging Parent 10.6.0 released

Apache Logging Parent team is pleased to announce the 10.6.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]. === Release Notes This minor release contains several

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

Hi Volkan, On Mon, 15 Jan 2024 at 09:28, Volkan Yazıcı wrote: > Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"* > practice in `logging-parent` too. I find this new setup > >- *confusing* – Previously, say, `asf-site` related configuration was >only in the

Website repos/branches (again)

Hi, As we discussed yesterday the way our website is created from multiple repos and branches is somehow incoherent: some parts of the website have separate repos, other parts have a branch in a code repo, other parts have a branch in a website repo. For example: * the `/log4j/jakarta`

Re: [VOTE][LAZY] Release Apache Logging Parent 10.6.0 RC1

Hi, On Thu, 11 Jan 2024 at 13:42, Piotr P. Karwasz wrote: > 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 neg

[VOTE][LAZY] Release Apache Logging Parent 10.6.0 RC1

This is a lazy-vote to release the Apache Logging Parent 10.6.0. Website: https://logging.staged.apache.org/logging-parent GitHub: https://github.com/apache/logging-parent Commit: 64ae84e05803f3ab6d4201512b00f1cb1c4051e8 Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent

Re: Spring 3 and Log4j 3

Hi Ralph, On Thu, 11 Jan 2024 at 01:38, Ralph Goers wrote: > I fixed two bugs. One was reported against 2.x ages ago. The second was first > reported in the Spring issue. > > Yes, they can be ported to 2.x but if we release 3.0.0 in the next couple of > months I would prefer to tell users just

Removal of `log4j-jcl` in `3.x`

Hi all, Since `commons-logging` 1.3.0 was published last month and it supports Log4j API out-of-the-box, does it still make sense to keep `log4j-jcl` around in 3.x? I would keep the 2.x version, so that users don't need to modify their stacks. However we might assume that 3.x adopters are

Re: Spring 3 and Log4j 3

Hi Matt, On Wed, 10 Jan 2024 at 18:45, Matt Sicker wrote: > > This might affect 2.x, though it’s largely in the Spring environment property > source. Given the application lifecycle there, Spring doesn’t seem to remove > its own closed property sources at shutdown, hence the exception. The

Re: Spring 3 and Log4j 3

Hi Ralph, On Tue, 9 Jan 2024 at 22:45, Ralph Goers wrote: > > FYI - in > https://github.com/spring-projects/spring-boot/issues/33450#issuecomment-1883014368 > has confirmed that Log4j 3.0.0-beta1 now works correctly with Spring 3.x. Are you planning to backport that patch or is it specific to

Properties configuration factory

Hi all, As an experiment, I added an alternative implementation of a properties configuration factory yesterday[1]. It is Jackson-based and uses whatever mapping is provided by `jackson-dataformat-text`. As a result the resulting configuration file seems much more coherent to me (cf. [3]). If a

Re: `a.o.l.l.core.parser` package removal

Hi Mikael, On Sun, 7 Jan 2024 at 10:38, Mikael Ståldal wrote: > What about (re)moving the classes which actually depends on Jackson > (AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser, > YamlLogEventParser), but keeping the interfaces (LogEventParser, > TextLogEventParser,

Dependency management style

Hi all, Following the discussion in PR#2166, I would like to change the dep management convention I mentioned in 2022. On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz wrote: > It would be also nice to synchronise the `pom.xml` of `release-2.x` > and `master`. Since the main `pom.xml` has

  1   2   3   4   5   >