Re: [VOTE] Release Log4j Scala API 12.0-rc1

Housekeeping: The old RC jars in https://dist.apache.org/repos/dist/dev/logging/log4j/ for 2.13.0 should be deleted. Gary On Sat, Feb 1, 2020 at 5:38 PM Matt Sicker wrote: > This is a vote to release Log4j Scala API 12.0-rc1. This vote will > remain open for at least 72 hours and requires 3 +1

Re: [VOTE] Release Log4j Scala API 12.0-rc1

IMO the staging are https://dist.apache.org/repos/dist/dev/logging/log4j/scala/ should include release notes. Gary On Sat, Feb 1, 2020 at 5:38 PM Matt Sicker wrote: > This is a vote to release Log4j Scala API 12.0-rc1. This vote will > remain open for at least 72 hours and requires 3 +1 votes a

Re: [VOTE] Release Log4j Scala API 12.0-rc1

-0 I was able to build according to src/asciidoctor/build.adoc. On the site https://jvz.github.io/log4j-scala-site/ In the table for "API Documentation", there is no link for 2.13 (this release) In the download section, the links are still labeled and for 2.12 (needs to be 2.13). There are mo

Re: [VOTE] Release Log4j Scala API 12.0-rc1

On Sat, Feb 1, 2020 at 6:43 PM Ralph Goers wrote: > I didn’t try to run it but based on a cursory examination of the web site > and artifacts - I did notice the site mentions md5 instead of sha256 and > sha512. > Note that the proper sha256/512 are here https://dist.apache.org/repos/dist/dev/log

Re: Upcoming release candidates

Matt, If have Kotlin specific instructions I am happy to test those. Gary On Sat, Feb 1, 2020, 14:56 Matt Sicker wrote: > Hi all, > > I’ll be attempting to start release processes for both the Scala and Kotlin > APIs today. For the Scala API, this mostly involves Scala 2.13 support > (frequent

Re: [log4j] Releasing 2.13.1?

On Sat, Jan 18, 2020 at 12:59 PM Gary Gregory wrote: > Hi All: > > I just ran into and fixed > https://issues.apache.org/jira/browse/LOG4J2-2762 for which I do not have > decent workaround in 2.13.0. > > Any thoughts on releasing 2.13.1? > ping? Gary > > > Gary >

Re: Migrating from Travis CI to GitHub Actions

FWIW, over at Apache Commons, some components use both. Gary On Mon, Jan 20, 2020 at 3:42 PM Matt Sicker wrote: > I'd be on board with trying that out as an alternative to Travis. > Anything to help test PRs more reliably is great, especially without > having to overload our Jenkins instance (w

Re: FOSDEM'20 attendance

Not me but have fun :-) On Mon, Jan 20, 2020 at 2:46 PM Volkan Yazıcı wrote: > Will any of you Log4j enthusiasts, developers plan to show up in > FOSDEM'20[1]? If so, I will be more than happy to share a beer/coffee > with you. > > [1] https://fosdem.org >

[log4j] Releasing 2.13.1?

Hi All: I just ran into and fixed https://issues.apache.org/jira/browse/LOG4J2-2762 for which I do not have decent workaround in 2.13.0. Any thoughts on releasing 2.13.1? Gary

Re: eol and null-delimiter in Jackson layouts

On Fri, Jan 17, 2020 at 10:01 AM Gary Gregory wrote: > Does this help: https://logging.apache.org/log4j/2.x/manual/layouts.html > But basically you cannot collapse the 2 since you want to be able to pretty- vs. compact-print AND you want to terminate the whole thing with an optional NUL.

Re: eol and null-delimiter in Jackson layouts

On Fri, Jan 17, 2020 at 12:50 PM Matt Sicker wrote: > On Fri, 17 Jan 2020 at 07:44, Volkan Yazıcı > wrote: > > (Sorry for spamming the list. Is there a FreeNode channel or sth > > similar where I can direct my questions to?) > > I believe this is exactly the purpose of the dev@ mailing list. Tho

Re: eol and null-delimiter in Jackson layouts

endOfLine : compact && !eventEol ? > COMPACT_EOL : DEFAULT_EOL; > > I will appreciate some hints here. > > (Sorry for spamming the list. Is there a FreeNode channel or sth > similar where I can direct my questions to?) > > On Fri, Jan 17, 2020 at 2:33 PM Gary

Re: final modifier in method args and local variables

So you might as well follow convention ;-) Gary On Fri, Jan 17, 2020 at 8:16 AM Ralph Goers wrote: > That is a convention Gary imitated. If you don’t add the final keywords > you can be sure Gary will do it. > > Ralph > > > On Jan 17, 2020, at 3:55 AM, Volkan Yazıcı > wrote: > > > > Hello, > >

Re: eol and null-delimiter in Jackson layouts

On Fri, Jan 17, 2020 at 8:16 AM Ralph Goers wrote: > Makes sense to me. > Not to me ;-) The optional NULL is to end an event. An EOL is to end a line when you are not using a compact format. Gary > > Ralph > > > On Jan 17, 2020, at 6:11 AM, Volkan Yazıcı > wrote: > > > > Jackson layouts acce

Re: final modifier in method args and local variables

I'm not sure if we flag missing final keywords in Checkstyle/PMD/Spotbugs but I know projects that do. I'm all for keeping on using final, it's one less thing to consider when grooking code please see https://garygregory.wordpress.com/2013/01/26/the-final-kiss-in-java/ Gary On Fri, Jan 17, 2020

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

Can we please not invent yet another pooling mechanism at Apache? ;-) OTOH bringing in Apache Commons Pool might be too heavy handed. For the two main server stacks I work on at my day job, it's not an issue since I already use Commons Pool. Actually, now that I think of it: Commons DBCP (which de

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

I like the idea of centrally controlling these objects. This should make resource monitoring easier as well. Gary On Mon, Jan 6, 2020, 13:09 Matt Sicker wrote: > Would it be useful to implement some sort of buffer pool for > StringBuilders and ByteBuffers? Could likely copy code from netty's >

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

On Mon, Dec 23, 2019 at 6:25 PM Ralph Goers wrote: > Thanks, > > What I was thinking was that I would just like a more flexible way to > specify what should be included in the JSON. In its current form the JSON > Layout just creates a serialized version of a LogEvent. I would prefer it > if users

Re: Blog post

Thanks for the link, nice write up :-) Gary On Tue, Dec 17, 2019, 00:58 Apache wrote: > I thought you all might be interested in this - > https://www.ralphgoers.com/home/why-was-log4j-2-created. I plan to write > a few entries on what is new in Log4J. > > Ralph

Re: Thoughts on Log4j 3.0

And, so for 3.0: Move org.apache.logging.log4j.internal.DefaultLogBuilder to org.apache.logging.log4j.spi since it is the only place seems to be used from and make it package private unless I am misunderstanding the layout? Gary On Mon, Dec 16, 2019 at 3:03 PM Gary Gregory wrote: > I'

Re: Thoughts on Log4j 3.0

lean things up (for my definition of "clean" of course :-) > > Gary > > On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory > wrote: > >> >> >> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers >> wrote: >> >>> >>> >>> > On Dec

Re: Thoughts on Log4j 3.0

On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers wrote: > > > > On Dec 16, 2019, at 11:13 AM, Gary Gregory > wrote: > > > > From the 10,000 ft level, within one app: > > > > - Log4j 2 configures itself by finding a log4j2.xml file. > > - Log4j 3 c

Re: Thoughts on Log4j 3.0

2019 at 2:48 PM Gary Gregory wrote: > > > On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers > wrote: > >> >> >> > On Dec 16, 2019, at 11:13 AM, Gary Gregory >> wrote: >> > >> > From the 10,000 ft level, within one app: >> > >> &g

Re: Thoughts on Log4j 3.0

On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers wrote: > > > > On Dec 16, 2019, at 11:13 AM, Gary Gregory > wrote: > > > > From the 10,000 ft level, within one app: > > > > - Log4j 2 configures itself by finding a log4j2.xml file. > > - Log4j 3 c

Re: Thoughts on Log4j 3.0

On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory wrote: > > > On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers > wrote: > >> >> >> > On Dec 16, 2019, at 11:13 AM, Gary Gregory >> wrote: >> > >> > From the 10,000 ft level, within one app: &

Re: Thoughts on Log4j 3.0

ake sure it's worth it? > > -ck > > On Mon, Dec 16, 2019, at 13:13, Gary Gregory wrote: > > From the 10,000 ft level, within one app: > > > > - Log4j 2 configures itself by finding a log4j2.xml file. > > - Log4j 3 configures itself by finding a log4j3.xml fi

Re: Thoughts on Log4j 3.0

>From the 10,000 ft level, within one app: - Log4j 2 configures itself by finding a log4j2.xml file. - Log4j 3 configures itself by finding a log4j3.xml file. - Both can co-exist happily - The bridge exercise can be done separately. The APIs b/w Log4j 2 and 3 are already not binary compatible WRT

Re: Thoughts on Log4j 3.0

On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers wrote: > > > > On Dec 15, 2019, at 2:44 PM, Gary Gregory > wrote: > > > > All good thoughts. > > > > I suspect that now that 2.x is on Java 8 there are some clean ups we will > > want to do. What comes to m

Re: Thoughts on Log4j 3.0

On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers wrote: > > > > On Dec 15, 2019, at 2:44 PM, Gary Gregory > wrote: > > > > All good thoughts. > > > > I suspect that now that 2.x is on Java 8 there are some clean ups we will > > want to do. What comes to m

Re: Is there any chance that there will be a security fix for log4j-v1.2.17?

ch less attempted to perform a release. > Log4j 1.x supported an ancient version of the JDK (1.2?). I am not even > sure if that is possible any more. The oldest version I have installed is > 1.7. I would have no idea how to validate that it was still compatible. > > Ralph >

Re: Thoughts on Log4j 3.0

All good thoughts. I suspect that now that 2.x is on Java 8 there are some clean ups we will want to do. What comes to mind immediately is deprecating our functional interfaces in favor of the ones in java.util.function. Then we can drop our custom functional interfaces in the 3.0 branch (if that

Re: Is there any chance that there will be a security fix for log4j-v1.2.17?

Security issues should not be discussed in public for obvious reasons. Please see https://www.apache.org/security/ Gary On Sun, Dec 15, 2019 at 7:01 AM Andrew Marlow wrote: > Hello everyone, > > I know that log4j-v1 was announced as end of life back in 2015 and that all > effort is on log4j2.

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

Yes, thank you Ralph. Gary On Sun, Dec 15, 2019, 03:54 Remko Popma wrote: > Thank you Ralph! > > > > On Dec 15, 2019, at 15:40, Ralph Goers > wrote: > > > > The release vote has passed with +1 votes from Carter Kozak, Remko > Popma, Gary Gregory, and Ralp

Re: [VOTE] Log4j 2.13.0-rc2

+1 Based on the git tag. Maven tool-chain pointing to Java 8 through 14. Apache RAT check OK Apache CLIRR check on log4j-api: Could not find a combo of command to check on the command line. Running 'mvn clean package' using Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home

Re: [VOTE] Release Log4j 2.13.0-rc1

I'm not OK with that kind of workaround, as a user it does not inspire confidence. I won't -1 though. Gary On Tue, Dec 10, 2019 at 12:21 AM Ralph Goers wrote: > So add @Ignore to that one test. > > Ralph > > > On Dec 9, 2019, at 10:18 PM, Gary Gregory > wrote:

Re: [VOTE] Release Log4j 2.13.0-rc1

t; > >>> On Dec 9, 2019, at 8:40 PM, Ralph Goers > wrote: > >>> > >>> That test class hasn’t been modified since the last release. I > obviously don’t get that error on my Mac and I have run the build many > times, so it must be something Win

Re: [VOTE] Release Log4j 2.13.0-rc1

I get this failure running 'mvn clean package': [ERROR] Failures: [ERROR] LoggerTest.builder:69 Incorrect message 3 Expected: a string starting with " WARN Log4j rocks! java.lang.Throwable: This is a test\n\tat org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:65)" but: was " WARN

Re: [jira] [Closed] (LOG4J2-2418) NullPointerException when closing never used RollingRandomAccessFileAppender

On Mon, Dec 2, 2019 at 2:02 PM Ralph Goers wrote: > Gary, it looks like you merged this but I don’t see an entry for it in > changes.xml. > I do, here: https://github.com/apache/logging-log4j2/blob/67f9d1385d83c2cc16b692813605521f43384fc8/src/changes/changes.xml#L276 Gary > > Ralph > > > On D

Re: [Meta] Article about syslog security limitations

On Mon, Dec 2, 2019 at 11:34 AM Ralph Goers wrote: > > > > On Dec 2, 2019, at 9:25 AM, Gary Gregory wrote: > > > > On Mon, Dec 2, 2019 at 11:24 AM Ralph Goers > > wrote: > > > >> All of this would apply to the original BSD syslog format. RFC 5424 &

Re: [Meta] Article about syslog security limitations

2.13.0 will recommend using GELF. > When you do you we can get a 2.13.0? Gary > > Ralph > > > On Dec 2, 2019, at 9:02 AM, Gary Gregory wrote: > > > > This is what it says for me: > > " > > What's wrong with syslog? A lot, actually. > > >

Re: [Meta] Article about syslog security limitations

This is what it says for me: " What's wrong with syslog? A lot, actually. I recently had a post make it to Hacker News , lobste.rs

Re: [Java] Proposal: replacing plugin annotations with javax.inject ones

That sounds good Matt, I say go for it. Gary On Tue, Oct 8, 2019, 16:08 Matt Sicker wrote: > I've been doing some experiments with the plugin system for 3.x > lately, and I've recently pushed some changes toward that end. One of > the insights I gained from it was that some of our plugin annota

Re: Tagging releases

I think so yes, but RC tags should not be needed there IMO. Gary On Mon, Sep 9, 2019, 11:12 Matt Sicker wrote: > So should we copy all the previous release tags into rel/? > > On Mon, 9 Sep 2019 at 07:18, Gary Gregory wrote: > > > > I was just made aware over at Apach

Tagging releases

I was just made aware over at Apache Commons that Apache Infra will protect/preserve tags under "rel/" such that these cannot be deleted and should be used for the purpose of tagging releases. Please see below. -- Forwarded message - From: David Nalley Date: Sun, 10 Jan 2016 at 18

Re: [Java] GitHub usage stats seem interesting

At work we have one main hurdle to update one our projects from Log4j 1 to 2: How do we migrate installed applications from Log4j1 configurations to Log4j2. I started to work on this a long time ago but only got the basics working which is in Log4j2 now: The idea is to read a Log4j1 config file as

Re: "fat" JARs plus custom plugins?

I had a similar problem to solve a while back. I used something like https://github.com/edwgiz/maven-shaded-log4j-transformer Gary On Wed, Aug 21, 2019 at 12:20 PM Gregg Donovan wrote: > Hello! > > I'm working on getting Etsy's custom StackdriverJsonLayout Log4J plugin to > work with our Bazel-

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

ok at the justifications for those as > examples. > > Ralph > > > On Aug 16, 2019, at 11:23 AM, Gary Gregory > wrote: > > > > It looks like a bug in revapi to me: it does not know about type > erasures. > > I created a new Maven project that depends

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

recommended changes to revapi.json to > document why compatibility was broken. > > Ralph > > > > On Aug 15, 2019, at 4:54 PM, Gary Gregory > wrote: > > > > I fixed it already in both branches. > > > > Gary > > > > On Thu, Aug 15

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

ipTests in log4j-core. It will break for you too. > > Please look at the Jenkins build and fix the problems by either reverting > the breakage or by adding the recommended changes to revapi.json to > document why compatibility was broken. > > Ralph > > > > On Aug 15,

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-2673] OutputStreamAppender.Builder ignores setFilter().

ository. > >>> > >>> ggregory pushed a commit to branch release-2.x > >>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git > >>> > >>> > >>> The following commit(s) were added to refs/heads/release-2.x by this &

Re: Due-to in changes.xml

Talph, Feel free to edit changes.xml as you best see fit. Gary On Tue, Aug 13, 2019, 22:37 Ralph Goers wrote: > The “By” column is a link to the team list that includes all your > information. If you don’t use your userid then the link won’t index into > the list properly. > > Frankly, putting

Re: Due-to in changes.xml

The convention I use is dev is the committer and due-to is the creator of the Jira or PR followed by whomever else touched the code. Gary On Tue, Aug 13, 2019, 20:13 Ralph Goers wrote: > Gary, > > I am wondering why you have recently gotten in the habit of adding > yourself to the due-to field

Re: [Discuss] Log4j 2.12.1 release

+1 fine with me. Thank you for RM'ing. Gary On Thu, Aug 8, 2019, 13:19 Ralph Goers wrote: > Normally release votes are open for 72hrs. However, I will be going out of > town tomorrow and not returning until Sunday. Unless there are objections > I would like to close the vote early, in about 10

Re: [VOTE] Release Log4j 2.12.1-rc1

-api Gary On Wed, Aug 7, 2019 at 4:03 PM Carter Kozak wrote: > 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 ma

Re: [VOTE] Release Log4j 2.12.1-rc1

. I'll continue validating... Gary > > On Wed, 7 Aug 2019 at 14:16, Gary Gregory wrote: > > > > So you did not see the unit test failure I reported? > > > > Gary > > > > On Wed, Aug 7, 2019, 13:01 Matt Sicker wrote: >

Re: [VOTE] Release Log4j 2.12.1-rc1

; > I still need to try the release itself (build from source, verify > signatures, etc) before voting. > > > > On Wed, Aug 7, 2019 at 10:00, Ralph Goers > wrote: > >> > >> If it is just a test failing due to a change to the ListAppender I > don’t think

Re: [VOTE] Release Log4j 2.12.1-rc1

elease between 2.11.1 and this version. Or it could be that > > the code I'm testing out relied on a bug. I haven't figured out the > > issue yet, though it's strange so far. > > > > On Wed, 7 Aug 2019 at 08:31, Gary Gregory > wrote: > > > > >

Re: [VOTE] Release Log4j 2.12.1-rc1

Based on the tag git checkout tags/log4j-2.12.1-rc1 Apache RAT check OK I could not find a way to run the CLIRR check on the log4j-api module. Running 'mvn clean install' OK using: Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T15:00:29-04:00) Maven home: C:\Java\apach

Re: Log4j 2.12.1 release

g in the JDBC Appender where bufferSize="0" still uses a JDBC batch. I'll fix that... Gary > > On Tue, 6 Aug 2019 at 09:40, Gary Gregory wrote: > > > > On Tue, Aug 6, 2019 at 10:39 AM Gary Gregory > wrote: > > > > > On Mon, Aug 5, 2019 at 1

Re: Log4j 2.12.1 release

On Tue, Aug 6, 2019 at 10:39 AM Gary Gregory wrote: > On Mon, Aug 5, 2019 at 11:00 AM Gary Gregory > wrote: > >> FYI: I plan on looking at >> https://issues.apache.org/jira/browse/LOG4J2-2667 today/tonight. >> > > Please see my comments in the Jira above WRT

Re: Log4j 2.12.1 release

On Mon, Aug 5, 2019 at 11:00 AM Gary Gregory wrote: > FYI: I plan on looking at > https://issues.apache.org/jira/browse/LOG4J2-2667 today/tonight. > Please see my comments in the Jira above WRT batching. The upshot is that to workaround buggy JDBC drivers (My tests show no issues

Re: Log4j 2.12.1 release

investigate those before performing a release. > > > > Ralph > > > >> On Aug 4, 2019, at 8:26 AM, Matt Sicker wrote: > >> > >> Sounds like a plan! > >> > >> On Sun, Aug 4, 2019 at 10:13, Carter Kozak wrote: > >>

Re: Log4j 2.12.1 release

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 performing a > 2.12.1 release later today. I will then make the changes to the pom to > target

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

+1 for Java 8. Gary On Tue, Jul 30, 2019 at 7:49 PM Ralph Goers wrote: > I implemented a logging builder pattern in the Log4j API on the master > branch. I was able to do that in a backward compatible manner by using Java > 8 default methods. Although I could implement those default methods in

Re: [Discuss] Release Log4j 2.12.0-rc2

x” is to have unit automatically ignore those tests when the > classes > > >> don’t exist. However, as I said before, nothing has changed in this > regard > > >> from the past several releases which you voted +1 on. This means it is > > >> suddenly important to

Re: [Discuss] Release Log4j 2.12.0-rc2

On Fri, Jun 28, 2019 at 8:25 AM Gary Gregory wrote: > Ah! You can force compilation to be skipped with '-Dmaven.main.skip' so > you can 'compile' and 'install' jars with Java 8 and then run 'mvn test > -Dmaven.main.skip'

Re: [Discuss] Release Log4j 2.12.0-rc2

0. Gary On Thu, Jun 27, 2019 at 8:54 PM Matt Sicker wrote: > The java setup has me blocked currently for developing more complicated > code where I want to use inline test execution in my IDE. It’s not a > blocker for building, though. > > On Thu, Jun 27, 2019 at 19:51, Gary Gregory &g

Re: [Discuss] Release Log4j 2.12.0-rc2

) Our development set up is definitively pushing the boundaries... Pondering some more... Gary > > Ralph > > > On Jun 27, 2019, at 11:08 AM, Gary Gregory > wrote: > > > > On Thu, Jun 27, 2019 at 2:06 PM Ralph Goers > > wrote: > > > >> What was

Re: [Discuss] Release Log4j 2.12.0-rc2

On Thu, Jun 27, 2019 at 2:06 PM Ralph Goers wrote: > What was the last release where you could build and test with Java 11? > AFAIK this problem is not new to this release. > No idea, sorry. Gary > > Ralph > > > On Jun 27, 2019, at 10:54 AM, Gary Gregory > wrote

Re: [Discuss] Release Log4j 2.12.0-rc2

On Thu, Jun 27, 2019 at 1:54 PM Gary Gregory wrote: > Running the build on Java 8 was fine for me. I am concerned that it is not > testable on Java 11 in the usual Maven way. I cannot find a way to run the > tests without Maven deciding it needs to recompile everything. > I tried

Re: [Discuss] Release Log4j 2.12.0-rc2

Running the build on Java 8 was fine for me. I am concerned that it is not testable on Java 11 in the usual Maven way. I cannot find a way to run the tests without Maven deciding it needs to recompile everything. Gary On Thu, Jun 27, 2019 at 1:18 PM Ralph Goers wrote: > The vote is a little ove

Re: [VOTE] Release Log4j 2.12.0-rc2

eate a separate module for the unit tests. > But why does Maven recompile when nothing has changed? That's the real problem, I ran a first build on Java 8, then all I want to do is run the tests on Java 11. Gary > > Ralph > > > On Jun 26, 2019, at 9:00 AM, Gary Gregory &g

Re: [VOTE] Release Log4j 2.12.0-rc2

ts pass on Java 11?" I am OK for this release with not being able to _build_ on Java 11 but I certainly should be able to run all tests with a plain old 'mvn test'. FWIW, at work, our platform requirements are Java 8 and 11. Gary > Ralph > > > On Jun 26, 2019, at 7:32

Re: [VOTE] Release Log4j 2.12.0-rc2

Driving me nuts: I can do the following OK on Java 8: " mvn -P rat -DskipTests clean install". But then I switch to Java 11 and run "mvn test" and Maven wants to recompile everything and fails as noted below. How do you test on Java 11? Gary On Wed, Jun 26, 2019 at 10:24 AM

Re: [VOTE] Release Log4j 2.12.0-rc2

time when size based triggering policy > is used without a time-based triggering policy. > • LOG4J2-2597: Throw better exception message when both > log4j-slf4j-impl and log4j-to-slf4j are present. > • LOG4J2-2559: NullPointerException in > JdbcAppender.crea

Re: [VOTE] Release Log4j 2.12.0-rc2

pache-rat:check' in that command fails. Weird. I will keep on testing. Gary > > Ralph > > > On Jun 26, 2019, at 5:58 AM, Gary Gregory > wrote: > > > > On Wed, Jun 26, 2019 at 8:40 AM Gary Gregory > wrote: > > > >> FYI, running 'mvn apach

Re: [VOTE] Release Log4j 2.12.0-rc2

y On Wed, Jun 26, 2019 at 8:58 AM Gary Gregory wrote: > On Wed, Jun 26, 2019 at 8:40 AM Gary Gregory > wrote: > >> FYI, running 'mvn apache-rat:check' fails on log4j-cassandra/.toDelete >> > > Ah, I can see that we have .gitignore set up to ignore this file

Re: [VOTE] Release Log4j 2.12.0-rc2

On Wed, Jun 26, 2019 at 8:40 AM Gary Gregory wrote: > FYI, running 'mvn apache-rat:check' fails on log4j-cassandra/.toDelete > Ah, I can see that we have .gitignore set up to ignore this file so I deleted it and ran 'mvn apache-rat:check&#

Re: [VOTE] Release Log4j 2.12.0-rc2

iloverAppender was failing with ERROR appender > Failover has no parameter that matches element Failovers. Thanks to Seán > Dunne. > • LOG4J2-2602: Update file time when size based triggering policy > is used without a time-based triggering policy. > • LOG4J2-2597: T

Re: [VOTE] Release Log4j 2.12.0-rc1

I will test when it becomes available... :-) Gary On Tue, Jun 25, 2019 at 9:34 PM Ralph Goers wrote: > I will see if I can get a new rc out tonight, but it might not make it. > > Ralph > > > On Jun 25, 2019, at 6:26 PM, Gary Gregory > wrote: > > > > On Tue, Ju

Re: [VOTE] Release Log4j 2.12.0-rc1

;, version: "10.0", arch: "amd64", family: "windows" > >> > >> I will set JAVA_HOME to Java 7 and try again later. > >> > >> > >> On Wed, Jun 26, 2019 at 3:55 AM Ralph Goers > > >> wrote: > >

Re: [VOTE] Release Log4j 2.12.0-rc1

please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException using: mvn test -Dtest=ResolverUtilTest -pl log4j-core -e -V Gary On Tue, Jun 25, 2019 at 11:48 AM Gary Gregory wrote: > I will retest and report back today... > >

Re: [VOTE] Release Log4j 2.12.0-rc1

I will retest and report back today... Gary On Tue, Jun 25, 2019, 10:51 Ralph Goers wrote: > Can you run just that test to see if you get stack traces? > > Ralph > > > On Jun 25, 2019, at 6:59 AM, Gary Gregory > wrote: > > > > Oops, hit send

Re: [VOTE] Release Log4j 2.12.0-rc1

Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Gary On Tue, Jun 25, 2019 at 9:58 AM Gary Gregory wrote: > I get the following test failures: > > > On Sun, Jun 23, 2019 at

Re: [VOTE] Release Log4j 2.12.0-rc1

ailover has no parameter that matches element Failovers. Thanks to Seán > Dunne. > • LOG4J2-2602: Update file time when size based triggering policy > is used without a time-based triggering policy. > • LOG4J2-2597: Throw better exception message when

Re: PR for LOG4J2-2639

I would drop prefixes like "at" and "with". In you example, if debug logging is disabled, are the follow up calls noops? Gary (AFK) On Sat, Jun 22, 2019, 11:58 Ralph Goers wrote: > Please review the PR for LOG4J2-2639 at > https://github.com/apache/logging-log4j2/pull/284 < > https://github.co

Re: 2.12.0 Release

Great news! Gary On Thu, Jun 20, 2019, 11: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: MongoDB in Log4j 2 3.0

n released and is unlikely to be released for several more months I see > no reason to keep providing compatibility with the MongoDB 2.x when that is > released. > These all sound like good reasons to get rid of it. Gary > > Ralph > > > On Jun 3, 2019, at 7:09 AM, Ga

Re: MongoDB in Log4j 2 3.0

download for it on their > web site. Why should Log4j 2 3.0 support that? > It's not so much an issue of supporting which server but which client. Gary > > Ralph > > > On Jun 3, 2019, at 4:03 AM, Gary Gregory wrote: > > > > Indeed. I use Log4j with MongoDB at

Re: changes.xml in 3.0

Are you sure? The reason I did it like this is to track changes from when the branches diverged. Gary On Sun, Jun 2, 2019 at 5:45 PM Ralph Goers wrote: > Gary, > > In looking at the changes.xml in 3.0 it looks like you are adding > notations to both the 2.x and 3.x releases. That doesn’t make a

Re: MongoDB in Log4j 2 3.0

Indeed. I use Log4j with MongoDB at work. My goal in supporting MongoDB 2 and 3 drivers was to allow to match our customer's MongoDB environment, which we are not able to control in all cases. Note that there is no Mongo 4 driver to match the server so I can only assume that the version 3 driver wo

[log4j] release plans for 2.12.0?

Hi All: I'm seeing https://issues.apache.org/jira/browse/LOG4J2-2612 in our builds randomly but not that often. Does anyone plan on doing a release for 2.12.0 anytime soon-ish? Thank you, Gary

Re: NullPointerException in DefaultMergeStrategy

Ralph, why not add null-checks in the loops of the merge methods? Gary On Mon, May 27, 2019 at 4:28 AM Gaurav wrote: > > > On 2019/05/24 19:16:33, Ralph Goers wrote: > > Composite configuration implies that you are merging multiple > configuration files. Yes, it would appear that the configura

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

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 after tracking down the issue in prod. It's > frightening because the result was instability across entir

Re: [Log4j] Groovy Configuration DSL

I am all for making configurations easier to author. Your examples are less verbose than XML which is nice. I wonder if the same config would also look nice in JSON. Gary (on my phone ATM) On Fri, May 3, 2019, 13:08 Matt Sicker wrote: > I believe Ralph has brought up a feature request in the pa

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

t 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 09:24, Gary Gregory wrote: > >>> Have you guys seen this one and is there a w

Re: Asciidoc for site documents

On Mon, Apr 29, 2019 at 2:53 PM Ralph Goers wrote: > The proposal wasn’t to go back to xdoc but to switch everything to > Markdown. To be honest I’m still not sure why asciidoc is better than > Markdown. What syntactical features? > I won't oppose any shuffling around but I think it would be nic

Re: Asciidoc for site documents

Based on the reply to my comment I just saw on the github page for the issue, it seems like the developer is willing to help, we just need to provide PRs or a description of what we'd like to change... Gary On Mon, Apr 29, 2019 at 12:48 PM Ralph Goers wrote: > The issue isn’t marked as fixed.

Re: JDK version for building

I need Java 8 and Java 9 in our Maven toolchain to build Log4j 2. You could use later versions, maybe, I've not tried it. Gary On Thu, Apr 18, 2019 at 5:51 PM German Gonzalez-Morris < german.gonza...@gmail.com> wrote: > Hello, > > As we all know, JDK9 is deprecated, which version of JDK are you

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

Have you guys seen this one and is there a way we can guard against it. java.lang.StackOverflowError at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194) at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121) at org.apache.logging.slf4j.L

<    3   4   5   6   7   8   9   10   11   12   >