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

Welcome Fred / Jan. I like your email handle freeandnil. :-) Welcome aboard! -Remko On Sat, Feb 10, 2024 at 4:54 AM Fred am Nil wrote: > Hello, > > thank you very much for the warm welcome. > I'm looking forward to collaborating with everyone and making meaningful > contributions to the Apache

interesting writeup of some nice engineering

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 compresses on the fly. Impressive 169x compression rate. Resulting

Re: [log4j] Performance figures

I’m open to improvements in this area. Before going into details or specifics though, I’m curious: What do we (users, developers and PMC members) consider to be the “value proposition” of Log4j? Why should people choose Log4j over the alternatives? This is a positioning question; what are

Re: Change semantics of `Throwable` parameters

> On Nov 23, 2023, at 18: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 mis-use” style API. However, once you go that route, you >> start

Re: Refining product feature set strategy

+1 to what Ralph said On Sat, Sep 30, 2023 at 0:56 Scott Deboy wrote: > +1 to everything Ralph said. > > On Fri, Sep 29, 2023, 3:53 PM Ralph Goers > wrote: > > > I’m sorry, I can’t really agree with much of any of this. Following the > > thoughts being proposed in this thread much of Log4j 2

Re: [VOTE] Release Apache Log4j JMX GUI 2.21.0

+1 Remko > On Sep 14, 2023, at 16:34, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j JMX GUI 2.21.0. > > Source repository: https://github.com/apache/logging-log4j-jmx-gui > Commit: 35d3021e995393a0f62198c2c65af8b47e42688b > Distribution:

Re: Optional dependencies in `log4j-core` 3.x

> 1. Configuration has properties related to async logging: `asyncLoggerConfigDelegate` and `asyncWaitStrategyFactory`. These should be removed before the split, but I don't know what would be the right way to do it. How would that work? Will Log4j 3 configurations be incompatible with Log4j 2

Re: [VOTE] Release log4cxx 1.1.0

+1 Remko On Wed, May 3, 2023 at 2:34 AM Thorsten Schöning wrote: > Guten Tag Robert Middleton, > am Dienstag, 2. Mai 2023 um 13:47 schrieben Sie: > > > Please download, test, and cast your votes on the log4j developers list. > > [] +1, release the artifacts > > [] -1, don't release because... >

Re: [VOTE] Release Apache Log4j Tools 0.1.0

+1 On Thu, Jan 12, 2023 at 2:21 AM Matt Sicker wrote: > +1 > > Thanks for working on this! Looks great! > > > On Jan 10, 2023, at 4:55 AM, Volkan Yazıcı wrote: > > > > The Apache Log4j Tools 0.1.0 release is now available for voting. > > > > The 0.1.0 version is the very first release of this

Re: [VOTE] Release log4cxx 1.0.0

+1 Remko On Tue, Jan 3, 2023 at 4:57 PM Thorsten Schöning wrote: > Guten Tag Robert Middleton, > am Sonntag, 1. Januar 2023 um 19:06 schrieben Sie: > > > Please download, test, and cast your votes on the log4j developers list. > > [] +1, release the artifacts > > [] -1, don't release because...

Re: SLF4J 1.8 and SLF4J 2.0

Agree, makes sense. > On Aug 27, 2022, at 7:50, Gary Gregory wrote: > > Makes sense. > > Gary > >> On Fri, Aug 26, 2022, 15:55 Ralph Goers wrote: >> >> Ceki never released a GA version of SLF4J 1.8. Since we are adding >> support for SLF4J 2.0 in the next release I would suggest we

Re: Stack valued MDC

I don’t think that’s the only sane option. Another sane option is to ignore it. There’s nothing that says Log4j has to implement any enhanced SLF4J APIs. He wants to be the lowest common denominator in logging APIs, then he can’t add APIs that aren’t supported in the major implementations.

Re: Source location static inlining

It would be truly awesome to get this to work! Triple yay! I would keep it as simple as possible though, and not worry too much about being super user friendly. Asking folks to recompile to get this feature is not a big ask, and avoiding complexity like weaving is a big advantage. Not working

Re: [VOTE] Release Apache Log4j 2.18.0-rc1

+1 sigs good On Thu, Jun 30, 2022 at 8:23 PM Gary Gregory wrote: > I just ran it again and I get the same error, so I can't validate the > build for now. > > Gary > > On Wed, Jun 29, 2022 at 9:25 PM Matt Sicker wrote: > > > > If that test isn’t using the listener mechanism in LoggerContext,

Re: [VOTE] Release Log4j Kotlin API 1.2.0-rc4

+1 > On Jun 22, 2022, at 2:09, Matt Sicker wrote: > > Bump. > >> On Sat, Jun 18, 2022 at 12:07 PM Matt Sicker wrote: >> >> Hi all, this is a vote to release Log4j Kotlin API 1.2.0 rc4. This vote will >> be open for at least 72 hours, requires at least 3 +1 votes and more +1 >> votes

Re: [logging-log4j2] 03/03: LOG4J2-3473 DOC update manual for garbage-free logging

itory. > > > > rpopma pushed a commit to branch release-2.x > > in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git > > > > commit 97b8c1dc4f320e855f26a0690651fc062f08361a > > Author: Remko Popma > > AuthorDate: Fri Apr 22 05:15:15 2022 +

Re: does the master branch compile?

:52, Piotr P. Karwasz wrote: > > Hello Remko, > >> On Thu, 21 Apr 2022 at 13:14, Remko Popma wrote: >> >> Warnings look like this: >> [WARNING] >> >> C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\Lo

does the master branch compile?

Hi all, I am trying to merge the changes for LOG4J2-3472 into master, but I have trouble building the master branch... (and I don't think it is because of my changes) Am I missing something? My environment - C:\Users\remko\IdeaProjects\logging-log4j2>mvn --version Apache

Re: [VOTE] Release log4cxx 0.13.0

+1 On Sat, Apr 16, 2022 at 10:01 AM Robert Middleton wrote: > This is a vote to release log4cxx 0.13.0. > > Please download, test, and cast your votes on the log4j developers list. > [] +1, release the artifacts > [] -1, don't release because... > > This vote will remain open for 72 hours(or

Re: log4j slow startup time - could this be a factor?

> themselves instantiated only on first use). > > On Fri, Apr 15, 2022 at 6:51 AM Remko Popma wrote: > > > > Maybe the complaints about startup time have to do with this: > > > > note that every time a PatternParser is instantiated, we load all plugins > > again.

log4j slow startup time - could this be a factor?

Maybe the complaints about startup time have to do with this: note that every time a PatternParser is instantiated, we load all plugins again... public PatternParser(final Configuration config, final String converterKey, final Class expectedClass, final Class filterClass) {

merging PRs - branch protection questions

I remember we discussed changing our development process to use PRs instead of committing directly to the release branches. This was part of trying to increase our security score, especially the Branch Protection part in scorecard (https://github.com/ossf/scorecard/blob/main/docs/checks.md).

Re: [VOTE] Release Apache Log4j 2.17.2-rc1

Remko Popma wrote: > +1 > > Signatures good, checksums good. > > Build passes (ignoring rev-api problem for the mongodb3 module) > > Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; > 2019-08-28T00:06:16+09:00) > Maven home: C:\apps\apache-maven-3.6.2\bin\.

Re: [VOTE] Release Apache Log4j 2.17.2-rc1

+1 Signatures good, checksums good. Build passes (ignoring rev-api problem for the mongodb3 module) Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation,

Re: [VOTE] Future of Log4j 1.x

+1 for Option 1 On Wed, Jan 5, 2022 at 4:51 AM Volkan Yazıcı wrote: > +1, Option 1 > > On Wed, 29 Dec 2021, 20: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. > >

Re: [DISCUSS] Starting social media accounts for subprojects

I also like this idea and agree with separate accounts for each component. On Fri, Dec 31, 2021 at 7:48 AM Gary Gregory wrote: > Great idea. I would suggest one account for the each component. I'm not > sure anyone but the PMC would care about a logging services account. > > Gary > > On Thu,

Re: Forwarding email per Matt Sicker suggestion

On Tue, Dec 21, 2021 at 2:41 AM Ralph Goers wrote: > Thanks Dick, > > I am totally unfamiliar with this. Is there somewhere to read about what > this is all about? > > Ralph > Resending, including Dick in the recipients. > > > On Dec 20, 2021, at 7:18 AM, Dick Brooks < >

Re: Published artifact hash files

I agree that would be great. Meanwhile, I am using this script/command to achieve the same result: for a in 1 256 512; do for f in `find . -type f -name "*.sha${a}"`; do claim=`cat $f |cut -d' ' -f1`; actual=`shasum ${f%.sha*} -a ${a} |cut -d' ' -f1`; if [[ "$claim" == "$actual" ]];

Re: [VOTE] Release Log4j 2.3.2 for Java 6

+1 Hashes and signatures OK, build OK: Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default locale: en_GB, platform

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

+1 signatures and hashes OK build tag log4j-2.12.4-rc1 OK Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default locale:

Re: [VOTE] Release Apache Log4j 2.17.1-rc1

+1 signatures and hashes ok build ok Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default locale: en_GB, platform

Re: [VOTE] Release log4net 2.0.14

+1 On Sat, Dec 25, 2021 at 6:35 AM Ralph Goers wrote: > +1 > > I checked the signature and hashes and those look good. > > I unzipped the source and binaries. The appropriate license and notice > files are present. > > I did not perform tests as I don’t have the necessary tools installed. > >

Re: Resurrecting log4j 1.x

Vladimir, There is a vote thread in progress ( https://lists.apache.org/thread/0rk0nr0pv9p2945jsrs9pp2ys57wksn3). You and I both voted on that thread. Looking at the number of +1 votes on that voting thread, surely you can see that this repo will be created, and not only that, it will be created

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

The Log4j1 project is EOL, and assuming that it remains EOL and we are only doing security patches, I vote in favor of this repo change, to facilitate making such security patches. +1 I agree we need to get consensus on the scope of any Log4j1 work. On Fri, Dec 24, 2021 at 8:53 AM Matt Sicker

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

The Log4j1 project is EOL, and assuming that it remains EOL and we are only doing security patches, I vote in favor of this repo change, to facilitate making such security patches. +1 I agree we need to get consensus on the scope of any Log4j1 work. On Fri, Dec 24, 2021 at 8:55 AM Ralph Goers

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

+1 I am changing my vote. My earlier pipecleaning program failed because the config had a JmsAppender configured in it... My bad. Signatures are good. Pipecleaning program works on Java 6 when I remove the JmsAppender from the config. On Wed, Dec 22, 2021 at 6:23 AM Ralph Goers wrote: > My +1 >

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

n Tue, Dec 21, 2021 at 7:37 AM Ralph Goers >> wrote: >> >> Hmmm. This is not what I was expecting. If it didn’t work I would have >> expected bad class version exceptions. >> >> Ralph >> >>>> On Dec 21, 2021, at 4:28 AM, Remko Popma w

Re: Resurrecting log4j 1.x

Vladimir, Have you had a chance to work on a patch for the security vulnerabilities? While there is understandably not much interest in “resurrecting” the Log4j 1.x project, overall people are positive about releasing a 1.2.18 with security patches. I think it would be most helpful if we can

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

-1 it does not work... Problem running a simple pipecleaning test on Java 6 with 2.3.1... My pipecleaning program is something simple like this public class Pipecleaning { public static void main(String[] args) { org.apache.logging.log4j.LogManager.getLogger().info("HELLO USER

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

+1 Remko On Tue, Dec 21, 2021 at 12:52 PM Carter Kozak wrote: > +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

Re: [logging-log4j2] 01/01: [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links

Thank you Gary! Great catch! On Tue, Dec 21, 2021 at 11:51 AM Gary Gregory wrote: > I'm not sure this is the right branch, I think log4j-2.3.x is the > right one. > > Ralph? > > Gary > > On Mon, Dec 20, 2021, 21:33 wrote: > > > This is an automated email from the ASF dual-hosted git

Re: [Lo4Net] Cyber Vulnerability Vendor Impact Assessment for Lo4Net

Hi Milind, Please take a look at this page, which has all the details: https://logging.apache.org/log4j/2.x/security.html In short, the log4net library is not impacted. Only log4j (the java library) is impacted by this vulnerability. Kind regards, Remko On Sat, Dec 18, 2021 at 6:24 AM Milind

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

+1 GNU signatures check ok. Build passed with maven clean install Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default

Re: [GitHub] [logging-log4j2] ichux commented on a change in pull request #607: LOG4J2-3198: Log4j2 no longer formats lookups in messages by default

Yes. It certainly looks like it (on my phone now). On Thu, Dec 16, 2021 at 14:53 GitBox wrote: > > ichux commented on a change in pull request #607: > URL: > https://github.com/apache/logging-log4j2/pull/607#discussion_r770242666 > > > > ## > File path:

Re: [VOTE] Release Log4j 2.12.2-rc1

+1 very light validation but ran a simple test program against the binaries On Wed, Dec 15, 2021 at 3:19 AM Carter Kozak wrote: > +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,

Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18

On Tue, Dec 14, 2021 at 11:44 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >My understanding is it requires an extremely > >old JDK. > >Have you actually tried building the project to see if this is true? > > I was able to build the project with Maven3 and Java 1.8 by commenting

Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18

Hi Vladimir, Thank you for your interest! You mentioned that "The maintenance overheads for releasing 1.2.18 do not seem to be severe". Have you actually tried building the project to see if this is true? Remko On Tue, Dec 14, 2021 at 11:13 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com>

Re: [VOTE] Release Log4j 2.16.0-rc1

+1 build succeeds and tests all pass Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default locale: en_GB, platform

Re: [VOTE] Release Log4j 2.15.1-rc1

eases in a week is a lot even for me :-) >> >> Gary >> >>> On Sun, Dec 12, 2021 at 9:41 PM Remko Popma wrote: >>> It seems that Ralph has already started to work on a PR to remove message >>> lookups altogether from 2.x. >>> I have come around

Re: [VOTE] Release Log4j 2.15.1-rc1

> > Gary > >> On Sun, Dec 12, 2021, 20:40 Remko Popma wrote: >> >> I am also okay with removing Message Lookups from 2.x. >> A release with that change should be called 2.16.0 though, not 2.15.1 or >> 2.15.2. >> >> Also it makes sense to *

Re: [VOTE] Release Log4j 2.15.1-rc1

lookup. I want to believe that users get this fact right and have already > > disabled it. We need to be really careful with our next release. We can't > > expect people to upgrade once a week. Putting aside the damage it does to > > the reputation of the project. >

Re: [VOTE] Release Log4j 2.15.1-rc1

On Mon, Dec 13, 2021 at 5:47 AM Remko Popma wrote: > First, is this really a blocker for 2.15.1? > I think it is prudent to do urgent releases soon. > This JNDI change (LOG4J2-3208 > <https://issues.apache.org/jira/browse/LOG4J2-3208>) feels urgent enough > to warrant a

Re: [VOTE] Release Log4j 2.15.1-rc1

change like this be in a point/bugfix release (2.15.1) or should it be a separate minor release like 2.16.0? On Mon, Dec 13, 2021 at 5:10 AM Remko Popma wrote: > Shall we discuss this first please? > > On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker wrote: > >> If you can handle

Re: [VOTE] Release Log4j 2.15.1-rc1

Shall we discuss this first please? On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker wrote: > If you can handle that change, I can roll a new release candidate. > > Matt Sicker > > > On Dec 12, 2021, at 14:07, Volkan Yazıcı wrote: > > > > I know. I want them to be removed, not disabled. > > > >>

Re: [VOTE] Release Log4j 2.15.1-rc1

+1 build succeeds, all tests pass Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default locale: en_GB, platform encoding:

Re: Removing message lookups in master

I would say no. Lookups are very powerful and useful. We could consider removing JNDI lookups. The biggest problem however is that the lookups are applied to the logging message *parameters*. The logging message is controlled by the application, so any lookups there should be fine or at least any

Re: [VOTE] Release Log4j 2.15.0-rc2

+1 build succeeds and all tests pass on my windows machine. Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default

Re: SetUtils

+1 On Fri, Dec 10, 2021 at 1:31 AM Gary Gregory wrote: > Sounds good. > > Gary > > On Thu, Dec 9, 2021, 11:02 Volkan Yazıcı wrote: > > > SetUtils is only used by log4j-web, yet it is in log4j-core. I want to > mark > > it as deprecated in release-2.x and remove it in master. Objections? > > >

Re: changes.xml

Why not have separate entries for each change instead of this one big thingy: - org.eclipse.persistence:javax.persistence . 2.1.1 -> 2.2.1 - org.eclipse.persistence:org.eclipse.persistence.jpa ... 2.6.5 -> 2.6.9 - org.fusesource.jansi:jansi

Re: Unexpected concurrent LoggerContext initialization

What do the generated files look like? Is the output that is generated in concurrent mode longer or shorter than the expected length? Also, does it contain one entry (one log message) per line, or is it scrambled? Are entries ordered by time? On Fri, Nov 12, 2021 at 12:34 AM Ralph Goers wrote:

Re: [Vote] Release log4net 2.0.13-rc2

+1 On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl wrote: > Hi > > I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where > the only difference is the archive layout for the associated source and > binary artifacts) > > - there's an rc up at GitHub with release notes: >

Re: Cek's new log4j vs logback benchmark

I don't have access to those boxes any more. I will be going on holiday from tomorrow without access to work email so it will be difficult for me to find out. One way is to assume they were new and look at what was the fastest reported speed for 2015 SSDs. I found this:

Re: Cek's new log4j vs logback benchmark

at.DEFAULT. The FastDateFormat alternative does not support > microseconds, so it doesn't suffer from the same problem. I think I can > substantially reduce the frequency we re-format dates by checking > FixedFormat.secondFractionDigits to determine if we meed to compare > microseconds. >

Re: Cek's new log4j vs logback benchmark

I remember looking at PatternLayout performance, I reported my findings here, hopefully they’re still useful: https://issues.apache.org/jira/browse/LOG4J2-930 If %d is used in the pattern, does the FixedDateFormat get used? > On Aug 28, 2021, at 4:33, Ralph Goers wrote: > > All of that

Re: [VOTE] Release Apache Chainsaw 2.1.0-RC2

+1 On Sun, Jun 6, 2021 at 9:36 AM Robert Middleton wrote: > This vote is to release Apache Chainsaw 2.1.0. This fixes a few > annoying issues with chainsaw and some other bugs, as well as updating > some dependencies. > > This vote supersedes the original vote > > Differences from RC1: > *

Re: [VOTE] Release log4cxx 0.12.0-RC2

+1 On Sun, May 9, 2021 at 12:21 PM Stephen Webb wrote: > +1 > > On Sun, May 9, 2021 at 1:13 PM Robert Middleton > wrote: > > > As a reminder, this vote is still outstanding. > > > > -Robert Middleton > > > > On Tue, May 4, 2021 at 7:10 PM Robert Middleton > > wrote: > > > > > > I've updated

Re: Garbage Free Precise Time

hanged after > support for the higher precision was added. > >>>> > >>>> Ralph > >>>> > >>>>> On Apr 2, 2021, at 12:44 AM, Ralph Goers <mailto:ralph.goers%40dslextreme.com>> wrote: > >>>>> > >>>&

Re: What is going on with Master?

No it’s fine you can stay. “Ban me i can't get him off she'll” is just pure poetry. More please. :-) > On Apr 20, 2021, at 10:03, Sixx XT wrote: > > Ban me i can't get him off she'll

Re: What is going on with Master?

Sixx XT appears to be a robot. Ban? Sixx XT, you can redeem yourself with an intelligent response to this message. On Tue, Apr 20, 2021 at 6:04 Sixx XT wrote: > They figured it out through the drive the guy that was hacking me and stole > my dev in 2016 Oct is under apache 2.2 > > On

Re: Log4j core

On Wed, Apr 14, 2021 at 12:43 AM Ralph Goers wrote: > I started doing the work to modularize log4j-core last night. We have a > blocker in that the disruptor has not had a release in 3 years. They > committed the change to make it an automatic module over a year ago and > since have fully

Re: Log4j core

On Wed, Apr 14, 2021 at 1:41 AM Matt Sicker wrote: > The picocli reference is likely for type conversion. Possibly removable. > Agreed, yes. Actually, weren't picocli and all CLI tools moved to log4j-tools or log4j-server or something? > On Tue, 13 Apr 2021 at 11:34, Ralph Goers > wrote: > >

Re: Garbage Free Precise Time

> wonder if that qualifies. > That is at the code level, yes. But these get inlined when called sufficiently often. So it is difficult to reason about what is eligible for escape analysis just from the code... > > Ralph > > > On Apr 2, 2021, at 12:00 AM, Remko Popma wrote: > > >

Re: Garbage Free Precise Time

My understanding is that PreciseClock is garbage-free because the JVM does escape analysis. Here is the relevant code: public void init(MutableInstant mutableInstant) { Instant instant = java.time.Clock.systemUTC().instant(); mutableInstant.initFromEpochSecond(instant.getEpochSecond(),

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

Haha! putObject? > On Mar 25, 2021, at 11:39, Ralph Goers wrote: > > I’m sure that will drive Gary nuts. Let’s call the new method “put2()”. > > Ralph > >> On Mar 24, 2021, at 5:18 PM, Remko Popma wrote: >> >> Instead of overloading the existing met

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

me given at least two of us have run into this! > > -Carter > > On Wed, Mar 24, 2021, at 19:29, Remko Popma wrote: > > I called it StringMap because the keys must be Strings. Admittedly not a > > great name. :-) > > > > Not sure exactly, but there may be cases w

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

I called it StringMap because the keys must be Strings. Admittedly not a great name. :-) Not sure exactly, but there may be cases where this change could cause an issue: putAll(final Map map) -> putAll(final Map map) On Thu, Mar 25, 2021 at 2:12 AM Ralph Goers wrote: > I looked the other day

Re: release-2.x EventLogger

Wild guess: multi-threading issue? (That's my go-to boogeyman) :-) On Thu, Mar 25, 2021 at 6:03 AM Carter Kozak wrote: > 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

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

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 wrote: > > > The PMC has recently invited Robert to join the PMC which he has > > accepted. Please join me in welcoming our newest PMC

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

Great! Thank you Ralph! On Fri, Mar 19, 2021 at 0:25 Ralph Goers wrote: > This vote has passed with 6 binding +1 votes. No other votes or concerns > were expressed. > > I will prepare an announcement email for the PMC’s approval before sending > it. > > Given the concerns about the Download

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

We should at least retain the information of which older version of Log4j maps to which older version of Java. I thought it would be nice to keep the links but don’t feel super strongly about it. :-) > On Mar 16, 2021, at 5:01, Matt Sicker wrote: > > The files will always be available

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

Is it necessary to remove the download links? I would suggest adding text saying "we cannot help if you have any issues with these versions, but if you need them, they are here". Just to clarify to whoever is interested, that if you have to (for whatever reason) use Java 6, then use Log4j 2.3;

Dependabot

Hi all, Just FYI, I unsubscribed from GitHub updates for apache/logging-log4j2, I don’t have bandwidth for the many notifications. (Trying to reduce notifications from my life... ) Probably best to @-mention me if there’s anything anyone wants some to look at. Still subscribed to dev list

Re: [VOTE] Release Log4j 2.14.1-rc1

Sorry I won't have time to validate the release. But it looks like there are enough +1 votes to proceed, phew! :-) On Mon, Mar 8, 2021 at 5:58 AM Ralph Goers wrote: > See - https://issues.apache.org/jira/projects/MDOAP/issues/MDOAP-61. This > is documented as part of the release process. > > I

Re: Putting non-String values into ThreadContextMap

Just thinking that it may be worth capturing a summary of this discussion in the JIRA to make it easier to find next time. ;-) Remko. > On Mar 6, 2021, at 3:30, Remko Popma wrote: > > Ralph is spot on. I think this was the problem I remember. Web containers, > class loaders

Re: Putting non-String values into ThreadContextMap

ethods for each of the types we would want to support. > > Ralph > >> On Mar 5, 2021, at 5:57 AM, Remko Popma wrote: >> >> I think so yes. >> But a quick read doesn’t show drawbacks. >> Maybe I’ll remember later. >> >> >>>> On M

Re: Putting non-String values into ThreadContextMap

I think so yes. But a quick read doesn’t show drawbacks. Maybe I’ll remember later. > On Mar 5, 2021, at 21:54, Volkan Yazıcı wrote: > > Are you referring to LOG4J2-1648 > <https://issues.apache.org/jira/browse/LOG4J2-1648>? > >> On Fri, Mar 5, 2021 at

Re: Putting non-String values into ThreadContextMap

There should be an existing JIRA that contains fairly extensive analysis on this topic. There are some implications/drawbacks, can’t remember off the top of my head. Would need to look at the ticket but no time now, maybe tomorrow. > On Mar 5, 2021, at 19:45, Volkan Yazıcı wrote: > >

Re: [VOTE] Move Log4PHP to dormant status

+1 On Thu, Dec 10, 2020 at 7:01 AM Matt Sicker wrote: > +1 > > On Wed, 9 Dec 2020 at 16:00, Gary Gregory wrote: > > > > +1 > > > > Gary > > > > On Wed, Dec 9, 2020, 16:20 Ralph Goers > wrote: > > > > > I started a discussion several days ago regarding moving Log4PHP to > > > dormant status

Re: LOG4J2-2965 deadlock brainstorming

Hi Carter, I’m not sure if I understand the problem and your proposed solution fully but it sounds like it may reduce the probability of a deadlock occurring but not fully eliminate the possibility. (Without looking at the code, away from pc), would it be an idea to expose a status (or perhaps

Re: Opt in for JMX server?

+1 Explicit enabling is better. On Tue, Nov 17, 2020 at 12:39 AM Gary Gregory wrote: > So we might as well do it in 2.x and set expectations for the future 3.x > IMO. > > Gary > > On Mon, Nov 16, 2020, 10:26 Ralph Goers > wrote: > > > I believe that will be a requirement in Master since JMX

Re: Identifying the set of events to be logged

Tweeted: https://twitter.com/RemkoPopma/status/1327025834398339072 On Thu, Nov 12, 2020 at 11:09 PM Gary Gregory wrote: > Great write up Ralph! > > Gary > PS: in the same vein, my "The Art of Test Driven Development: Understanding > Logging" > >

Re: Identifying the set of events to be logged

Tweeted: https://twitter.com/RemkoPopma/status/1326856942543802369 On Thu, Nov 12, 2020 at 4:15 PM Ralph Goers wrote: > FYI - > > https://www.ralphgoers.com/post/identifying-the-set-of-events-to-be-logged > < > https://www.ralphgoers.com/post/identifying-the-set-of-events-to-be-logged > > > >

Re: [VOTE] Release Log4j 2.14.0-rc1

+1 Remko. On Sat, Nov 7, 2020 at 8:46 AM Ralph Goers wrote: > This is a vote to release Log4j 2.14.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 release because... > > The

Re: [LOG4NET] Vote for release: 2.0.12

Is this not a vote thread? > On Oct 19, 2020, at 13:27, Matt Sicker wrote: > > Interesting. Anyways, as there are workarounds, it’s not a release blocker > at least. > >> On Sun, Oct 18, 2020 at 23:14 Davyd McColl wrote: >> >> Hi Matt >> >> Looks like the culprit is gulp-zip,

Re: [LOG4NET] Vote for release: 2.0.12

+1 for the release. Remko. > On Oct 19, 2020, at 5:24, Matt Sicker wrote: > > I've tried extracting it via unzip, tar, and the built in macOS GUI > unzipper, and all three respect the permissions specified which cause > permissions errors on unix. Being that this release is to help fix >

Re: [VOTE] [log4net] Release 2.0.11

+1 remko On Sat, Sep 19, 2020 at 5:56 AM Matt Sicker wrote: > How about your gpg key? I don't think we've imported that to the KEYS > file as far as I can tell? > > On Fri, 18 Sep 2020 at 15:53, Matt Sicker wrote: > > > > Oh sorry, I didn't notice that you uploaded them there (wasn't even > >

Re: [VOTE] Release Log4Net 2.0.9

t;>> pmc. Most members of the pmc should be in the set of > > recipients > > > > > >>> >> with > > > > > >>> >> >> their > > > > > >>> >> >> >>>>> gpg key. > > &

Re: [ANNOUNCE] Welcome our new committer, Stephen Webb!

Welcome aboard Stephen! Remko. > On Aug 12, 2020, at 4:41, Matt Sicker wrote: > > Hi, > > It is my pleasure to announce to the community that Stephen Webb > has joined our ranks. > > Stephen has been contributing to log4cxx for a while and helping to > shape a new release, and we think

Re: [VOTE] [log4xx] Release log4cxx 0.11.0

+1 Remko. > On Aug 11, 2020, at 6:27, Robert Middleton wrote: > > This new RC has the latest fixes that we've done(LOG4CXX-512,490,398). > > I'm not sure exactly why the autotools are there now; something about doing > the maven release triggers them. I don't think they get generated

Re: Json Template Layout

Volkan, No need to apologize! We’re all contributing at a pace we’re comfortable with. It’s good that you’re doing this at a rate you can sustain. More than a few people found themselves burn out and need to take a break from open source altogether. Enjoy! Remko. (Shameless plug) Every

  1   2   3   4   5   6   7   8   9   10   >