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 jus

Re: Catching Throwable's in AsyncAppender worker

I could see rethrowing vm errors in some cases but we definitely don't want to allow logging to stop entirely when these things occur. On Wed, Oct 28, 2020, at 17:17, Gary Gregory wrote: > Hi, I am not sure it is wise to catch VM Errors like out of memory and > stack overflow Errors... any though

Re: Catching Throwable's in AsyncAppender worker

Good catch, I recall a similar bug using fully asynchronous logging when the exception handler threw an error: https://issues.apache.org/jira/browse/LOG4J2-2333 While it's generally not considered good practice to "handle" errors, in this case it's far better than not logging! I've seen this ma

Re: Batching in appenders

this and the > aforementioned explicit batching at the interface level, please? > > In conclusion, IMHO, making batching/aggregation explicit at the interface > level will help us to avoid quite some code repetition and make the life > easier for future appenders. > > On Thu, Sep 2

Re: Batching in appenders

The AsyncAppender more or less implements what you've described, except it forwards each event in the batch individually to a delegate appender and sets the end-of-batch marker on the last one so the API isn't quite as pretty. We could implement something similar that groups events up to some in

Re: Disable dependabot

I tend to prefer using the latest versions by default, and using “break glass” overrides to back versions down. I wouldn’t want our users to be stuck on older log4j versions due to unnecessarily loose version constraints from projects like Spring. If we define the minimum version, consumers are

Re: Literals in Velocity Templates

Perhaps we could backport the documentation conversion? I've found it difficult to backport documentation changes as well. -ck On Thu, Aug 20, 2020, at 12:00, Ralph Goers wrote: > That is almost true. The site plugin configuration in master was modified in > master to support asciidoc. It is ea

Re: [Log4j] Any desire to continue using Travis now that GitHub Actions are configured for PRs?

I'm in favor of consolidation, I don't recall Travis working on both master and release-2.x at the same time. Thanks for your work to improve the build pipeline, Matt! -ck On Sun, Aug 2, 2020, at 15:03, Matt Sicker wrote: > As far as I can tell, we have full support for building PRs in both > W

Re: Build fails to compile StackLocatorUtilTest.java due to sun.reflect

I ran into a similar issue earlier and resolved it by setting my JAVA_HOME to match my java 1.8 jdk from my toolchains.xml: export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 On Wed, Jul 15, 2020, at 15:43, Kirk Lund wrote: > I'm trying to build 2.13.1 from sources using either JDK 8 or 9 on Mac

Re: Approving GitHub Dependabot PRs

I wonder if we should wait until we're ready to cut a release to update the changelog with dependency changes? That way we don't end up with changelog entries for all intermediate versions of dependencies. The release process is already relatively heavy and adding more friction to ship a release

Re: Removal of log4j-layout-jackson-* modules

Configuration breaks have always been painful for consumers for a couple reasons. We don't have a great way to tell whether an appender is still being used, and it's not clear to consumers when they upgrade libraries that their configuration may no longer work. This becomes more confusing when a

Re: Broke master due to UriUtilTest failure on Windows

Thanks, Volkan! On Tue, Jun 9, 2020, at 15:18, Volkan Yazıcı wrote: > Fixed: https://builds.apache.org/view/L/view/Logging/job/log4j/job/master/78/ > > On Sun, Jun 7, 2020 at 11:03 PM Volkan Yazıcı wrote: > > > > Sorry, I've just noticed that I broke the `master` builds due to a > > UriUtilTest

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

Thanks everyone, sorry I haven't been able to run verification over the last few weeks! On Thu, May 14, 2020, at 08:12, Gary Gregory wrote: > Thank you Ralph! > > Gary > > On Wed, May 13, 2020, 23:12 Ralph Goers wrote: > > > This vote has passed with +1 votes from Gary Gregory, Matt Sicker, a

Re: [log4j] Makr Java 8 dep with version bump

I had thought we updated to java 8 for 2.13.0, but I may be mistaken. -ck On Fri, Apr 17, 2020, at 08:49, Gary Gregory wrote: > Now that 2.x is on Java 8 (aka "The Ocho > "), I think the next release > label should be 2.14 instead of 2.13.2. > > Gary

Re: [VOTE] Log4Net dormant release

+1 On Sun, Apr 5, 2020, at 07:26, Dominik Psenner wrote: > +1 > > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Sun, Apr 5, 2020, 09:21 Volkan Yazıcı wrote: > > > +1 > > > > On Sun, 5 Apr 2020, 00:25 Ralph Goers wrote: > > > > > I have modified th

Re: [VOTE] Move Log4net to dormant state

+1 -ck On Mon, Mar 30, 2020, at 09:29, Matt Sicker wrote: > +1 here > > On Mon, Mar 30, 2020 at 08:28 Gary Gregory wrote: > > > +1 > > > > Gary > > > > On Sun, Mar 29, 2020 at 6:23 PM Ralph Goers > > wrote: > > > > > Seeing as there have been no volunteers after my last message regarding > >

Re: Dependency-free JsonTemplateLayout

Regarding 2, I don't think we regenerate performance numbers very frequently, we have older results in the documentation already: https://logging.apache.org/log4j/2.x/performance.html On Wed, Mar 11, 2020, at 10:09, Volkan Yazıcı wrote: > I have finally removed all dependencies of JsonTemplateLa

Re: Emoji in PatternLayout?

I wonder if the log4j2.properties file is being parsed as ISO-8859-1 rather than UTF-8, so we're not reading the cat properly? On Tue, Mar 10, 2020, at 20:04, Christopher wrote: > In my log4j2.properties file, I used: > > appender.console.type = Console > appender.console.name = STDERR > appende

Re: [log4j] getLogger(String... name)?

think of a reason why this would be “better”. > > Ralph > > > On Mar 10, 2020, at 7:34 AM, Carter Kozak wrote: > > > > Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string > > concatenation with dynamic values more performant than string builde

Re: [log4j] getLogger(String... name)?

Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string concatenation with dynamic values more performant than string builders. That said, requesting loggers from the context is already relatively expensive and isn't expected to be on hot paths. -ck On Tue, Mar 10, 2020, at 10:32,

Re: [VOTE] Release Log4j 2.13.1-rc2

+1 Tested on several internal products including internal logging fixture benchmarks, everything looks good. Ralph, thank you for all the work you put into releases, I really appreciate it! -ck On Thu, Feb 27, 2020, at 09:56, Marius Volkhart wrote: > +1. Thanks for fixing the dependencies and a

Re: Memory leak with log4j 2.13

Hi Srijith, Thanks for reaching out. Could you file a jira issue to track all of this information? If you could attach or link a minimal reproducer that would be tremendously helpful. Thanks, -ck On Wed, Feb 26, 2020, at 07:25, Srijith Kochunni wrote: > Hi All, > > We recently upgraded our

Re: Review request for PR#339 addressing LOG4J2-2703

Happy to take a look but I won’t be back from vacation until Sunday. -ck > On Feb 12, 2020, at 5:45 AM, Volkan Yazıcı wrote: > > Hello, > > I've created a PR[1] addressing the MapMessage JSON formatter bug > reported in LOG4J2-2703[2]. Would somebody mind reviewing it, please? > > Cheers! >

Re: PluginAttributeBuilder-vs-PluginAttribute

Perhaps we need to update our docs/javadoc. -ck > On Jan 16, 2020, at 10:54 AM, Ralph Goers wrote: > > Builders haven’t gone away, if that is what you are thinking. I think all > Matt did was make it so you could use @PluginAttribute wherever you would > have used @PluginBuilderAttribute. I

Re: The convention for thread-local allocations (TLAs)

ringBuilders and ByteBuffers? Could likely copy code from netty's > > > util library (ByteBuf et al.) or reuse stuff from commons-pool if > > > needed. This would work properly in applications, servlets, and even > > > reactive streams and lightweight threads later o

Re: Getting the most out of the Log4j 2 API

Fantastic post, thanks Ralph. I think this information would be great on the official site as well. -ck > On Jan 1, 2020, at 7:02 PM, Ralph Goers wrote: > > https://www.ralphgoers.com/post/getting-the-most-out-of-the-log4j-2-api >

Re: Constants in 3.0

Many places we use system properties I imagine we could use the constant value as a default, and allow elements to individually toggle as needed for test coverage. This provides a similar benefit without rearchitecting the codebase, but does have the potential to miss things. Unfortunately a lot

Re: The convention for thread-local allocations (TLAs)

Hi Volkan, Beyond StringBuilder instances, we attempt to clear references from all thread local references to avoid substantial overhead. In practice this works nicely because it reinforces java performance characteristics. Java threads are fairly memory expensive (not to mention the cost of in

Re: Thoughts on XML/JSON/YAML layout in Log4j 3.0 (Was: Feature request/possible contribution)

On Wed, Dec 25, 2019, at 01:38, Ralph Goers wrote: > > > > On Dec 24, 2019, at 2:06 PM, Volkan Yazıcı wrote: > > > > Indeed ColumnMapping is an alternative approach. I believe due to its > > origin, i.e., RDBMSes, it facilitates a 1-to-1 mapping particularly > > targeted at table column names,

Re: slf4j-1.8 and the event logger

> I'm not sure why the linked change is not failing revapi Our root configuration filters down to the 'org.apache.logging.log4j' prefix, but slf4j appears to live in 'org.apache.logging.slf4j' rather than 'org.apache.logging.log4j.slf4j'. -ck On Mon, Dec

slf4j-1.8 and the event logger

Hi all, Any concerns with deleting the slf4j EventLogger support in log4j-slf4j18-impl given it's still in beta, and no longer supports the event logger? My proposed change is pushed here: https://github.com/apache/logging-log4j2/pull/325 Relatedly, I'm not sure why the linked change is not fai

Re: Thoughts on Log4j 3.0

Before we make large API changes for 3.x, I think it's worth considering the benefit compared to the churn (both for us, and log4j consumers) is worth it. Can we articulate the benefits of our API break, particularly the benefits that we cannot capture without breaking our API? Based on recent d

Re: Thoughts on Log4j 3.0

Regarding unit tests and upgrading from junit 4 to junit 5, I've written some automation to ease the transition, including conversion from org.junit.Assert to the AssertJ[1] library. Thisdecouples assertions from the framework, and takes advantage of tab completion for more specific tests with l

Re: [RESULT][VOTE] Release Log4j 2-13.0-rc2

>> wrote: >>> >>> The release vote has passed with +1 votes from Carter Kozak, Remko >> Popma, Gary Gregory, and Ralph Goers. No other votes were cast. >>> >>> I will continue with the release process. >>> >>> Ralph >>

Re: [VOTE] Log4j 2.13.0-rc2

+1 Everything is green, our internal logging benchmarks do not appear to have regressed. -ck On Sat, Dec 14, 2019, at 00:23, Carter Kozak wrote: > Tests look good everywhere I've tried the artifacts, the last project is > still running tests for another hour or so. I plan to +1 in

Re: [VOTE] Log4j 2.13.0-rc2

Tests look good everywhere I've tried the artifacts, the last project is still running tests for another hour or so. I plan to +1 in the morning if everything passes. On Fri, Dec 13, 2019, at 23:03, Ralph Goers wrote: > This vote has now been open for 2 days with no feedback. Please vote. > > R

Re: [VOTE] Release Log4j 2.13.0-rc1

I'm planning to test and benchmark with several projects I'm responsible for today. On Tue, Dec 10, 2019, at 10:03, Ralph Goers wrote: > Thanks Gary, although it would have been nice to have had feedback on the > failing unit test in the 4 months since it has been in place instead of > waiting

Re: Log4j 2.13.0

; If you like it you should really thank Mikael. His initial work on this > > gave me the idea how to do it. I wish he was able to contribute more these > > days. > > > > Ralph > > > >> On Dec 2, 2019, at 9:49 AM, Carter Kozak wrote: > >> > >

Re: Log4j 2.13.0

Thanks Ralph, Your work on log4j1 configuration compatibility looks fantastic! I'd like to make sure the fix for LOG4J2-2725 goes into this release, if the PR author doesn't reply in the next day or so I'll take care of it. There are a couple related places I'd like to test for similar types of

Re: [Java] New NVMe ByteBuffer API in Java 14, potential super fast appender?

JEP 352: Non-Volatile Mapped Byte Buffers: https://openjdk.java.net/jeps/352 This sounds interesting! I'm curious what kind of performance impact we could see in practice. Regarding the repository configuration, I'm surprised we don't have tooling available to handle our use case, there must be

Re: [VOTE] Release Log4j 2.12.1-rc1

My fault, sorry! On Wed, Aug 7, 2019, at 16:00, Gary Gregory wrote: > On Wed, Aug 7, 2019 at 3:33 PM Matt Sicker wrote: > > > Nope, I didn't see it. I wonder if it's Windows-specific maybe? > > > > Yep, actually the test was written code in a *nux-specific way using \n in > a String instead of

Re: Log4j 2.12.1 release

Thanks Ralph! -ck On Sun, Aug 4, 2019, at 06:56, Gary Gregory wrote: > Sounds good. > > Gary > > On Sun, Aug 4, 2019, 03:11 Ralph Goers wrote: > > > We have a few commits on the release-2.x branch that are important that > > user’s who still use Java 7 would want. So I am planning on performi

Re: Should Log4j 2 2.x drop support for Java 7?

Sounds reasonable to me given public support for 7 ended over four years ago. It's probably worth a preemptive email to the users list so we don't surprise anyone. -ck On Tue, Jul 30, 2019, at 19:56, Matt Sicker wrote: > I’d be alright with that as well. 3.0 is a good place for modularization >

Re: Code of Conduct

Great idea Ralph. I'm in favor of adding this and anything else we can do to make more people feel comfortable contributing! -ck On Fri, Jul 12, 2019, at 20:02, Ralph Goers wrote: > First, I don’t perceive the logging project as having a problem with people’s > code of conduct. But some of the

Re: Fwd: Travel Assistance for ApacheCon NA Las Vegas 2019 now open.

Hi Folks, I've registered to attend ApacheCon Vegas, hoping to see you there! -ck On Sun, May 19, 2019, at 14:38, Matt Sicker wrote: > Hello everyone! This year, I know of at least two submissions to > ApacheCon Las Vegas that are related to Log4j. While the schedule > hasn't been confirmed or p

Re: [VOTE] Release Log4j 2.12.0-rc2

; >> Spring Cloud Configuration. > >> • LOG4J2-2586: TCP Appender should support a host name resolving to > >> multiple IP addresses. > >> • LOG4J2-2337: Allow custom end-of-line with JsonLayout. Thanks to Arvind > >> Sahare, Patrice Ferrot. > >> • LO

Re: [VOTE] Release Log4j 2.12.0-rc1

; Cloud Configuration. > • LOG4J2-2586: TCP Appender should support a host name resolving to multiple > IP addresses. > • LOG4J2-2337: Allow custom end-of-line with JsonLayout. Thanks to Arvind > Sahare, Patrice Ferrot. > • LOG4J2-2598: GZIP compression on rollover supports configur

Re: PR for LOG4J2-2639

This looks a lot like Google Flogger[1], we may want to read through their design (if you haven't done so already) to see if there's anything clever they've done that we should take advantage of. I'll take a look at the PR today. 1. https://github.com/google/flogger On Sun, Jun 23, 2019, at 05

Re: 2.12.0 Release

Wonderful, thanks Ralph! On Thu, Jun 20, 2019, at 11:41, Matt Sicker wrote: > Sounds good to me! > > On Thu, 20 Jun 2019 at 10:40, Ralph Goers wrote: > > > > Unless I get a burning desire to fix a bunch more issues I plan to do the > > release build this weekend. > > > > Ralph > > > > -- >

Re: Build failed in Jenkins: Log4j 2 2.x #3915

Sorry about that, updated! On Mon, Jun 17, 2019, at 00:08, Ralph Goers wrote: > The Log4j 2.x build is failing with a compile error. > > Ralph > > > On Jun 16, 2019, at 5:29 PM, Apache Jenkins Server > > wrote: > > > > See > >

Re: changes.xml in 3.0

I have been doing the same thing as Gary, I will prune out my duplicates shortly. -ck On Mon, Jun 3, 2019, at 10:55, Ralph Goers wrote: > Am I sure about what? Who cares when the branches diverged? If a fix or > feature was introduced prior to 3.0 then it shouldn’t be listed as something > int

Re: [log4j] release plans for 2.12.0?

We should make sure to fix the failing test (possibly dropped events when logs roll) before we release: https://issues.apache.org/jira/browse/LOG4J2-2613 I'd love to have the fix for https://issues.apache.org/jira/browse/LOG4J2-2606 available, but that's pending a more thorough review. On Wed,

Re: [log4j2] Builds failing on master (travis)

I've filed LOG4J2-2613 to track the fix. -ck https://issues.apache.org/jira/browse/LOG4J2-2613 On Thu, May 23, 2019, at 09:48, Matt Sicker wrote: > I’m normally OK with that sort of thing provided it’s fixed before a > release. > > On Thu, May 23, 2019 at 06:23, Carter Kozak

Re: [log4j2] Builds failing on master (travis)

l take a look when I can. > > Ralph > > > On May 14, 2019, at 7:21 AM, Carter Kozak wrote: > > > > It looks like github builds on master have been broken since > > 619707edd57fd6f562ea154d1eac56708b6634e2 > > > > LOG4J2-2602 - Update file time whe

Re: Hide message in throwable

Once you've implemented a LogEventPatternConverter which overrides "handlesThrowable" to return true, you will also need to use that pattern in the PatternLayout pattern. This can be a little bit confusing since the pattern layout will automatically add a default throwable pattern converter to t

Re: LOG4J2-2606: Very high CPU utilization when the async queue is full

at 15:02, Gary Gregory wrote: > Would it make sense to have an optional "drop events on the floor" policy > when things get busy? > > Gary > > On Fri, May 17, 2019, 14:52 Carter Kozak wrote: > > > Hi friends, > > > > I've filed LOG4J2-2606 af

LOG4J2-2606: Very high CPU utilization when the async queue is full

Hi friends, I've filed LOG4J2-2606 after tracking down the issue in prod. It's frightening because the result was instability across entire box due to CPU starvation, caused by a full logging queue from heavy load. I'm curious if anyone else has run into this behavior. We may want to change the

[log4j2] Builds failing on master (travis)

It looks like github builds on master have been broken since 619707edd57fd6f562ea154d1eac56708b6634e2 LOG4J2-2602 - Update file time when size based triggering policy is used without a time-based triggering policy Failing with: [ERROR] Failures: [ERROR] RollingAppenderSizeWithTimeTest.testAppen

Re: LOG4J2-913 Code Reviews

Thanks Ralph! On Mon, May 6, 2019, at 13:31, Ralph Goers wrote: > Carter, thanks for the code review comments. I will try to address them over > the next couple of days and probably won’t comment on them until then so > please don’t think I am ignoring them. But if you find stuff that you > abs

Re: RollingRandomAccessFileAppender does not wait for compression to complete on LogContext.stop()

Hi Steffen, I've seen this occur in two scenarios: 1. The JVM is stopped in an unexpected way (e.g. process killed, system loses power, Runtime.halt) while files roll 2. Compressing files takes long enough in a shutdown hook that the JVM is forcefully killed by a service wrapper (resulting in th

Re: Build failed in Jenkins: Log4j 2 2.x #3867

tries because I thought the were all > prior to 2.11.2. I will add these entries back. > > Ralph > >> On Apr 30, 2019, at 9:38 PM, Carter Kozak wrote: >> >> That's odd, thank you for flagging the failure. I would have expected >> 81249177c60cd98c35a1e19541

Re: Build failed in Jenkins: Log4j 2 2.x #3867

That's odd, thank you for flagging the failure. I would have expected 81249177c60cd98c35a1e19541d1663af1047442 to have caused this before 2.11.2 was released. I will take a look tomorrow to figure out why my change to GzCompressAction would trigger revapi on WriterAppender. At a glance it seems

Re: JDK version for building

I've been doing the same successfully for local builds and testing, though I haven't verified that the bytecode is generated targeting java 9. On Fri, Apr 19, 2019, at 00:10, Matt Sicker wrote: > I set up my local toolchain config file with java 8 and 11. There’s a bug > in pom.xml currently wher

Re: StackOverflowError at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)

Yep, that looks like the failure scenario we've highlighted in red in the docs. https://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html I'm not sure how we would guard against it, arguably failing silently (not logging) in this case would be worse than throwing. On Thu, Apr 11, 2019, at 0

Re: [VOTE] Release Log4j 2.11.2-rc3

+1 My projects all pass tests, and product-specific benchmarks haven't regressed. I can't thank you enough for taking the time to put this release together, thanks Ralph! On Wed, Feb 6, 2019 at 10:29 AM Gary Gregory wrote: > > +1 > > From ' git checkout tags/log4j-2.11.2-rc3' > > Apache RAT ch

Re: [VOTE] Release Log4j 2.11.2-rc1

A few hits show up on public github that will break if we don't fix WriterAppender.newBuilder for 2.11.2: https://github.com/search?l=Java&q=WriterAppender.newBuilder%28%29&type=Code On Mon, Feb 4, 2019 at 10:24 AM Carter Kozak wrote: > > That is correct, the builder had no u

Re: [VOTE] Release Log4j 2.11.2-rc1

ted at it? > > Ralph > > > On Feb 4, 2019, at 7:53 AM, Carter Kozak wrote: > > > > Sorry, I think part of a commit that modified WriterAppender never > > made it to the master branch. > > I've provided a PR against release-2.x: > > https://github.com/apa

Re: [VOTE] Release Log4j 2.11.2-rc1

wrote: > > I’m a little confused. When I look at the source for release-2.x it already > looks just like what you changed it to. In looking at your link below, it is > a PR against master. Are you sure you are comparing the correct branch? > > Ralph > > > On Feb 4, 2019,

Re: [VOTE] Release Log4j 2.11.2-rc1

I've discovered a regression between 2.11.1 and 2.11.2-rc1 which breaks compilation for consumers of WriterAppender.Builder, illustrated here: https://github.com/apache/logging-log4j2/pull/254 I can take a closer look into the cause this afternoon. On Sun, Feb 3, 2019 at 7:43 PM Carter

Re: [VOTE] Release Log4j 2.11.2-rc1

Oof "uses a more faster method" in the LOG4J2-2391 note. I think I messed up an edit between "more performant" and "faster". Probably not worth rebuilding for just the release note. I've run tests on a few projects I maintain, results are passing so far. I'll have a few more sets of results in the

Re: [log4j] 2.11.2 release?

I'm interested in the 2.11.2 release as well, happy to help out if there's anything you need a hand with. On Tue, Jan 22, 2019 at 11:34 AM Gary Gregory wrote: > > Hi Ralph, > > Where are for 2.11.2? > > Gary > > On Mon, Nov 26, 2018 at 8:54 AM Ralph Goers > wrote: > > > I did not get the release

Re: What's left for 2.11.2?

Red-green color blindness is fairly common as well :-) On Fri, Dec 7, 2018 at 5:10 PM Matt Sicker wrote: > > On Fri, 7 Dec 2018 at 15:28, Gary Gregory wrote: > > > 2.x is blue (why not green Jenkins? why?) > > > > From Wikipedia: > Japanese traffic signals mostly follow the same rule except t

Re: [log4j] Toward 3.0

It would be helpful if we could implement failover and retrial in a way that is compatible with disabling immediate flush. The current implementations may surface a failure to the attempt to log an end of batch, but don't provide a mechanism to retry queued or buffered events. On Tue, Nov 6, 2018

Re: [log4j] Toward 3.0

I'd like to consider potential API breaking refactors around ThrowableProxy regarding LOG4J2-2391. The jar lookup is incredibly expensive and creates a great deal of additional complexity. On Mon, Nov 5, 2018 at 4:06 PM Matt Sicker wrote: > > One of my biggest bikeshedding questions I've been thin

Re: [log4j] Better time values in config files.

I agree that we shouldn't use the Duration.parse functionality, but perhaps we can define our own parser to convert strings into Duration objects similar to the parse function in TimeValue. Thoughts? On Mon, Nov 5, 2018 at 2:33 PM Gary Gregory wrote: > > On Mon, Nov 5, 2018 at 12:1

Re: [log4j] Better time values in config files.

Big +1 for values with units. Unless we need to support this on 2.x, should we take advantage of java 8 java.time.Duration as our value type, and only implement the parser ourselves? On Mon, Nov 5, 2018 at 1:54 PM Gary Gregory wrote: > > Hi All: > > Today in appenders like the JMS Appender you can

Re: master is failing compilation

Should be resolved :-) http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/924a476c On Mon, Nov 5, 2018 at 11:22 AM Carter Kozak wrote: > > Looks like this commit broke the JUL WrappedLogger: > bccb9a365a7de68431b7165a33d514f07e659528 > > -ck

master is failing compilation

Looks like this commit broke the JUL WrappedLogger: bccb9a365a7de68431b7165a33d514f07e659528 -ck

Re: Pull Request for [LOG4J2-2405] Better handling of %highlight pattern when using jul-bridge

The PR looks good to me as well. As a future improvement we may want to fall back on a failed lookup on Level.getName() to Level.getStandardLevel().getName() for the closest matching standard level style. On Sat, Nov 3, 2018 at 11:47 AM Gary Gregory wrote: > > Marco: Thank you for updating your P

Re: [log4j2] Release 2.11.2?

A 2.11.2 release would be great! On Thu, Oct 11, 2018 at 6:08 AM Ralph Goers wrote: > > I don’t recall you asking about a 2.11.2 release previously. I would think I > might be able to do it on Thanksgiving weekend. > > Ralph > > > On Oct 10, 2018, at 6:20 PM, Gary Gregory wrote: > > > > Hi All:

Re: [GitHub] logging-log4j2 pull request #202: [LOG4J2-2391] Improve ThrowableProxy perfo...

g-log4j2/commit/64bfd314 Best, -ck On Fri, Oct 5, 2018 at 4:54 PM Ralph Goers wrote: > > Carter, > > Did you check in this benchmark? I posted these numbers on Jigsaw-dev and > they would like to see the benchmark. > > Ralph > > > On Aug 7, 2018, at 8:10 PM, Carter Kozak

[log4j][LOG4J2-2423] Rolling and Retention

This morning I realized that my understanding of how our rolling appenders handle retention was flawed. When the file pattern includes a date, the limit is applied per day (or the smallest interval present in the date), not total rolled files over time. Is this behavior expected? Is there a better

Re: [GitHub] logging-log4j2 pull request #202: [LOG4J2-2391] Improve ThrowableProxy perfo...

oks similar to mine. > > Ralph > > > On Aug 9, 2018, at 11:14 AM, Ralph Goers wrote: > > > > No, I haven’t committed it. I started looking into it but got sidetracked > > with having to earn a living. > > > > Ralph > > > >> On Aug 9, 2

Re: [GitHub] logging-log4j2 pull request #202: [LOG4J2-2391] Improve ThrowableProxy perfo...

Aug 9, 2018 at 1:56 PM, Ralph Goers wrote: > I created a micro benchmark for the extended stack trace. It isn’t pretty. > > Ralph > >> On Aug 9, 2018, at 10:53 AM, Carter Kozak wrote: >> >> That's true, as long as we collect the stack trace when the >> Th

Re: [GitHub] logging-log4j2 pull request #202: [LOG4J2-2391] Improve ThrowableProxy perfo...

alph Goers wrote: > What I don’t understand is that ThrowableProxy seems to be doing a whole > bunch of stuff in the constructor. I would think a lot of that could be > deferred until the Throwable is being rendered. > > Ralph > >> On Aug 9, 2018, at 8:10 AM, Carter Kozak

Re: [GitHub] logging-log4j2 pull request #202: [LOG4J2-2391] Improve ThrowableProxy perfo...

erters rely on it. > > Ralph > >> On Aug 8, 2018, at 8:34 AM, Carter Kozak wrote: >> >> I'm curious what you would think of a system property to disable >> ThrowableProxy creation? >> My initial preference was to avoid this type of flag and make the

Re: [GitHub] logging-log4j2 pull request #202: [LOG4J2-2391] Improve ThrowableProxy perfo...

Proxy refactors significantly more difficult in the future. -ck On Tue, Aug 7, 2018 at 11:10 PM, Carter Kozak wrote: > My guess is that StackWalker provides additional information beyond > the array of classes > supplied by the SecurityManager, though I've not done a thorough analy

Re: [GitHub] logging-log4j2 pull request #202: [LOG4J2-2391] Improve ThrowableProxy perfo...

these changes as the patch at: >> >>https://github.com/apache/logging-log4j2/pull/202.patch >> >> To close this pull request, make a commit to your master/trunk branch >> with (at least) the following in the commit message: >> >>This closes #202 >&

[log4j] Proposal for asynchronous formatting on reusable messages

Hi folks, I've filed LOG4J2-2399 with a proposal for supporting asynchronous message formatting on reusable messages, with a bit of background explaining why it would be ideal for my use case. I'd appreciate feedback on the idea. If we're happy with it, I have a bit of time this week to put togeth

Re: [VOTE] Release Log4j 2.11.1-rc1

+1 I've tested the snapshot similarly and ran a suite of benchmarks overnight without signs of performance degradation in my usage. Best, Carter On Tue, Jul 24, 2018 at 11:53 AM, Gary Gregory wrote: > More reviews please :-) More reviews please :-) > > I've already votes and FWIW I am testing

Re: logging-log4j2 git commit: Inline private StringBuilders.escapeAndDecrement

ommit/ac0bf4bb >> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/ac0bf4bb >> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/ac0bf4bb >> >> Branch: refs/heads/master >> Commit: ac0bf4bbe85cd4a07af195b3b001717a72888794 >> Parents: 1d

[log4j] Reusable message memory leaks

Hi all, I've found another reusable message memory leak[1]. I've pushed a proposed fix[2] which adds a new "Clearable" interface we can use to reset reusable messages. Ideally this would be a default method on ReusableMessage, however I would like to get this fix into 2.11.1 so I've made the inter

Re: logging-log4j2 git commit: LOG4J2-2362 ReusableObjectMessage memory leak

t; Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/377afa00 >> >> Branch: refs/heads/release-2.x >> Commit: 377afa006b5102c508f1e6578bc05da24385907f >> Parents: b66f09c >> Author: Carter Kozak >> Authored: Fri Jun 29 16:02:55 2018 -0400 >> Co

Re: Reminder - [VOTE] Release Log4j Audit 1.0.0 RC1

I didn't realize I was eligible to vote, I'll take a closer look through the codebase tomorrow. -ck On Thu, Jun 14, 2018 at 8:08 PM, Ralph Goers wrote: > I should have also pointed out that ANY PMC member, committer or user is > welcome to look at the project and vote on it, not just those who

Re: logging-log4j2 git commit: [LOG4J2-2351] Added AbstractLogEvent.getMutableInstant

ing-log4j2/repo >> Commit: >> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/b54045f7 >> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/b54045f7 >> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/b54045f7 >> >> B

[log4j] 2.11.1 release timeline

Hi all, Do we have a release schedule for 2.11.1? I'm more than happy to assist with the process. Best, -ck

Re: [log4j] master unit failures

a test that was testing a failure > scenario that couldn't quiet the exception logs. Wonder if it's related? > > On 31 May 2018 at 17:45, Carter Kozak wrote: > >> That looks like a recurring flake we've had for at least a couple >> months months: https://travis

Re: [log4j] master unit failures

That looks like a recurring flake we've had for at least a couple months months: https://travis-ci.org/apache/logging-log4j2/builds/365329034 Prior to that commit most builds failed before running tests, so I wasn't able to check for the issue earlier. Unfortunately I'm unable to reproduce this fa

Re: Github PR 163

If my understanding of the PR is correct, I've implemented similar output using PatternLayout with a pattern along these lines, though it's not very pretty to read: {"timestamp":"%d{ISO8601}", "level":"%p", "logger":"%encode{%c}{JSON}", "thread":"%encode{%t}{JSON}", "message": "%encode{%m}{JSON}",

Re: [Log4j] Windows build failures on Jenkins

I've been having issues with EquinoxLoadApiBundleTest, FelixLoadApiBundleTest, and FileAppenderPermissionsTest (has some special casing on osx which may not be compatible with my environment, works on linux though) on osx, haven't had a chance to dig into them quite yet. I've executed the tests on

<    1   2   3   >