Re: [VOTE] Move Chainsaw to dormant

+1 Thanks! -ck On Mon, Feb 12, 2024, at 16:31, Christian Grobmeier wrote: > This vote is to put Chainsaw to the "Dormant" components. There is much work > to be done on this component, but not enough hours can be committed to do > that work. To reflect this situation to the user, it is better

Re: Code reformatting

Updating branches across code formatting isn't bad if you run the formatter on the repo on your branch prior to updating, then you can merge the formatted target branch into your branch cleanly. On Wed, Nov 15, 2023, at 12:52, Matt Sicker wrote: > We have our great deletion branch I started to

Re: Deterministic formatter

I'd be happy to review+release changes to get the eclipse plugin in that repo into a good place as long as it doesn't make the build process a great deal more complicated. We don't have many folks internally using eclipse so support hasn't been a priority, but the easier it is to use across

Re: [log4j] Recycler and Scoped Values (JEP 429)

Thanks for raising this, Volkan. I agree with your assessment that scoped values won't be very helpful for object pooling. The first sentence of https://openjdk.org/jeps/446 states: > Introduce scoped values, which enable the sharing of immutable data within > and across threads. The key

Re: Review Request: LOG4J2-3628 Migrate from maven-changes-plugin to a merge-conflict-free Markdown-based solution

report issues. If the existing user or dev lists become inundated with bug reports, we can always spin up a new mailing list for tracking and triage, but I suspect that will be the exception rather than the rule. Carter Kozak

Re: Switch Log4j to GitHub Issues

I’m supportive of using GitHub issues for a few reasons: It’s more inclusive to our users who can no longer create jira accounts. My account is more secure, requiring hardware tokens to log in. Unlike jira, it renders correctly on my phone. -ck > On Nov 4, 2022, at 09:43, Matt Sicker wrote: >

Re: Stack valued MDC

I can understand how the stack-based mdc might be convenient and useful, but I don't think it fits my use-cases. That said, I wonder if the API could be improved in such a way that it could leverage the application stack instead of maintaining its own -- this is an issue that I've encountered

Re: [VOTE] Release Apache Log4j 2.17.2-rc1

+1 Build is green. Validated the artifacts across a variety projects I maintain, tests are all green. A few builder 'with' methods failed in builds that lint against deprecation due to new overloads with 'set' methods. Also tested spring-boot from commit

Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.

That would certainly make local development, PR builds, and the individual component releases easier. However, if each release requires a release of every sub-component, that would be harder to track. I'm in favor of splitting out composable pieces, but we should be cognizant of process

Re: [logging-log4j2] branch release-2.x updated: LOG4J2-3394 - Allow substitution of system properties and environment variables in shorthand variables introduced in LOG4J2-3341

I have added a few review comments on this change https://github.com/apache/logging-log4j2/commit/b69b7b802539d87aab6b51aca0a0df8a669ce6ee -ck On Sun, Feb 6, 2022, at 12:38, rgo...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > rgoers pushed a

Re: [logging-log4j2] branch release-2.x updated: LOG4J2-3394 - Allow substitution of system properties and environment variables in shorthand variables introduced in LOG4J2-3341

-1 see GitHub comments regarding recursive lookup evaluation https://github.com/apache/logging-log4j2/commit/6d6ff5b85bbdba8895c41de5c5b6049e07635395 -ck > On Feb 6, 2022, at 12:39, rgo...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > rgoers

Re: LOG4J2-3260 Missing branch protection settings

r own > > > company and provide paid support and development for Log4j forks or > > > whatever else we want, then we can put in all the processes anyone wants. > > > > > > Gary > > > > > > On Thu, Jan 27, 2022 at 9:02 AM Gary Gregory > >

Re: LOG4J2-3260 Missing branch protection settings

What if RTC only applied to the primary branch, release-2.x? We've had changes like this[1] which I discovered after the fact and wish we'd had a chance to discuss before it merged. Pushing changes prior to review is faster and easier for the committer, but ultimately creates an arduous process

Re: Is a truly small core possible for 3.0?

bytes into a log4j configuration. -ck On Wed, Jan 26, 2022, at 19:38, Matt Sicker wrote: > A truly minimal core that only supports properties is the API itself. Look > into SimpleLogger. > > — > Matt Sicker > > > On Jan 26, 2022, at 18:29, Carter Kozak wrote: > >

Re: Is a truly small core possible for 3.0?

I agree with Gary about a truly minimal core (though I'm going to stay out of the naming argument, it's one of the two hardest problems in CS). My largest use-case doesn't involve parsing any sort of configuration -- it's all programmatic. I'd benefit from the ability to run without any sort of

Re: LOG4J2-3260 Missing branch protection settings

I'd love to start using the github PR workflow for our contributions. I've been using them for my changes for a while and find it much easier than running a full build locally to verify each change on my development system. While we've historically used "commit then review", I find it much

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

pp, and the server combo, sometimes changing a setting, > > means the UI generates a new config file and sends it over, sometimes to > > translates to calling a specific Configurator API like one of the > > setLevel() APIs, and some other time we query and/or edit objects direct

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Any chance you could help me understand the rationale for this feature? I opted not to implement a method akin to MapLookup.getMap because that wasn't used, avoiding unnecessary API constraints allows us to refactor more easily in the future. If the values are required elsewhere, it may be

Re: [logging-log4j2] branch release-2.x updated (ff33bbc -> 97f9201)

n't > have a custom CI pipeline of yours. > > On Mon, Jan 17, 2022 at 7:51 PM Carter Kozak wrote: > > > Please revert, this breaks stacklocatorutil on java 9+ with the following: > > > > Caused by: java.lang.No

Re: [logging-log4j2] branch release-2.x updated (ff33bbc -> 97f9201)

to be desired as well. -ck On Mon, Jan 17, 2022, at 14:48, Gary Gregory wrote: > How does this stack trace happen when my full local builds and github builds > are green? Are we missing a test for this feature? > > Gary > > > On Mon, Jan 17, 2022, 13:51 Carter Kozak wrote: &

Re: [logging-log4j2] branch release-2.x updated (ff33bbc -> 97f9201)

This may fix the regression: https://github.com/apache/logging-log4j2/pull/714 -ck On Mon, Jan 17, 2022, at 13:50, Carter Kozak wrote: > Please revert, this breaks stacklocatorutil on java 9+ with the following: > > Caused by: java.lang.NoSuchMethodError: 'java.u

Re: [logging-log4j2] branch release-2.x updated (ff33bbc -> 97f9201)

Please revert, this breaks stacklocatorutil on java 9+ with the following: Caused by: java.lang.NoSuchMethodError: 'java.util.Deque org.apache.logging.log4j.util.StackLocator.getCurrentStackTrace()' at

Code Formatter?

Hi all, We've discussed the idea of using a code formatter before, I finally had a moment put up an example. Please take a look and provide feedback at your convenience :-) https://github.com/apache/logging-log4j2/pull/697 -ck

Re: [logging-log4j2] 02/04: Our convention is to make test classes public.

+1 I prefer minimum visibility by default for the same reason I prefer to make everything final by default: It gives us more freedom to change later on. This doesn't directly apply to tests, but it's nice when a convention applies globally. Most projects don't make junit5 tests public, so

Re: [logging-log4j2] 02/02: Use final and simpler hashcode generation through Objects.

I'd prefer if we didn't incur implicit array allocation cost generating a hash code. My preference is to keep the original implementation. -ck On Wed, Jan 12, 2022, at 08:50, ggreg...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > ggregory pushed a

Re: [VOTE] Future of Log4j 1.x

+1 Option 1 -ck > On Dec 29, 2021, at 14:33, Christian Grobmeier wrote: > > Hello, > > as discussed in another thread, this is a vote about the future of log4j 1. > This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ]

Re: [VOTE] CVE creation process

+1 -ck > On Jan 3, 2022, at 6:59 AM, Volkan Yazıcı wrote: > > Hello, > > As discussed earlier[1], this is a vote to introduce the process that > enforces CVE submissions and their content should be first subject to > voting using the (private) `secur...@logging.apache.org` mailing list. > >

Re: rat:check at verify

Thank you! -ck > On Dec 30, 2021, at 02:27, Volkan Yazıcı wrote: > > Pushed to both `release-2.x` and `master`. > >> On Wed, Dec 29, 2021 at 10:25 AM Volkan Yazıcı wrote: >> >> I suggest hooking apache-rat:check up to the verify stage in Maven. This >> will make CI run that goal too.

Re: [VOTE] Release Log4j 2.12.4-rc1 for Java 7

+1 rat and build look good, usual issues with mongo tests on m1 $mvn --version Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime:

Re: [VOTE] Release Log4j 2.3.2 for Java 6

+1 $ mvn -version Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre

Re: [VOTE] Release Apache Log4j 2.17.1-rc1

+1 $ mvn --version Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec Java version: 1.8.0_292, vendor: Azul Systems, Inc., runtime: /Users/ckozak/.tools/jdk/zulu8.54.0.21-ca-jdk8.0.292-macosx_aarch64/zulu-8.jdk/Contents/Home/jre

Re: Setting default branch to release-2.x on GitHub

I filed an infra ticket for this, but it hasn’t been picked up yet: https://issues.apache.org/jira/browse/INFRA-22641 Might be worth emailing someone? Otherwise they may be busy with the holidays. -ck > On Dec 26, 2021, at 06:16, Volkan Yazıcı wrote: > > Many people get confused by the

Re: [DISCUSS] The future of Log4j 1.x

> Sorry to be pedantic, but what Apache rules apply to the previous > DISCUSS/VOTE thread? There's no need to apologize, the rules exist for a reason! > It should be telling, not ironic, that the last two contributors to Log4j 1 > that are still here voted -1 This is a great point which I

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

You can find the PMC list here: https://people.apache.org/phonebook.html?pmc=logging On Fri, Dec 24, 2021, at 11:59, Vladimir Sitnikov wrote: > AFAIK only PMC members have binding votes. > > AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members > of Logging as

Re: [DISCUSS] The future of Log4j 1.x

I would agree directionally with option 1 or option 4. Making changes without pushing binary artifacts to maven central (options 2 and 3) is unlikely to do much good for the types of projects which still use log4j1. Option 5 is a hard no from me, my time is already too constrained, there are

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 -ck > On Dec 23, 2021, at 16:35, Ralph Goers wrote: > > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has > recommended that we can divorce > the read-only SVN repo from https://github.com/apache/log4j. However, it will > not be able to keep the same > name as all

Re: Broken CI

I haven't had a test flake locally in the last 6 months (at least), if we see flaky tests I'm in favor of fixing them rather than working around them. fwiw the non GitHub-actions tests work great on the release-2.x branch in my experience, when they aren't overwhelmed accessing build nodes

Re: New Log4j 1 repo

I’d rather use a name like ‘main’ or ‘develop’ for inclusivity (across all our projects). -ck > On Dec 23, 2021, at 08:41, Gary Gregory wrote: > > If we use this repo, is everyone OK renaming "trunk" to "master" in order > to match the branch name of our other repos? > > Gary > >> On Thu,

Re: LOG4J2-3243

Is the case that the log4j2 log4j-1.2-api is not on the classpath, but log4-1.2 itself is? Ideally we could detect that case and allow log4j1 to do its thing, but that's easier said than done outside of standard cases (for instance when interesting plugin/webapp classloaders are used) On Wed,

Re: [VOTE] Release Apache Log4j 2.3.1-rc1 for Java 6

+1 rat and build succeed, however I don't have a jre6 around to test with. Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: /home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre Default locale: en_US, platform encoding:

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

+1 -ck > On Dec 20, 2021, at 22:46, Matt Sicker wrote: > > +1 > > Notes on the release: > * Sigs and checksums good > * Builds and tests fine > * Outdated copyright year in NOTICE.txt > > -- > Matt Sicker > >> On Dec 20, 2021, at 18:52, Ralph Goers wrote: >> >> This is a vote to release

Re: Resurrecting log4j 1.x

Same, git migration makes sense to me if we are fixing CVEs. -ck > On Dec 20, 2021, at 14:28, Matt Sicker wrote: > > Sorry, I forgot to vote explicitly. I'd be +1 on the git repo > migration, but I was also iffy on enabling issues there. > >> On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

+1 build + rat are good -ck On Fri, Dec 17, 2021, at 22:18, Ralph Goers wrote: > This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 > project. > > Please download, test, and cast your votes on the log4j developers list. > [] +1, release the artifacts > [] -1, don't

Re: [VOTE] Release Log4j 2.12.2-rc1

+1 validated the build and signatures, tests in core modules. On Tue, Dec 14, 2021, at 00:58, Ralph Goers wrote: > This is a vote to release Log4j 2.12.2, a security release for Java 7 users. > > Please download, test, and cast your votes on the log4j developers list. > [] +1, release the

Re: [VOTE] Release Log4j 2.15.0-rc2

Thanks, Matt. It has been a long day :) On Sun, Dec 12, 2021, at 13:16, Matt Sicker wrote: > This vote thread is already closed. Did you mean to vote on the 2.15.1-rc1 > thread? > > > On Dec 12, 2021, at 11:49, Carter Kozak wrote: > > > > +1 > > > >

Re: [VOTE] Release Log4j 2.15.1-rc1

+1 mvn clean && mvn install rat passes $ mvn -v Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: /home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux",

Re: [VOTE] Release Log4j 2.15.0-rc2

+1 mvn clean && mvn install rat passes $ mvn -v Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: /home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux",

Re: Removing message lookups in master

Agreed that the feature should be purged entirely. I turned it off by default with no global enablement on release-2.x (shipped in 2.15). -ck > On Dec 11, 2021, at 09:13, Mikael Ståldal wrote: > > I would say that log messages and log message parameter are as much (or as > little)

Re: [VOTE] Release Log4j 2.15.0-rc2

+1 rat passes build+tests pass [logging-log4j2-2.x]$ mvn -v Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: /home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name:

Re: [VOTE] Release Log4j 2.15.0-rc1

+1 rat: success mvn install: success (no flakes) $ mvn -v Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: /home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name:

Re: FixedDateFormat performance

It looks like we're spending a great deal of time calculating midnight, and the delta to midnight. I don't think this is a representative benchmark because the time intervals are not ordered, nor are they close together. This means the entire cache is invalidated each iteration (date, time,

Re: Continuous Log4j-vs-Logback benchmarks

I won’t be back to a dev machine until Sunday, but I’d be happy to put together a list at that point! -ck > On Oct 15, 2021, at 7:16 AM, Volkan Yazıcı wrote: > > I am looking for certain JMH benchmarks to assess the Log4j-vs-Logback > performance. I plan to integrate these into the

Re: Cek's new log4j vs logback benchmark

y blocker after that.) Porting those to > `master` can be tackled in parallel. > >> On Fri, Oct 15, 2021 at 1:03 PM Carter Kozak wrote: >> >> I’ve been on vacation with limited network access since Saturday, but I’ll >> be back on Sunday. My PR is ready to merge into release-

Re: Cek's new log4j vs logback benchmark

I’ve been on vacation with limited network access since Saturday, but I’ll be back on Sunday. My PR is ready to merge into release-2.x, I haven’t done so yet because I began the cherry-pick to master but was unable to complete the relatively painful conflict resolution before my flight out.

Re: broken Log4j2Plugins.dat in the shaded benchmarks.jar of log4j-perf

This sounds great. Thanks, Volkan! -ck > On Oct 15, 2021, at 6:42 AM, Volkan Yazıcı wrote: > > I have gotten in touch with the author of the > maven-shaded-log4j-transformer plugin, Eduard Gizatullin. He has kindly > accepted to contribute this plugin in the form of a PR to the project. I >

Re: Cek's new log4j vs logback benchmark

. > > Ralph > > > On Oct 4, 2021, at 12:09 AM, Volkan Yazıcı wrote: > > > > Gentlemen, what is the status of the progress on this front? Is it in a > > "good enough" state for the 2.15.0 release? > > > > On Thu, Sep 23, 2021 at 6:29 PM Carter Kozak wro

Re: Cek's new log4j vs logback benchmark

15.0. > > > > I have followed the conversation with Claes Redestad from Oracle on Twitter > > <https://twitter.com/carter_kozak/status/1433798391604162561>. My > > conclusion was also that there apparently is no way to make CharsetEncoder > > beat .toString().ge

Re: Cek's new log4j vs logback benchmark

Thanks, Volkan! Rerunning the benchmarks on my branch (specifically the PatternLayout benchmarks in log4j-perf) produced much better improvements than I had anticipated. Beyond that, the date format cache invalidation problem resulted in a substantial speedup. I agree that it would be helpful

Re: Cek's new log4j vs logback benchmark

r-encoding-performance/pull/3 On Mon, Sep 20, 2021, at 15:34, Volkan Yazıcı wrote: > Carter, I am really curious about your ongoing crusade. Mind updating us on > it a bit, please? Where are we? What is your plan? How can we help you? > > On Wed, Sep 1, 2021 at 2:57 PM Carter Kozak wrote:

Missing commits on the master branch

In cherry-picking a change from release-2.x to master I ran into some conflicts because https://github.com/apache/logging-log4j2/commit/97ec707d69280ef57aed8fd5831dc4f3a75f7715 was merged to the release branch, but never ported to master. Gary, do you recall if this was intentional? If not I'd

PR Build Failures

Hi all, Does anyone know why our PR builds recently began to fail posting status after successfully running the build? > Posting status 'completed' with conclusion 'success' to > https://github.com/apache/logging-log4j2/pull/579 (sha: > 782a2769bdcd30e5f913b900fff59aa6250db53b) > Error:

Re: Cek's new log4j vs logback benchmark

/twitter.com/cl4es/status/1432361530268528642>, via Twitter? > > On Mon, Aug 30, 2021 at 11:32 PM Carter Kozak wrote: > > > I've merged the fix for our FixedDateFormat caching bug which caused us to > > recompute the same millisecond-precision formatted timestamp un

Re: Cek's new log4j vs logback benchmark

I've merged the fix for our FixedDateFormat caching bug which caused us to recompute the same millisecond-precision formatted timestamp unnecessarily each time our microsecond-precision clock incremented. https://issues.apache.org/jira/browse/LOG4J2-3153 I've also been unwrapping a few layers

Re: Cek's new log4j vs logback benchmark

up the "SEQ" notation, there's likely a better way to > > express the feature. Everything can read from the buffer without locking. > > 4)Have a background thread casually keep the sequence filled in a ring so > > dates in the past are replaced with future dates

Re: Cek's new log4j vs logback benchmark

gt;> [10] = "2021-08-28 09:44:31,050"[11] = "2021-08-28 09:44:31,075"[12] = >> "2021-08-28 09:44:31,100"[13] = "2021-08-28 09:44:31,150"[14] = "2021-08-28 >> 09:44:31,175"[15] = "2021-08-28 09:44:31,200"...[31999] = "...&q

Re: Cek's new log4j vs logback benchmark

to read through the patternlayout and individual pattern converters to understand why, but there's definitely some headroom we'll be able to reclaim hiding somewhere. -ck On Fri, Aug 27, 2021, at 11:23, Carter Kozak wrote: > My pleasure, I enjoy digging into this sort of performance compari

Re: Cek's new log4j vs logback benchmark

cept similar to the > one we have in JsonTemplateLayout. I think there was already a mailing list > thread about this.) > > On Thu, Aug 26, 2021 at 8:37 PM Carter Kozak wrote: > > > Yes, I'm still looking into this. > > > > I agree that the zero-garbage code

Re: Cek's new log4j vs logback benchmark

again yesterday to > >> change > >> the wording but I am pretty sure he didn’t change the log4j2 configuration > >> to use a > >> 256K buffer to match Logback. And the page still makes it look like he is > >> testing > >> the performance of asynchrono

Re: Cek's new log4j vs logback benchmark

26, 2021, at 10:29, Carter Kozak wrote: > I also tried that with similar results, which leads me to believe we're > spending > too much time copying between buffers. > > We've proven that log4j can get LogEvents to the appender very quickly and > efficiently. > >

Re: Cek's new log4j vs logback benchmark

that made a big difference is that Ceki has Logback > > configured to > > use a buffer size of 256K while Log4j2 uses the default of 8K. Setting > > Log4j2 to 256K > > considerably improved the performance. > > > > > > Ralph > > > > > On Aug 25

Re: Cek's new log4j vs logback benchmark

> If we would move the appender performance aside, am I right to conclude > that the entire complex async. framework built atop Disruptor with all its > whistles and bells is yielding a diminishing performance gain compared to a > simple off the shelf blocking queue? I haven't seen any data that

Re: Cek's new log4j vs logback benchmark

> Appender configured. > > Ralph > >> On Aug 20, 2021, at 9:14 AM, Carter Kozak wrote: >> >> Benchmarks were using an unpublished version of logback that works >> differently than the release version I tested against -- continuing the >>

Re: Cek's new log4j vs logback benchmark

ond to his tweet. > > Ralph > > > On Aug 20, 2021, at 7:15 AM, Carter Kozak wrote: > > > > Thanks for flagging this! I've responded to the tweet, copying it here as > > well for posterity: > > > > Looking at the logback benchmark it appears that no by

Re: Cek's new log4j vs logback benchmark

Thanks for flagging this! I've responded to the tweet, copying it here as well for posterity: Looking at the logback benchmark it appears that no bytes are being written to target/test-output/logback-async-perf.log. Upon closer inspection the logback asyncappender is in an started=false state,

Re: Solution for vulnerability

This CVE is mentioned on the release notes page, I'd suggest you start there: https://logging.apache.org/log4net/release/release-notes.html Carter On Tue, Aug 17, 2021, at 15:56, Marcelo Lourenço wrote: > Good afternoon dear, > > I have an apache CVE-2018-1285 for log4net vulnerability > >

Re: Putting a ribbon onto 2.15.0

I've meant to set aside time to fix https://issues.apache.org/jira/browse/LOG4J2-3083 before 2.15.0. Hoping to verify benchmarks on https://github.com/apache/logging-log4j2/pull/485 as well. Don't block on me if I haven't been able to take care of these over the weekend. Really sorry that I

Re: Large commit incoming

Looking forward to it, thank you for the work, Ralph! -ck > On May 13, 2021, at 2:14 PM, Ralph Goers wrote: > > Just a word of warning that I will be pushing a large commit to master. This > one makes log4j-core a JPMS compliant module. > > Ralph

Re: Garbage Free Precise Time

Escape analysis can take quite a few iterations to take effect, perhaps we need a few more tens of thousands of warmup cycles? Admittedly I haven't taken a look at the failures yet and there's a great deal of subtlety around this. I can try to take a closer look later, unfortunately I've been

Re: [apache/logging-log4j2] MapMessage put methods should not mandate String values (#477)

The method argument type changes are an ABI break, but I recall extending MapMessage within a project in order to support more expressive types -- that may have relied on dangerously casting the result of getIndexedReadOnlyStringMap to an IndexedStringMap. Including a safer Object-valued

Re: release-2.x EventLogger

The flake appears to be resolved, just as mysteriously as it appeared. -Carter On Wed, Mar 24, 2021, at 10:28, Carter Kozak wrote: > Any ideas why org.apache.logging.log4j.EventLoggerTest.structuredData would > fail due to the following? > > java.lang.NullPoin

release-2.x EventLogger

Any ideas why org.apache.logging.log4j.EventLoggerTest.structuredData would fail due to the following? > java.lang.NullPointerException > at > org.apache.logging.log4j.EventLoggerTest.structuredData(EventLoggerTest.java:42) I haven't been able to reproduce this failure locally, but it

Re: The Logging Services PMC is pleased to announce our newest PMC member, Robert Middleton!

Welcome, Robert! -Carter On Mon, Mar 22, 2021, at 05:24, Remko Popma wrote: > Welcome aboard, Robert! > :-) > Remko > > On Mon, Mar 22, 2021 at 5:15 PM Volkan Yazıcı > > wrote: > > > Welcome aboard Robert! > > > > On Mon, Mar 22, 2021 at 2:31 AM Matt Sicker

Re: [VOTE] Announce EOL for Java 6 and Java 7

+1 I don't have a strong opinion either way about retaining download links. In general I think keeping them around suggests that we're still willing to support fixes on those branches, even if we document to the contrary. That said, it's easy enough to close tickets against old versions by

Re: [Discuss] EOL of Java 6 and 7

I'm in favor of dropping support for java 6 and 7 and have little reason to believe anyone still using older releases is also taking library upgrades. -Carter On Sat, Mar 13, 2021, at 21:15, Robert Middleton wrote: > According to Adopt OpenJDK[1], version 8 will be supported until at least >

Re: Parallelization of PluginManager#collectPlugins()

Please don't use stream.parallel! It executes tasks on the ForkJoin pool which implements work-stealing, and can result in expensive long-running operations from other components in the system that we don't expect blocking our call (anything using the fork-join pool, all stream.parallel

Re: [VOTE] Release Log4j 2.14.1-rc1

+1 Verified the snapshots in a few internal projects, as well as code review and tests on the tag. Test pass on ubuntu: $ mvn clean && mvn install /usr/lib/jvm/java-11-openjdk-amd64/bin/java -version openjdk version "11.0.10" 2021-01-19 OpenJDK Runtime Environment (build

Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

The slf4j API is used very widely, I don't think it's a reasonable solution to suggest people migrate their code (and dependencies) to our API. That said, I'm not sure how important it is for us to support each alpha version of slf4j, considering it doesn't appear to be moving toward a

Re: Removing GelfLayout

I agree with Ralph's comments here. As a developer shipping an application, it's not clear how all my consumers have configured logging. I can upgrade jars, but I wouldn't want to make a change that breaks some percentage of my customers logging configurations. The cost of continuing to provide

Re: Renaming log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy (Was: [jira] LOG4J2-3009)

ers? > > On Fri, Jan 29, 2021 at 5:01 PM Carter Kozak wrote: > > > We have a framework in place to migrate property names without disrupting > > users, I would support using a default name that aligns more closely with > > the feature. I don't think we warn whe

Re: Renaming log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy (Was: [jira] LOG4J2-3009)

log4j2.asyncLoggerThreadNameStrategy to log4j2.threadNameStrategy > and display a warning if the deprecated one is defined? Are there more of > such properties? > > On Fri, Jan 29, 2021 at 4:44 PM Carter Kozak (Jira) wrote: > > > The {{log4j2.asyncLoggerThreadNameStrategy

Re: Review request for LOG4J2-2972

You’re too kind, you did all the work! This is what open source development is all about! Carter > On Jan 9, 2021, at 10:01 AM, Volkan Yazıcı wrote: > > After incorporating changes requested by Carter and Gary, I have merged > this branch. > > I want to take this opportunity to thank Carter

Re: Rationale behind EventRoute.SYNCHRONOUS

Queues are difficult to get right, and easy to deadlock, especially when there are multiple queues. Falling back to synchronous appender access avoids that risk and operates in the same threading model as synchronous logging. I've seen a bug roughly every 6 months (despite several billion log

Re: [VOTE] Move Log4PHP to dormant status

+1 Carter On Mon, Dec 14, 2020, at 07:45, Dominik Psenner wrote: > +1 > > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Fri, Dec 11, 2020, 19:59 Christian Grobmeier > wrote: > > > Very sad, but +1. > > > > Code base became very old and there is

Re: LOG4J2-2965 deadlock brainstorming

onents can wait and > continue initialization when the core is completely initialized? > > Remko > > > On Mon, Dec 7, 2020 at 8:16 Carter Kozak wrote: > > > Hi Friends, > > > > I've been thinking about ways that we can solve LOG4J2-2965 which is a > > dead

LOG4J2-2965 deadlock brainstorming

Hi Friends, I've been thinking about ways that we can solve LOG4J2-2965 which is a deadlock between JUL init and log4j init, both of which use synchronization. The crux of the issue is that JUL LogManager uses a synchronized block to initialize, which requests log4j-core initialization and

Re: Using RecyclerFactory throughout the code base

I like the idea, but I defer to the benchmark results for this sort of thing ;-) The ability to bound reusable objects below the thread count will become more valuable when project loom[1] is released, as the JVM will support millions of virtual threads on a handful of OS threads. This will

Re: Log4j JSON layout template Uris enum

I'm a big fan fan of enum singletons. This case looks like an enum with no values for utility methods to avoid a private ctor, I haven't used enums this way myself. I think the trade-off is between avoiding having to write a private constructor to prevent extension, and the downside of enum

Re: Fwd: Opt in for JMX server?

Sounds like a great idea to me. At work we use a different framework to report metrics and generally disable jmx everywhere that allows us to do so. -ck On Mon, Nov 16, 2020, at 09:39, Gary Gregory wrote: > Hi All, > > I am starting to think that registering JMX MBeans after setting a config >

Re: [RESULT][VOTE] Release Log4j 2.14.0-rc1

Sorry I'm a little late to the party, I wasn't around a keyboard all weekend. This would have been a +1 from me if I'd made it in time! [logging-log4j2-2.x]$ mvn -version Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_252, vendor: Azul Systems, Inc., runtime:

Re: Log4j 2.14.0 release status

I’d like to get a fix for LOG4J2-2954 into this release so appenders are flushed before the jvm exits. I’ll be reviewing the proposed fix and making required changes tonight or tomorrow if that’s alright. -ck > On Nov 1, 2020, at 8:10 AM, Gary Gregory wrote: > > Over at Apache Commons, I

  1   2   >