Why can't you use the default, ExclusiveLock? log4net automatically manages
writing messages from different threads in the same process. InterProcessLock
is for a specific use case where more than one process is trying to write to
the same file. In that case writing to multiple files and combin
Yes, this is the intent of LOG4J2-2986:
"stackTrace": {
"stringified": true, "truncatedStringSuffix": ">",
"truncationPointStrings": ["at javax.servlet.http.HttpServlet.service"]}
That snippet from the PR doesn't seem to match your documentation grammar
"truncationPointStrings" vs "truncatio
Follow-up to "Formatting the date is expensive. The process of actually
formatting a value is reasonable". Is this still an issue from LOG4J2-930:
%m %ex%n: 1,755,573 msg/sec%d %m %ex%n: 1,194,184 msg/sec
If so, isn't date rendering essentially a sequence we can generate ahead of
time similar to
Any thoughts if the concept of a message template would add value to JSON
Template Layout? Heavily inspired by Serilog:
https://ikeptwalking.com/structured-logging-using-serilog/https://blog.rsuter.com/logging-with-ilogger-recommendations-and-best-practices/https://benfoster.io/blog/serilog-best-p
Ughh, second badly formatting email. Need to research that some more
On Monday, September 20, 2021, 09:24:45 PM EDT, Ron Grabowski
wrote:
Any thoughts if the concept of a message template would add value to JSON
Template Layout? Heavily inspired by Serilog:
https://ikeptwalking.com
t constructing a `MapMessage` and passing it to
`Logger#log()` is not very convenient. That I agree with. But then let's
improve the `Logger` API instead.
On Tue, Sep 21, 2021 at 3:24 AM Ron Grabowski
wrote:
> Any thoughts if the concept of a message template would add value to JSON
>
I built with Java 8 because that's the default JDK on this Windows 10 box.
Based on https://logging.apache.org/log4j/2.x/build.html I understand why Java
9 is needed. Why are Java 7 and Java 11 JDKs required to build? It took a few
minutes to find a JDK 7 installer. I had to add a new toolchai
Same results for rc2 vs rc1: Cassandra test not deleting a .toDelete file.
Everything else was fine:
+1
Building
- mvn clean install
- mvn apache-rat:check
- mvn revapi:check -pl log4j-api
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)Maven home:
C:\projects\apache-maven-3.8.4Jav
+1
mvn clean install -t toolchains-sample-win.xml
mvn apache-rat:checkmvn revapi:check -pl log4j-api
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)Maven home:
C:\projects\apache-maven-3.8.4Java version: 1.8.0_181, vendor: Oracle
Corporation, runtime: C:\Program Files\Java\jdk1.8.
+1 for Log4j 2.15.1-rc1, I accidently replied to the wrong thread earlier.
mvn clean install -t toolchains-sample-win.xmlmvn apache-rat:checkmvn
revapi:check -pl log4j-api
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)Maven home:
C:\projects\apache-maven-3.8.4Java version: 1.8.0_1
I saw the vote has already been closed on log4j-2.16.0-rc1, +1 from me
for completeness. No cassandra errors with rat:check this time:
mvn clean install -t toolchains-sample-win.xml
mvn revapi:check -pl log4j-api
mvn apache-rat:check
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Severity: moderate (CVSS: 3.7 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
Description:
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was
incomplete in certain non-default configurations. This could allows attackers
with control over Thread Context Map (MDC) input data when
+1
mvn clean install
mvn apache-rat:check
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: C:\projects\apache-maven-3.8.4
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_181\jre
Default locale: en_US, platform encoding: Cp125
Vladimir, wouldn't a more efficient approach be to offer support to
Logging Services then have them make a release to address the recent CVE
while still maintaining 1.2.17 compatibility? I don't get the sense
folks are against fixing things. Re-starting the entire EOL'ed Log4j1
engine with a ne
+1
I wrote a simple HelloWorld app with 2.3.1 running on jdk1.6.0_45 to
further verfiy LOG4J2-3198. These commands ran successfully too:
mvn clean install
mvn site -DskipTests
mvn apache-rat:check -DskipTests
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: C:\project
+1
On Thursday, December 23, 2021, 04:45:14 PM EST, Matt Sicker
wrote:
+1
--
Matt Sicker
> On Dec 23, 2021, at 15:41, Dominik Psenner wrote:
>
> +1
>
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Thu, Dec 23, 2021, 22:38 Ralph Goers
I interpreted your comment as the branch name on the 2.17.0 site says
'log4j-2.17.0' which doesn't exist, it should be 'rel/2.17.0'. I updated
pom.xml in release-2.x to use the rel/x.y.z pattern in future deploys. When the
2.17.0 site is redeployed source-repository.html will be updated with th
+1 for passing tests and website. RAT failed on these two files: !?
docs/2.17.0-interpolation.md !? docs/cve-map.md
On Monday, December 27, 2021, 07:31:20 PM EST, Matt Sicker
wrote:
This is a vote to release Log4j 2.17.1, the next version of the Log4j 2
project.
Please downlo
+1
"mvn clean install -pl '!log4j-cassandra'" ran correctly. Verified
hashes and asc files. RAT passed too.
On 12/28/2021 7:46 PM, Gary Gregory wrote:
+1
SHA512 OK
ASC OK
RAT check OK
mvn clean install -pl '!log4j-cassandra' OK
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build
+0 no concerns, I'm just not at a machine where I can verify
On Wednesday, December 29, 2021, 01:40:50 PM EST, Matt Sicker
wrote:
I’m waiting to see if Ron or any other PMC members wanted to review this
before I close the vote and continue with the release.
--
Matt Sicker
> On Dec 29,
+1 for Option 1
On 12/29/2021 2:33 PM, Christian Grobmeier wrote:
Hello,
as discussed in another thread, this is a vote about the future of log4j 1.
This vote stays open for the usual 72h.
Options are explained below.
You can vote for:
[ ] +1, Option 1
[ ] +1, Option 2
[ ] +/- 0, absta
Dear Log4j community,
While working on the December 2021 Apache Log4j 2 releases the Apache
Logging Services PMC received requests to reevaluate the 2015
End-of-Life (EOL) decision for Apache Log4j 1, which has seen its
latest release in 2012.
We have considered these requests and discussed vario
I saw the same errors with JDK8 on Windows:
openjdk version "1.8.0_342"
OpenJDK Runtime Environment Corretto-8.342.07.3 (build 1.8.0_342-b07)
OpenJDK 64-Bit Server VM Corretto-8.342.07.3 (build 25.342-b07, mixed mode)
[ERROR] Errors:
[ERROR]
GelfLayoutTest.testLayoutNewLineDelimiter:286->testC
23 matches
Mail list logo