Re: Context data propagation and logger-bound context data

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 Jav

Re: Better Javadoc/Impl for org.apache.logging.log4j.core.Layout.getContentType()

We’ve got nullability annotations now, so we should be defining them. For use cases like this, I’d examine how existing things work and then document the nullability as such. For new code, I prefer things to be non-null except for cases where it makes sense to use null rather than, say, passing

Re: Monitoring discards from async logging

We’ve got a new proposal from Piotr on this front now which sort of emulates his suggestion for 3.x but applied to 2.x (since that doesn’t have the DI system). I like the approach there as it provides enough of a hook for users to customize whatever metrics library they wish to enhance some

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:

Re: Context data propagation and logger-bound context data

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

Re: Clean site repo

Must be a relic from when we used Subversion to publish the website instead of Git. Maybe ask Infra? > On Feb 26, 2024, at 12:05, Piotr P. Karwasz wrote: > > Hi Matt, > > On Mon, 26 Feb 2024 at 18:49, Matt Sicker wrote: >> >> The /log4j/2.0/ link is because 2.

Re: Clean site repo

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. > On Feb 21, 2024, at 04:44, Piotr P. Karwasz wrote: > > Hi, > > On

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

I think it’s a good idea, especially since Jira registrations are closed. > On Feb 13, 2024, at 02:20, Volkan Yazıcı wrote: > > Log4j has deprecated JIRA in favor of GitHub Issues and enabled GitHub > Discussions as an alternative (not replacement!) to mailing lists. So far > it has been a

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

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

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

Welcome, Fred! > On Feb 9, 2024, at 13:06, 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: Revamp of asynchronous logging

For #3, I agree that we should perform formatting on the application thread before transferring control to an asynchronous thread. > On Feb 5, 2024, at 14:49, Piotr P. Karwasz wrote: > > Hi all (and especially Remko), > > Lately I spent some time looking at the asynchronous logger/logger >

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

. >> This >>>> could cause the OOM error. Truncating it in a layout simply limits how >> much >>>> of the String is printed. Even Gary’s proposal of calling substring() is >>>> still going to operate on the whole String. He would really need a >> method >>

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

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

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

I like this idea, Piotr. > On Jan 22, 2024, at 12:28 PM, Piotr P. Karwasz > wrote: > > 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

Re: interesting writeup of some nice engineering

I’m not sure if it’s a binary layout, but OpenTelemetry does define some standard formats and protocols around transferring and collecting log data. Any sort of binary layout would require some level of tooling support to be useful. > On Jan 19, 2024, at 3:12 AM, Volkan Yazıcı wrote: > > I

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

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. > On Jan 21, 2024, at 1:32 PM, Volkan Yazıcı wrote: > > *Abstract:* There will not be a Log4j 3 API. Both Log4j 2 and Log4j 3 will > implement the Log4j 2 API. >

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

That might work, yeah. > On Jan 17, 2024, at 12:46 PM, Volkan Yazıcı wrote: > > We can move the spi package content in main to a separate module in main. > SPI problem is solved? > > On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote: > >> I suspect this won

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

Or if we back port any of those changes I’ll propose, then perhaps we can continue with the API at 2.x. That does require that the API target Java 8, though. > On Jan 17, 2024, at 11:32 AM, Matt Sicker wrote: > > I suspect this won’t work that well once I’ve implemented > https:

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

I suspect this won’t work that well once I’ve implemented https://github.com/apache/logging-log4j2/issues/1977 as the current provider SPI is fairly lacking. It might make more sense to release the main API as 3.0.0 and have 2.x depend on the updated API. > On Jan 17, 2024, at 10:11 AM, Volkan

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

Agreed that we can add things back later if needed. +1 > On Jan 15, 2024, at 3:02 PM, Volkan Yazıcı wrote: > > +1 > > Allow me to remind everyone that anything that is removed from `3.0.0` can > be added again in a follow up minor release, if need arises. Hence, no need > to be overcautious. >

Re: Website repos/branches (again)

I love this idea, Volkan! > On Jan 15, 2024, at 3:40 AM, 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: > >

Re: Spring 3 and Log4j 3

Oh, in that case, assuming it’s a bug in log4j 2.x as well, then yes, seems worth fixing. > On Jan 10, 2024, at 12:29 PM, Piotr P. Karwasz > wrote: > > Hi Matt, > > On Wed, 10 Jan 2024 at 18:45, Matt Sicker wrote: >> >> This might affect 2.x, though it’s lar

Re: Spring 3 and Log4j 3

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 issue was only reported against Spring 3, though. > On Jan 10, 2024,

Re: Dependency management style

I like this idea. > On Jan 8, 2024, at 4:09 AM, Piotr P. Karwasz wrote: > > 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

Re: (logging-log4j2) branch main updated: Fix compilation error

Thanks for fixing this. This formatting change got swept up in a branch of mine you already reviewed. > On Jan 2, 2024, at 10:10 AM, pkarw...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > pkarwasz pushed a commit to branch main > in repository

Re: Nullability annotations

Nullability annotations are trivial to remove. I’ve added some basic aliases for them in main. As it stands, they’re copies of the four JSpecify annotations with those annotations applied to them along with equivalent JSR 305 meta-annotations to make the annotations function the same in

Re: [VOTE] Release log4cxx 1.2.0-RC1

+1 Same checks as Volkan. Platform build info: cmake version 3.28.1 GNU Make 3.81 Apple clang version 15.0.0 (clang-1500.1.0.2.5) Target: arm64-apple-darwin23.2.0 Thread model: posix pkg-config: 0.29.2 apr-1: 1.5.2 apr-util-1: 1.5.4 EXPAT: 2.5.0 — Matt Sicker > On Dec 28, 2023, at 18

Re: Reproducibility checks

emails. — Matt Sicker > On Dec 27, 2023, at 08:10, Piotr P. Karwasz wrote: > > Hi Gary, > > On Wed, 27 Dec 2023 at 13:58, Gary Gregory wrote: >> Please include whatever instructions you want folks to run in the vote >> email to prove reproducibility. Then at least we ca

Re: [VOTE] Release Apache Log4j 2.22.1 RC1

While there appears to be some issues with the reproducibility of the build, it appears to be inconsequential. +1 — Matt Sicker > On Dec 22, 2023, at 12:00, Piotr P. Karwasz wrote: > > This is a vote to release the Apache Log4j 2.22.1. > > Website: https://logging.staged.apach

Re: [VOTE] Release Apache Log4j Kotlin API 1.4.0

And my +1. With this, the vote passes with 4 +1 votes from myself, Volkan, Piotr, and Gary. — Matt Sicker > On Dec 24, 2023, at 09:57, Gary Gregory wrote: > > +1 > - Tested src zip file > - ASC OK > - SHA512 OK > - Building 'mvn clean verify' OK > - Usi

Re: [VOTE] Release Apache Log4j 3.0.0-beta1 (RC2)

+1 I’ll note that the reproducibility check fails on log4j-bom this time, but not a blocker. > On Dec 19, 2023, at 3:00 PM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j 3.0.0-beta1 RC2. > > Website: https://logging.staged.apache.org/log4j/3.x > GitHub:

Re: [VOTE] Release Apache Log4j Kotlin API 1.4.0

ng-1251 > (Matt, there is a warning about this in the release instructions. ) > > On Wed, Dec 20, 2023 at 7:08 PM Matt Sicker wrote: > >> This is a vote to release the Apache Log4j Kotlin API 1.4.0. >> >> Website: https://logging.staged.apache.org/log4j/kotlin >> Git

[VOTE] Release Apache Log4j Kotlin API 1.4.0

This is a vote to release the Apache Log4j Kotlin API 1.4.0. Website: https://logging.staged.apache.org/log4j/kotlin GitHub: https://github.com/apache/logging-log4j-kotlin Commit: ee2d4a8efa16bb2223252329531c94e98ed6d1e6 Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

+1 > On Dec 18, 2023, at 2:45 PM, Matt Sicker wrote: > > We can review this without doing a reproducibility check. The signatures of > everything look good; just doing some final validations before voting. > >> On Dec 18, 2023, at 6:38 AM, Gary Gregory wrote: >

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

We can review this without doing a reproducibility check. The signatures of everything look good; just doing some final validations before voting. > On Dec 18, 2023, at 6:38 AM, Gary Gregory wrote: > > Since Piotr asked for a fix and Matt can reproduce the issue, I'm not going > to take the

Re: [log4j] Revamping Log4j website & manual

I’d be interesting in helping with this, particularly around plugin development docs which are somewhat anemic. I’ve got several things to document in a non-API-doc fashion from the new DI system and such, too. > On Dec 18, 2023, at 1:13 PM, Volkan Yazıcı wrote: > > *TLDR:* Log4j websites &

Re: All-in-one site documentation

This is pretty cool! > On Dec 18, 2023, at 11:37 AM, Gary D. Gregory wrote: > > Hi All, > > A while back, I mentioned that we could (not should) have our documentation > generated within Javadoc. Here is an example from another Apache project I > participate in: > >

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

> On Dec 14, 2023, at 3:08 PM, Volkan Yazıcı wrote: > > Given we will have several other betas before a GA release, do these issues > really constitute a serious blocker? Or they can be addressed in the next > beta? > I can’t run the release verification commands you provided without this fix

Re: [log4j-kotlin] Next release (`1.3.1`-vs-`1.4.0`)

Thanks for the info! I don’t think you’re being pedantic here; the uniform release process is very important to keeping all our components healthy. > On Dec 7, 2023, at 4:54 AM, Volkan Yazıcı wrote: > > Raman, Matt, great that you want to release the next version of the Log4j > Kotlin! Thanks

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

I think it makes sense to default to a supported version, and we can take a manual look at what’s required in updates as new Java versions come out rather than letting random users find out by accident. > On Dec 5, 2023, at 6:49 AM, Volkan Yazıcı wrote: > > I disagree with having an

Re: Logstash and Filebeat guaranteed delivery

Right, I think I misread that. However, that’s what the curation idea is for :) — Matt Sicker > On Dec 1, 2023, at 18:47, Gary Gregory wrote: > > Of course RE Volkan, my first sentence must have been poorly written. I > meant to say that I know who Volkan is and that he is great,

Re: [Flume] Integration with OpenTelemetry

> On Nov 30, 2023, at 12:13 PM, Christian Grobmeier > wrote: > > Please do. I would also like to learn more about this stuff and maybe we can > make Chainsaw to receive Flume messages or OTel things too! I think that would make sense. When I do a deeper review of OpenTelemetry, I’ll suggest

Re: Logstash and Filebeat guaranteed delivery

I may be biased, but I wouldn’t consider Volkan a random GitHub user! However, that does raise an interesting point: we could link to third party plugins and such to help curate it. > On Dec 1, 2023, at 5:00 AM, Gary Gregory wrote: > > Hi all, > > (Don't take his the wrong way Volkan ;-) >

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

No, only that it requires Java 17 to build. It still targets the Java 8 release profile. > On Nov 30, 2023, at 11:15 AM, Gary Gregory wrote: > > Nice! That means that 2.23.0 will require Java 17 at runtime right? > > Gary > > > On Thu, Nov 30, 2023, 11:05 AM Volkan Yazıcı wrote: > >>

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

Sounds great! We even finally updated Spinnaker this week to build on Java 17, so great timing. — Matt Sicker > On Nov 30, 2023, at 10:03, Volkan Yazıcı wrote: > > Heads up! #2021 <https://github.com/apache/logging-log4j2/pull/2021> bumps > the `2.x` baseline to Java 17

Re: [Flume] Integration with OpenTelemetry

Oh yes, I’d still love to see how we can adapt the Log4j plugin system here! And yeah, this would likely make sense as its own repository. I’ll make a proposal about the OTel stuff before working on any code. — Matt Sicker > On Nov 29, 2023, at 22:54, Ralph Goers wrote: > > This i

[Flume] Integration with OpenTelemetry

One of the main reasons why I supported Flume joining this PMC was that I noticed it has significant overlap with projects in the observability space despite not being advertised as such. For example, the project FluentBit is extremely similar to Flume, but its main purpose is for collecting,

Re: [log4j] Unstable tests on Windows

There’s a JUnit annotation `@Issue` or something like that (Spock has a similar annotation) which you can use for linking to an issue. Otherwise, adding `@Tag` annotations allows for arbitrary tags (of which we use several already such as “functional” and “sleepy”). > On Nov 28, 2023, at 5:55 

Re: [log4j] Releasing Log4j `3.0.0`

I’m good with a beta release to come soon. I’m still working on a branch to fix up the remaining SPI updates to avoid guessing at ClassLoaders, but that isn’t required for a beta release. As for the branches, if 2.x was made into 3.0, then main would be 4.0, and where would that leave us? Back

Re: Optional dependencies and JPMS

Small changes to that: * Should move the XML configuration format to its own module, too, for the java.xml dependency * Should remove the Jackson JSON configuration format as we have a dependency-free JSON format in core (the YAML format support is based on the Jackson JSON support, so this

Re: Change semantics of `Throwable` parameters

returns this builder class). — Matt Sicker > On Nov 23, 2023, at 03:31, Piotr P. Karwasz wrote: > > Hi Matt, > > On Tue, 21 Nov 2023 at 23:22, Matt Sicker wrote: >> >> This sounds like it might be a good basis for figuring out a parallel v3 API >> for a “hard to

Re: Disable new issues in JIRA

I’d like it if we could copy over open issues to GH. — Matt Sicker > On Nov 24, 2023, at 07:12, Piotr P. Karwasz wrote: > > Hi all, > > Since we switched to Github Issues, I rarely look at JIRA any more and > certainly I do not expect to see new issues being posted there.

Re: [log4j] Unstable tests on Windows

already with the modules there, but we can still break out more modules that involve more complicated refactoring). [0]: https://github.com/google/jimfs — Matt Sicker > On Nov 20, 2023, at 08:40, Gary Gregory wrote: > > The GH CI builds on every push (as opposed to commi) IIRC. > > G

Re: Change semantics of `Throwable` parameters

as structured log messages, something that is awkward to use in the API at the moment. — Matt Sicker > On Nov 21, 2023, at 08:16, Piotr P. Karwasz wrote: > > Hi, > > Profiting from release 3.x we could slightly change the interpretation > of throwable parameters used in logging

Re: [PR] Bump org.junit:junit-bom from 5.10.0 to 5.10.1 [logging-log4j-jakarta]

is a new > repo, it doesn't have the proper settings. > > -Robert Middleton > > On Wed, Nov 15, 2023 at 12:56 PM Matt Sicker wrote: >> >> Why do our email settings keep getting reset? Do we have some default >> settings somewhere? >> >>>

Re: [PR] Bump org.junit:junit-bom from 5.10.0 to 5.10.1 [logging-log4j-jakarta]

Why do our email settings keep getting reset? Do we have some default settings somewhere? > On Nov 15, 2023, at 6:19 AM, dependabot[bot] (via GitHub) > wrote: > > > dependabot[bot] opened a new pull request, #1: > URL: https://github.com/apache/logging-log4j-jakarta/pull/1 > > Bumps

Re: Code reformatting

We have our great deletion branch I started to collaborate with you, though I can merge that beforehand. > On Nov 15, 2023, at 1:53 AM, Piotr P. Karwasz wrote: > > Hi all, > > On Wed, 8 Nov 2023 at 09:05, Volkan Yazıcı wrote: >> Piotr, it has been two months or so since we are discussing

Re: OSGi package versioning

It’s similar to the compatible API versions, but the BND equivalent here would be the highest package version of all the packages in log4j-api (since the packages don’t get split out from the modules in practice). — Matt Sicker > On Nov 13, 2023, at 16:02, Piotr P. Karwasz wrote: > >

Re: [log4j] `2.22.0` release

Go for it! I love how streamlined our release process is now. :) — Matt Sicker > On Nov 13, 2023, at 08:22, Volkan Yazıcı wrote: > > I would like to do the Log4j `2.22.0` release in a couple of days; > there are some bug fixes and SBOM is ready to be shipped. Let me know &

Upcoming changes to main for Log4j 3.x

Message and LogEvent objects, though this is largely an implementation detail until we expose the Recycler API for more general reuse. What else have I missed in this email? — Matt Sicker

Re: Vulnerability Disclosure Report (VDR)

Very neat! Thanks for getting this started. > On Nov 8, 2023, at 9:49 AM, Volkan Yazıcı wrote: > > Today I have published the CycloneDX Vulnerability Disclosure Report (VDR) > Piotr and I have been working on. > This VDR is expected to contain all CVEs

Re: [log4j] Security page refactoring

Actually, I was able to review this just now during the lunch break. > On Nov 7, 2023, at 1:24 PM, Matt Sicker wrote: > > Also note that I’m at KubeCon right now, so I won’t have a chance to review > this PR until, well, sometime during the conference. Possibly today, but >

Re: [log4j] Security page refactoring

Also note that I’m at KubeCon right now, so I won’t have a chance to review this PR until, well, sometime during the conference. Possibly today, but likely within the next day or two. > On Nov 6, 2023, at 2:17 PM, Volkan Yazıcı wrote: > > I have created #1948

Re: [log4j] Security page refactoring

Not that it’s relevant to adopt right away, but do note that there is a CVSS 4.0 now (that was finished quite recently) which is supposed to produce more useful severity scores. > On Nov 6, 2023, at 2:17 PM, Volkan Yazıcı wrote: > > I have created #1948

Re: Deterministic formatter

In the worst case scenario, we can still format from maven before committing (which is what I used to do before finding that there were IntelliJ plugins for this). In fact, I have to do that all the time lately anyways by running `mvn spotless:apply`. > On Nov 6, 2023, at 9:00 AM, Carter Kozak

Re: [log4j] What is JPMS support and its state

the little things that went into that. — Matt Sicker > On Nov 7, 2023, at 05:31, Piotr P. Karwasz wrote: > > Hi Ralph, > >> On Tue, 7 Nov 2023 at 05:05, Ralph Goers wrote: >> Next, there is a good chance that users really using JPMS won’t be able to >> access any

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

I added @InternalApi to all the classes that were marked “consider this class private”. As for the plugins, yes, now that we’ve got that stabilized, I think that makes sense to keep stable, too. — Matt Sicker > On Nov 5, 2023, at 16:22, Ralph Goers wrote: > > > >> On Nov 5

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

hat should be done before 3.0, but those largely involved removal of deprecated code and some small changes to APIs (such as flattening of extension interfaces, removal of Serializable, removal of the generic parameter from Layout). We can do some additional passes for anything else that shou

Re: (logging-log4j2) branch 2.x updated: Backport Lazy util

I split this one up by accident. There was a follow up commit that updated the places where they were updated in main. I don’t recall any particular issue being resolved, though I was comparing the 2.x and main branches to look for differences. Guess I did it in reverse here. — Matt Sicker

Re: Deterministic formatter

; > On Thu, 26 Oct 2023 at 01:03, Matt Sicker wrote: >> >> Seems reasonable to me. I can’t really tell what the difference is between >> the two resulting outputs, though. > > There was no difference (I must have used the same Spotless config > twice), so I corre

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

here I stopped making proof of concept appenders. — Matt Sicker > On Nov 3, 2023, at 09:08, Gary Gregory wrote: > > What I mean is this: When I want to work with a DB-like thing from Java, I > look 1st for a JDBC driver, when there is no FOSS option, I have to use a > DB-specifc API

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

(which is itself a unique implementation detail). — Matt Sicker > On Nov 2, 2023, at 21:36, Ralph Goers wrote: > > > >> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier >> wrote: >> >> >> >> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrot

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

What’s great about JTL is that it generates valid YAML, too! YAML is a superset of JSON. :) > On Nov 2, 2023, at 11:15 AM, Ralph Goers wrote: > > IMO JSONLayout should be deprecated for 2 reasons: > 1. JTL is so much better > 2. It doesn’t generate great JSON. > > As for the YAMLLayout, I

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

Votes below > On Oct 30, 2023, at 3:44 AM, Piotr P. Karwasz wrote: > > This is a vote to deprecate the following `2.x` modules and features > and remove them from the `3.x` release: > > * `log4j-cassandra`: +1 deprecate > * CouchDB appender: +1 deprecate > * `log4j-docker` -0 > * GELF

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

If we actually annotate the various public APIs like how JUnit 5 does, then we could have more flexibility to remove things. > On Nov 2, 2023, at 4:10 AM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Thu, 2 Nov 2023 at 09:42, Apache wrote: >> I’m confused. 3.0.0 hasn’t even been released so

Re: [Log4j] Main website page

Oh, I thought you meant you updated the website itself already. > On Nov 1, 2023, at 3:03 PM, Volkan Yazıcı wrote: > > It is the last commit to the `logging-log4j2` repository: > https://github.com/apache/logging-log4j2/commit/96eb0d00099b709663a251484f2967cbb93b0230 > > On Wed, Nov 1, 2023 at

Re: Why is JNDI still necessary?

> On Nov 1, 2023, at 2:22 PM, Christian Grobmeier wrote: > > We should not underestimate the impact log4shell had. Jndi was at the epi > center. Us, providing a giant jar including so much stuff with potential > security holes don’t do us a favor. This is exactly why in 3.x, the main branch,

Re: Why is JNDI still necessary?

I don’t see any reason why we shouldn’t publish the JNDI support in its own module as we’re planning in main already. Whether we eventually split out anything from the main repo is another story, but in 3.x, JNDI, like most of the optional features, will require downloading additional

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

I can’t think of any reason why we’d need fast date parsing. Unless it’s relevant in the rolling file appender family? > On Nov 1, 2023, at 6:07 AM, Volkan Yazıcı wrote: > > As reported in LOG4J2-3672 > , `FastDateParser`[1] > contains

Re: Why is JNDI still necessary?

I’m not sure how much people use this deployment model anymore, but JNDI was and still is at the core of JavaEE (now JakartaEE) dependency injection APIs. While CDI is the current way of using dependency injection there, CDI is compatible with JNDI and the other JavaEE tech that came in between

Re: Serializable gone for 3.0?

Yeah I nuked it a while back. > On Oct 27, 2023, at 5:44 AM, Gary Gregory wrote: > > Should we remove implements Serializable from classes for 3.0? > > Gary

Re: Deterministic formatter

Seems reasonable to me. I can’t really tell what the difference is between the two resulting outputs, though. > On Oct 25, 2023, at 3:06 PM, Piotr P. Karwasz wrote: > > Hi all, > > On Thu, 21 Sept 2023 at 07:15, Piotr P. Karwasz > wrote: >> Spotless supports many formatter plugins, the main

Re: [chainsaw] DB package?

If you use Log4j in Chainsaw, you could set up a JDBC appender or similar to forward things along. The Flume appender could be useful there, too, but that sort of moves the database configuration into your Flume config. > On Oct 24, 2023, at 3:14 PM, Christian Grobmeier wrote: > > Hi, > > in

Re: [log4j] Project URLs per major version

Considering I’m one of the only people who adds @since tags (or Javadocs in general), I think we’ll need some tooling to help with this. In Jenkins, we had some sort of script for this so that we could add “@since TODO” to new files, and the script would replace them all before tagging a

Re: [log4j] Annotation processing alternatives

ns. I say we stick with the built-in > Service Loader. > > Gary > > On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz > wrote: >> >> Hi Matt, >> >> On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: >>> So now we come to your question about a factori

Re: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up

Yeah I think it’s mainly a documentation thing for 3.x. — Matt Sicker > On Oct 20, 2023, at 18:06, Ralph Goers wrote: > > I don’t think this is a problem. Only users of Log4j 3.x should be using Java > 17 and up by the time this makes it to an LTS release. Log4j 3.x has put the

Re: [log4j] Annotation processing alternatives

by hand, but it’s tedious as it’s replicating information from the plugin annotations into PluginEntry instances. — Matt Sicker > On Oct 22, 2023, at 14:35, Volkan Yazıcı wrote: > > Good point Matt! Annotation processing has always been an unpleasant magic > to work with from

Fwd: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up

Snippet from the JDK 21 announcement email that pertains to us. While the annotation processor was initially developed to try to be implicit and magic, as we’ve seen both in our build and in IDEs, annotation processing is typically either disabled by default (in IDEs) or sometimes requires

Re: Staging sites and repo convention

If this is only for staging URLs and doesn’t break the production URLs, this sounds reasonable. And the git worktree stuff is new to me! > On Oct 19, 2023, at 3:03 AM, Piotr P. Karwasz wrote: > > Hi, > > Since now we have a fast release process It might happen (and it > already did) that the

Re: Failing tests (was: [VOTE] Release Apache Log4j 2.21.0)

I’ve seen that test fail in CI before as well. I wonder if there’s any firewall issues that can interfere with it, or if it relies on some potentially unusable state like a common port number. > On Oct 16, 2023, at 8:06 AM, Ralph Goers wrote: > > I enabled that profile. Log4j-core-test failed

Re: JDBC optimizations in 3.x

> On Oct 16, 2023, at 6:38 AM, Piotr P. Karwasz wrote: > > 2. There are two ways to map event data to columns: ColumnConfig and > ColumnMapping. It is unclear to me which way is the recommended one. > Since we can perform breaking changes in 3.x, could we remove one of > these methods? I added

Re: Status of log4j-audit

Log4j Audit has multiple components: * Audit API for extending log4j-api with some additional audit logging APIs * Tool for managing your audit event schemata and such (the web app thing) * Tool for generating structured log classes from the event schemata Thus, in typical use, you can (and

Re: [VOTE] Release Apache Log4j Scala 13.0.0

+1 I also agree that the Scala 3 reproducible build issue is minor. > On Oct 10, 2023, at 6:21 AM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Scala 13.0.0. > > Website: https://logging.staged.apache.org/log4j/scala > GitHub:

Re: Breaking changes in Log4j API 3.x

Use PropertyEnvironment; it’s the public API. The only methods not exposed by it are internal ones like reload which are used by some tests. > On Oct 9, 2023, at 6:37 PM, Ralph Goers wrote: > > > >> On Oct 9, 2023, at 2:14 PM, Piotr P. Karwasz wrote: >> >> On Mon, 9 Oct 2023 at 20:57,

Re: [log4j] LOG4J2-3669 Scala API license

I’m not sure which parts of the code are inspired by the other library. I mostly worked on the build files :) > On Oct 4, 2023, at 2:02 AM, Volkan Yazıcı wrote: > > PJ states in LOG4J2-3669 > that the NOTICE file should contain reference to

Re: New for 3.0: Ergonomic Default Settings

multiple defaults tailored to specific application types. > > Ralph > >> On Oct 3, 2023, at 9:35 AM, Matt Sicker wrote: >> >> I’ve had this idea for many years now, and as we get closer to 3.0, it seems >> like it’s time to consider the details. We can change the defa

Re: [VOTE] Release Apache Log4j Kotlin API 1.3.0 (RC2)

+1 Same comment about the `mvnw` script not being executable. The README could perhaps be updated with build instructions in the future. > On Oct 3, 2023, at 4:13 AM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Kotlin API 1.3.0 (RC2). > > Website:

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

+1 I should note that the included `mvnw` script is not executable in the zip. > On Oct 3, 2023, at 3:29 AM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Tools 0.5.0 (RC2). > > Website: https://logging.staged.apache.org/log4j/tools > GitHub:

New for 3.0: Ergonomic Default Settings

I’ve had this idea for many years now, and as we get closer to 3.0, it seems like it’s time to consider the details. We can change the default configuration in 3.0 without being as surprising as any other version. I think we could use this as an opportunity to demonstrate some best practices

Re: [chainsaw] What is necessary for a 2.2 release?

Jackson makes for a good library here because it also supports several data formats (YAML, XML, HOCON, and all sorts of others, both textual and binary) and is fairly extensible for hooking any custom serialization or deserialization logic you need. Given the desire to avoid Java serialization,

  1   2   3   4   5   6   7   8   9   10   >