Re: log4net interprocesslock crashing the app

2020-01-21 Thread Ron Grabowski 
 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 combining then in a 
log aggregator seems like a better idea.
On Tuesday, January 21, 2020, 06:40:03 AM EST, Denis Levushkin 
 wrote:  
 
   Hi,
I have discovered a problem with "interprocesslock" locking model used in our 
project for File appender. I will appreciate if you could investigate the issue 
and let me  know what is wrong. Maybe it is a bug within log4net dll.

ISSUE:If file appender is configured with
""
and 
""
Then splitting file for each new day works fine while splitting file during a 
day on limit "5MB" reached crashes the whole application. If I set  
maximumFileSize value to another value, let us say, to "50KB"  then the app 
crashes when log file reaches these 50KB. Previous file gets footer at the end, 
new file is creating and even first attempt to write to new file is always ok. 
However, any next attempt to write into new log file by log4net dll fails.
The issue fixes only by changing locking model from "InterProcessLock"  to 
"MinimalLock". However, we would like to use "InterProcessLock" because it 
works faster and we do logging only from one single process.  It is a windows 
service written in C# .net with multi-threading approach used. Therefore, one 
process with a lot of separate threads starting and stopping inside. And 
logging works fine every day until log file reaches the limit by value. As I 
said, splitting of log file on each new day does not produce any issues.
I turned on diagnostic and debug mode for log4net library. All files are 
attached. Configuration file is also attached.
The code line that fails:
if (Log.IsInfoEnabled) Log.Info("New schedule configuration is saved 
successfully on server.");

if I have two such lines of code written within the same function and after the 
first one file reaches the limit then call of the second will crash the app.

Best regards 







| Denis LevushkinSoftware Architect - H&L LønnMobile +47 45 83 80 69 | 
Switchboard +47 46 40 40 00 Visma Software ASKarenslyst Allé 56, 0277 Oslo | 
http://www.visma.no |

 
|  | Stay ahead with leading cloud software |

This communication is intended for the person(s) named above only. It contains 
information that is confidential and legally privileged. If received in error, 
please delete this e-mail and notify the sender.

Re: LOG4J2-2993 Support stack trace truncation in JsonTemplateLayout

2021-01-17 Thread Ron Grabowski 
 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 "truncationPointMatcherStrings":
stringified                   = "stringified" -> booleantruncatedStringSuffix   
      = "truncatedStringSuffix" -> stringtruncationPointMatcherStrings = 
"truncationPointMatcherStrings" -> string[]truncationPointMatcherRegexes = 
"truncationPointMatcherRegexes" -> string[]
I just finished up with a PR on my ticket too. Since I'm dealing with frames I 
decided to build on the existing "filters" name for packages and name it 
"filters.startFrames":

filters.startFrames(javax.servlet.http.HttpServlet.service)
I don't support regexes (yet?)
Do you think the name/syntax should match across features or is the Json layout 
unique enough that having two names (truncationPoint*, startFrames) for the 
same concept is ok?
On Friday, January 15, 2021, 10:59:26 AM EST, Volkan Yazıcı 
 wrote:  
 
 Hello,
I have cloned Ron's LOG4J2-2986 (truncation of stack traces after a matching 
point) for JSON template layout in LOG4J2-2993 and created a PR. I would 
appreciate it if somebody can review the changes, in particular, how matching 
against the provided regexes are performed via grouping.
@Ron, I will appreciate it if you can confirm that the implemented feature set 
is indeed what you were asking for.
Kind regards.
P.S. @Remko Popma, I still cannot add you as a reviewer to GitHub PRs.

Re: Cek's new log4j vs logback benchmark

2021-08-27 Thread Ron Grabowski 
 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 how a local ID generator asks for an allocation of keys then 
uses that to quickly assign IDs to new objects? When its time to render %d we 
can just grab it via an index:

1)At startup calculate the next 32k formatted dates. If 
Clock.currentTimeMillis() were configured down to the second, 32000 seconds 
would pre-allocate %d for the next 8 hours.
2)Apply math to Clock.currentTimeMillis() to get an index into the buffer. 
Seconds precision:
[10] = "2021-08-28 09:44:31,000"
[11] = "2021-08-28 09:44:32,000"[12] = "2021-08-28 09:44:33,000"[13] = 
"2021-08-28 09:44:34,000"[14] = "2021-08-28 09:44:35,000"[15] = "2021-08-28 
09:44:36,000"...[31999] = "..."
50ms precision:
[10] = "2021-08-28 09:44:31,050"[11] = "2021-08-28 09:44:31,075"[12] = 
"2021-08-28 09:44:31,100"[13] = "2021-08-28 09:44:31,150"[14] = "2021-08-28 
09:44:31,175"[15] = "2021-08-28 09:44:31,200"...[31999] = "..."

3)Rendering %d{SEQ(DEFAULT,32000)} is just a index lookup into the sequence of 
32000 pre-calculated %d{DEFAULT} values without the cost of formatting. I made 
up the "SEQ" notation, there's likely a better way to express the feature. 
Everything can read from the buffer without locking.
4)Have a background thread casually keep the sequence filled in a ring so dates 
in the past are replaced with future dates so the structure consumes a 
consistent amount of memory.
On Friday, August 27, 2021, 10:07:59 PM EDT, Carter Kozak 
 wrote:  
 
 Thanks, Remko. The default '%d' uses FixedDateFormat with FixedFormat.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.

On Fri, Aug 27, 2021, at 16:10, Remko Popma wrote:
> 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 agrees with my observations as well.
> > 
> > Ralph
> > 
> >> On Aug 27, 2021, at 12:23 PM, Carter Kozak  wrote:
> >> 
> >> I've identified a few things that seem impactful, but bear in mind that I 
> >> haven't begun to drill down into them yet. I plan to file individual 
> >> tickets and investigate in greater depth later on:
> >> 
> >> 1. Formatting the date is expensive. The process of actually formatting a 
> >> value is reasonable, however using a precise clock appears to cause cache 
> >> misses even when the pattern results in the same value 
> >> (microseconds/nanoseconds aren't included in the result). Using the 
> >> SystemMillisClock improves our throughput. I imagine some part of that 
> >> improvement is the result of currentTimeMillis(): long rather than 
> >> Clock.instant().
> >> 
> >> 2. Setting 'log4j2.enable.direct.encoders' to false improves performance, 
> >> otherwise we see a lot of time spent in the StringBuilderEncoder, but I 
> >> haven't had time to investigate that yet. Without direct encoders, we are 
> >> allocating a great deal more byte arrays, but they're used across a small 
> >> space that C2 may be able to inline out.
> >> 
> >> 3. Setting log4j2.formatMsgNoLookups=true (or using message pattern 
> >> '%m{nolookup}' saves us some time scanning through produced messages -- 
> >> I've had this disabled at work for a while.
> >> 
> >> 4. [in progress] If I implement the full layout directly in java (write 
> >> directly to a stringbuilder based on the event in a custom Layout instead 
> >> of using PatternLayout) combined with [1] and [2] above, performance is 
> >> much better than logback, however using PatternLayout with the steps above 
> >> we fall just a bit short. I still need to read through the patternlayout 
> >> and individual pattern converters to understand why, but there's 
> >> definitely some headroom we'll be able to reclaim hiding somewhere.
> >> 
> >> -ck
> >> 
> >>> On Fri, Aug 27, 2021, at 11:23, Carter Kozak wrote:
> >>> My pleasure, I enjoy digging into this sort of performance comparison, the
> >>> toughest piece right now is balancing investigation with active projects 
> >>> at
> >>> work. I completely agree about the importance of getting this resolved
> >>> quickly and I intend to continue investigating.
> >>> 
> >>> Re loom:
> >>> Currently we have a few places which reuse shared objects, potentially 
> >>> large
> >>> ones (thinking StringBuilder instances on 
> >>> ReusableLogEvent/StringLayout/etc)
> >>> which are currently boun

Event (Message) Template idea for JSON Template Layout

2021-09-20 Thread Ron Grabowski 
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-practices/
Two examples playing around with syntax:
"message" : "Engine Started at 09/28/2016 23:28:51, restart scheduled for 
09/29/2016 23:28:51","message_template" : "Engine started at {TimeOfStart}, 
restart scheduled for {TimeOfRestart}","message_template_hash" : 
"152d8ea","message_fields" : {  "TimeOfStart" : 
"2016-09-28T23:28:51.224+10:00",  "TimeOfStart" : 
"2016-09-29T23:28:51.224+10:00"}
"message.template" : "Engine started at {}, restart scheduled for 
{}","message.template.hash" : "152d8ea","message.args" : [  
"2016-09-28T23:28:51.2247447+10:00",  "2016-09-29T23:28:51.2247447+10:00"]
In the second example message is omitted on purpose because we want the 
structured version. When looking for occurrences of the same event you could 
search for a short value without having to use wildcards or regex. Hash seems 
complex, it could be replaced by a marker at the call site.

Re: Event (Message) Template idea for JSON Template Layout

2021-09-20 Thread Ron Grabowski 
 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/structured-logging-using-serilog/https://blog.rsuter.com/logging-with-ilogger-recommendations-and-best-practices/https://benfoster.io/blog/serilog-best-practices/
Two examples playing around with syntax:
"message" : "Engine Started at 09/28/2016 23:28:51, restart scheduled for 
09/29/2016 23:28:51","message_template" : "Engine started at {TimeOfStart}, 
restart scheduled for {TimeOfRestart}","message_template_hash" : 
"152d8ea","message_fields" : {  "TimeOfStart" : 
"2016-09-28T23:28:51.224+10:00",  "TimeOfStart" : 
"2016-09-29T23:28:51.224+10:00"}
"message.template" : "Engine started at {}, restart scheduled for 
{}","message.template.hash" : "152d8ea","message.args" : [  
"2016-09-28T23:28:51.2247447+10:00",  "2016-09-29T23:28:51.2247447+10:00"]
In the second example message is omitted on purpose because we want the 
structured version. When looking for occurrences of the same event you could 
search for a short value without having to use wildcards or regex. Hash seems 
complex, it could be replaced by a marker at the call site.

Re: Event (Message) Template idea for JSON Template Layout

2021-09-21 Thread Ron Grabowski 
 StringMapMessage offers similar functionality. That's the concept I was 
looking for, thanks

On Tuesday, September 21, 2021, 03:12:16 AM EDT, Volkan Yazıcı 
 wrote:  
 
 What advantage(s) does it provide compared to simply logging a
`MapMessage`? Consider the following:

StringMapMessage message = new StringMapMessage();
message.put("Kind", "engine start");
message.put("Instant", "2016-09-28T23:28:51.224Z");
message.put("NextScheduledInstant", "2016-09-29T23:28:51.224Z");
logger.atWarn().log(message);

You might argue that 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
> 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-practices/
> Two examples playing around with syntax:
> "message" : "Engine Started at 09/28/2016 23:28:51, restart scheduled for
> 09/29/2016 23:28:51","message_template" : "Engine started at {TimeOfStart},
> restart scheduled for {TimeOfRestart}","message_template_hash" :
> "152d8ea","message_fields" : {  "TimeOfStart" :
> "2016-09-28T23:28:51.224+10:00",  "TimeOfStart" :
> "2016-09-29T23:28:51.224+10:00"}
> "message.template" : "Engine started at {}, restart scheduled for
> {}","message.template.hash" : "152d8ea","message.args" : [
> "2016-09-28T23:28:51.2247447+10:00",  "2016-09-29T23:28:51.2247447+10:00"]
> In the second example message is omitted on purpose because we want the
> structured version. When looking for occurrences of the same event you
> could search for a short value without having to use wildcards or regex.
> Hash seems complex, it could be replaced by a marker at the call site.
>
>

Re: [VOTE] Release Log4j 2.15.0-rc1

2021-12-07 Thread Ron Grabowski 
  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 toolchain entry to the 
local toolchains-sample-win.xml for JDK 11.  
https://logging.apache.org/log4j/2.x/build.html references 
https://cwiki.apache.org/confluence/display/logging/Log4j2ReleaseGuide which 
doesn't exist.
This warning caused apache-rat:check to fail so I deleted the file (.toDelete). 
It is not in the repo so it may be a left over from a test that didn't run 
correctly on Windows?
"Files with unapproved licenses:
  C:/projects/log4j-2.15.0-rc1/log4j-cassandra/.toDelete"
Once I fixed those couple things everything 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.4Java version: 1.8.0_181, vendor: Oracle 
Corporation, runtime: C:\Program Files\Java\jdk1.8.0_181\jreDefault locale: 
en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows"
On Tuesday, December 7, 2021, 03:36:47 PM EST, Gary Gregory 
 wrote:  
 
 +1

Building
- mvn clean install
- mvn apache-rat:check
- mvn revapi:check -pl log4j-api

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

On

Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

Gary


On Mon, Dec 6, 2021 at 11:13 PM Ralph Goers 
wrote:

> This is a vote to release Log4j 2.15.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 vote will remain open for 72 hours (or more if required). All votes
> are welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
>
> Changes in this release include:
>
> New Features
>
>        • LOG4J2-3198: Pattern layout no longer enables lookups within
> message text by default for cleaner API boundaries and reduced formatting
> overhead. The old 'log4j2.formatMsgNoLookups' which enabled this behavior
> has been removed as well as the 'nolookups' message pattern converter
> option. The old behavior can be enabled on a per-pattern basis using
> '%m{lookups}'.
>        • LOG4J2-3194: Allow fractional attributes for size attribute of
> SizeBsaedTriggeringPolicy. Thanks to markuss.
>        • LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty 11)
> Thanks to Michael Seele.
>        • LOG4J2-3189: Improve NameAbbreviator worst-case performance.
>        • LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case
> time, rather than O(n^2). Thanks to Gareth Smith.
>        • LOG4J2-3133: Add missing slf4j-api singleton accessors to
> log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This doesn't
> impact behavior or correctness, but avoids throwing and catching
> NoSuchMethodErrors when slf4j is initialized and avoids linkage linting
> warnings.
>        • LOG4J2-2885: Add support for US-style date patterns and
> micro/nano seconds to FixedDateTime. Thanks to Markus Spann.
>        • LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform
> structured logging layout.
>        • LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
>        • LOG4J2-3074: Add replacement parameter to
> ReadOnlyStringMapResolver.
>        • LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
>        • LOG4J2-3064: Add Arbiters and SpringProfile plugin.
>        • LOG4J2-3056: Refactor MD5 usage for sharing sensitive
> information. Thanks to Marcono1234.
>        • LOG4J2-3004: Add plugin support to JsonTemplateLayout.
>        • LOG4J2-3050: Allow AdditionalFields to be ignored if their value
> is null or a zero-length String.
>        • LOG4J2-3049: Allow MapMessage and ThreadContext attributes to be
> prefixed.
>        • LOG4J2=3048: Add improved MapMessge support to GelfLayout.
>        • LOG4J2-3044: Add RepeatPatternConverter.
>        • LOG4J2-2940: Context selectors are aware of their dependence
> upon the callers ClassLoader, allowing basic context selectors to avoid the
> unnecessary overhead of walking the stack to determine the caller's
> ClassLoader.
>        • LOG4J2-2940: Add BasicAsyncLoggerContextSelector equivalent to
> AsyncLoggerContextSelector for applications with a

Re: [VOTE] Release Log4j 2.15.0-rc2

2021-12-09 Thread Ron Grabowski 
 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.4Java version: 1.8.0_181, vendor: Oracle 
Corporation, runtime: C:\Program Files\Java\jdk1.8.0_181\jreDefault locale: 
en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows"
On Thursday, December 9, 2021, 03:32:36 PM EST, Matt Sicker 
 wrote: 
 +1

Build good, sigs good, etc. Still has an issue running the Cassandra 
integration test on my machine, but not a blocker.

Environment info:

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.0.1", arch: "aarch64", family: “mac"

Java version: 11.0.12, vendor: Homebrew, runtime: 
/opt/homebrew/Cellar/openjdk@11/11.0.12/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.0.1", arch: "aarch64", family: “mac"

> On Dec 9, 2021, at 12:43, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.15.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 vote will remain open for 72 hours (or more if required). All votes are 
> welcome and we encourage everyone to test the release, but only Logging PMC 
> votes are “officially” counted. As always, at least 3 +1 votes and more 
> positive than negative votes are required.
> 
> Changes in this release include:
> 
> New Features
> 
>     • LOG4J2-3198: Pattern layout no longer enables lookups within message 
> text by default for cleaner API boundaries and reduced formatting overhead. 
> The old 'log4j2.formatMsgNoLookups' which enabled this behavior has been 
> removed as well as the 'nolookups' message pattern converter option. The old 
> behavior can be enabled on a per-pattern basis using '%m{lookups}'.
>     • LOG4J2-3194: Allow fractional attributes for size attribute of 
> SizeBsaedTriggeringPolicy. Thanks to markuss.
>     • LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty 11) Thanks 
> to Michael Seele.
>     • LOG4J2-3189: Improve NameAbbreviator worst-case performance.
>     • LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case time, 
> rather than O(n^2). Thanks to Gareth Smith.
>     • LOG4J2-3133: Add missing slf4j-api singleton accessors to 
> log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This doesn't 
> impact behavior or correctness, but avoids throwing and catching 
> NoSuchMethodErrors when slf4j is initialized and avoids linkage linting 
> warnings.
>     • LOG4J2-2885: Add support for US-style date patterns and micro/nano 
> seconds to FixedDateTime. Thanks to Markus Spann.
>     • LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform 
> structured logging layout.
>     • LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
>     • LOG4J2-3074: Add replacement parameter to ReadOnlyStringMapResolver.
>     • LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
>     • LOG4J2-3064: Add Arbiters and SpringProfile plugin.
>     • LOG4J2-3056: Refactor MD5 usage for sharing sensitive information. 
> Thanks to Marcono1234.
>     • LOG4J2-3004: Add plugin support to JsonTemplateLayout.
>     • LOG4J2-3050: Allow AdditionalFields to be ignored if their value is 
> null or a zero-length String.
>     • LOG4J2-3049: Allow MapMessage and ThreadContext attributes to be 
> prefixed.
>     • LOG4J2=3048: Add improved MapMessge support to GelfLayout.
>     • LOG4J2-3044: Add RepeatPatternConverter.
>     • LOG4J2-2940: Context selectors are aware of their dependence upon the 
> callers ClassLoader, allowing basic context selectors to avoid the 
> unnecessary overhead of walking the stack to determine the caller's 
> ClassLoader.
>     • LOG4J2-2940: Add BasicAsyncLoggerContextSelector equivalent to 
> AsyncLoggerContextSelector for applications with a single LoggerContext. This 
> selector avoids classloader lookup overhead incurred by the existing 
> AsyncLoggerContextSelector.
>     • LOG4J2-3041: Allow a PatternSelector to be specified on GelfLayout.
>     • LOG4J2-3141: Avoid ThreadLocal overhead in RandomAccessFileAppender, 
> RollingRandomAccessFileManager, and MemoryMappedFileManager due to the unused 
> setEndOfBatch and isEndOfBatch methods. The methods on LogEvent are preferred.
>     • LOG4J2-3144: Prefer string.getBytes(Charset) over 
> string.getBytes(String) based on performance improvements in modern Java 
> releases.
>     • LOG

Re: [VOTE] Release Log4j 2.15.0-rc2

2021-12-12 Thread Ron Grabowski 
 +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.0_181\jreDefault locale: 
en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows"
On Thursday, December 9, 2021, 06:01:28 PM EST, Remko Popma 
 wrote:  
 
   +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 locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Thank you Ralph!


On Fri, Dec 10, 2021 at 7:11 AM Gary Gregory  wrote:

> +1
>
> RAT check OK
> RevApi check OK on log4j-api but gives weird errors on log4j-1.2-api
>
> OK: mvn clean install
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>
> Gary
>
>
>
> On Thu, Dec 9, 2021 at 1:43 PM Ralph Goers 
> wrote:
>
> > This is a vote to release Log4j 2.15.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 vote will remain open for 72 hours (or more if required). All votes
> > are welcome and we encourage everyone to test the release, but only
> Logging
> > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> > positive than negative votes are required.
> >
> > Changes in this release include:
> >
> > New Features
> >
> >        • LOG4J2-3198: Pattern layout no longer enables lookups within
> > message text by default for cleaner API boundaries and reduced formatting
> > overhead. The old 'log4j2.formatMsgNoLookups' which enabled this behavior
> > has been removed as well as the 'nolookups' message pattern converter
> > option. The old behavior can be enabled on a per-pattern basis using
> > '%m{lookups}'.
> >        • LOG4J2-3194: Allow fractional attributes for size attribute of
> > SizeBsaedTriggeringPolicy. Thanks to markuss.
> >        • LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty
> 11)
> > Thanks to Michael Seele.
> >        • LOG4J2-3189: Improve NameAbbreviator worst-case performance.
> >        • LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case
> > time, rather than O(n^2). Thanks to Gareth Smith.
> >        • LOG4J2-3133: Add missing slf4j-api singleton accessors to
> > log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This
> doesn't
> > impact behavior or correctness, but avoids throwing and catching
> > NoSuchMethodErrors when slf4j is initialized and avoids linkage linting
> > warnings.
> >        • LOG4J2-2885: Add support for US-style date patterns and
> > micro/nano seconds to FixedDateTime. Thanks to Markus Spann.
> >        • LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform
> > structured logging layout.
> >        • LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
> >        • LOG4J2-3074: Add replacement parameter to
> > ReadOnlyStringMapResolver.
> >        • LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
> >        • LOG4J2-3064: Add Arbiters and SpringProfile plugin.
> >        • LOG4J2-3056: Refactor MD5 usage for sharing sensitive
> > information. Thanks to Marcono1234.
> >        • LOG4J2-3004: Add plugin support to JsonTemplateLayout.
> >        • LOG4J2-3050: Allow AdditionalFields to be ignored if their
> value
> > is null or a zero-length String.
> >        • LOG4J2-3049: Allow MapMessage and ThreadContext attributes to
> be
> > prefixed.
> >        • LOG4J2=3048: Add improved MapMessge support to GelfLayout.
> >        • LOG4J2-3044: Add RepeatPatternConverter.
> >        • LOG4J2-2940: Context selectors are aware of their dependence
> > upon the callers ClassLoader, allowing basic context selectors to avoid
> the
> > unnecessary overhead of walking the stack to determine the caller's
> > ClassLoader.
> >        • LOG4J2-2940: Add BasicAsyncLoggerContextSelector equivalent to
> > AsyncLoggerContextSelector for applications with a single LoggerContext.
> > This selector avoids classloader lookup overhead incurred by the existing
> > AsyncLoggerContextSelector.
> >        • LOG4J2-3041:

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Ron Grabowski 
 +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_181, vendor: Oracle 
Corporation, runtime: C:\Program Files\Java\jdk1.8.0_181\jreDefault locale: 
en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows"

On Sunday, December 12, 2021, 09:07:52 AM EST, Gary Gregory 
 wrote:  
 
 +1

*- I cannot get revapi:check to work on the log4j-api module due to some
weird maven dependency issue I cannot resolve, may someone confirm that
this check passes?*

- Apache RAT check OK
- mvn clean package

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

On Sat, Dec 11, 2021 at 10:48 PM Matt Sicker  wrote:

> This is a vote to release Log4j 2.15.1, 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 vote will remain open for 72 hours (or more if required). All votes
> are welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
>
> Changes in this release include:
>
> Fixed Bugs
>
> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> set to true to allow JNDI.
>
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>" and then "git checkout
> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>"
> b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.15.1-rc1”
>
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
> https://logging.staged.apache.org/log4j/2.x/index.html>.
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

Re: [VOTE] Release Log4j 2.16.0-rc1

2021-12-13 Thread Ron Grabowski 
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)
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: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On 12/13/2021 8:04 AM, Gary Gregory wrote:

+1

mvn clean package
mvn apache-rat:check

Is this command 'wrong'?
mvn revapi:check -pl log4j-api
I get errors.

My Maven toolchain file contains mappings for Java 8, 11, 17.

Same failure as before on Windows 10 and Java 8 in the restricted JNDI
test. Could be something odd with my set up I suppose.

Darwin gdg-mac-mini.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13
17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"

Gary


On Mon, Dec 13, 2021 at 6:22 AM Remko Popma  wrote:


+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 encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:


+1

`./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
setup:

$ java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
mixed mode)

$ java -version
openjdk version "17.0.1" 2021-10-19 LTS
OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed

mode,

sharing)

$ uname -a
Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Though I would appreciate some small fixes, which can be incorporated

later

on as well:

1. index.md.vm contains references to 2.15.1 and misses Remko's
improvements in LOG4J2-3214

2. security.md needs to be aligned with LOG4J2-3214
 too
3. appenders.xml contains references to 2.15.1
4. lookups.xml contains references to 2.15.1
5. I want a link to myself in support.md too!
6. I have encountered multiple occurrences of *"release contains one
change"* phrase, yet there are actually two changes. I would rather
rephrase this as *"release contains a limited set of changes focusing

on

security"*.
7. I have seen that CassandraAppenderIT is disabled due to aarch64
failures. I would appreciate a ticket for incorporating a
@DisabledOnArch
annotation.
8. In Interpolator.java, there are usages of
`JndiLookup.class.getName()` and
`"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on

one.

9. JNDI changes look good to me, great job Ralph!
10. I am baffled to see that SimplePerfTest.bubbleSort() was broken,

yet

tests were passing! (Thanks Matt!)

I can actually incorporate website fixes. What is the procedure for that?
Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag and
commit changes there?

On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers 
wrote:


+1

Verified the signature and the SHA512 hashes. Verified the build worked
for me. I did correct some mistakes in the staging site home page news
section as it still referenced 2.15.1.

Ralph



On Dec 12, 2021, at 11:18 PM, Matt Sicker  wrote:

This is a vote to release Log4j 2.16.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 vote will remain open for 72 hours (or more if required). All

votes

are welcome and we encourage everyone to test the release, but only

Logging

PMC votes are “officially” counted. As always, at least 3 +1 votes and

more

positive than negative votes are required.

Changes in this release include:

Fixed Bugs

* LOG4J2-3208: Disable JNDI by default.

CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack

2021-12-14 Thread Ron Grabowski 
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 the logging 
configuration uses a non-default Pattern Layout with either a Context Lookup 
(for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or 
%MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a 
denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to 
localhost by default. Note that previous mitigations involving configuration 
such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT 
mitigate this specific vulnerability.

Log4j 2.16.0 fixes this issue by removing support for message lookup patterns 
and disabling JNDI functionality by default.  

This issue can be mitigated in prior releases (<2.16.0) by removing the 
JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class).

References:

https://logging.apache.org/log4j/2.x/security.html
https://www.cve.org/CVERecord?id=CVE-2021-44228

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

2021-12-17 Thread Ron Grabowski 

+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: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On 12/17/2021 10:18 PM, Ralph Goers wrote:

This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 project.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for as short amount as time as required to vet the 
release. All votes are welcome and we encourage everyone to test the release, 
but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
votes and more positive than negative votes are required.

Note that a pre-release version of this was distributed to all reporters of the 
issue covered by CVE-2021-45105 and all who tested confirmed the issue was 
addressed.

Changes in this version include:

Fixed Bugs

• LOG4J2-3230: Fix string substitution recursion.
• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
'log4j2.enableJndiContextSelector'.
• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. The enablement property has been renamed to 
'log4j2.enableJndiJava'
• LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
dependencies as it causes problems with the Maven enforcer plugin.
• LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when 
parsing properties file filters.
• LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 
512 instead of 514.
• LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to 
TCP.

Tag:
a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git and then 
"git checkout tags/log4j-2.17.0-rc1”  or just "git clone -b log4j-2.17.0-rc1 
https://github.com/apache/logging-log4j2.git";
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.17.0-rc1”

Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachelogging-1071

Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/

Ralph

Re: Resurrecting log4j 1.x

2021-12-20 Thread Ron Grabowski 
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 new crew to fix one issue is confusing. To answer your 
question about sponsorship, I want to explore partnering with Logging 
Services before forming a new Log4j1 team.


On 12/20/2021 11:15 AM, Gary Gregory wrote:

I don't see the need for the incubator or a new PMC, this is a recipe for
confusion for users and contributors: Log4j 1 is a component of the Apache
Logging Services project and should remain for Apache to provide the best
and consistent *story* for Java logging, at Apache at least.

Things are bad enough when a product or projects offers pluggable logging
and I have have to explain facades like Log4j API, Jetty Logging, slf4j,
etc, and then implementations of APIs like Log4j Core, Logback, etc, and
then explain when and how to use bridges.

I wrote the above to make the point that reintroducing log4j 1 as a first
class citizen is going to make an even bigger and confusing mess.

The only work we should allow is a 1.2.x release that fixes CVEs.

We should continue to evangelize migration to 2.x.

Gary


On Mon, Dec 20, 2021, 09:36 Ralph Goers  wrote:


I am sure any number of PMC members would be happy to act as sponsors &
mentors. However, before
you even start you need to know if you have enough people who want to
participate tin the project. The
application form needs to include the list of names of people who will
become the initial members of the project.

The reason I brought this up is that it seems there are two groups here.
One that wants to get a release
out and then put Log4j 1 back in the coffin and another that wants to
resurrect it.

Ralph



On Dec 20, 2021, at 7:06 AM, Vladimir Sitnikov <

sitnikov.vladi...@gmail.com> wrote:

Ron,

There's a need to move log4j 1.x forward, and Ralph Goers suggested
that the way to go is to re-incubate it, see [1].

Could you sponsor the project or do you want Incubator to do that? (see

[2])

[1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
[2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m

Vladimir

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

2021-12-21 Thread Ron Grabowski 

+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:\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: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On 12/21/2021 12:18 AM, Ralph Goers wrote:

This is a vote to release Log4j 2.3.1, a security release for Java 6 users.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for as short amount as time as required to vet the 
release. All votes are welcome and we encourage everyone to test the release, 
but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
votes and more positive than negative votes are required.

Changes in this version include:


New features:
*  LOG4J2-3198:  Pattern layout no longer enables lookups within message text.

Fixed Bugs:
*  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. Rename JNDI enablement property from
 'log4j2.enableJndi' to 'log4j2.enableJndiLookup', 
'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
*  LOG4J2-3230:  Fix string substitution recursion.

Tag:
a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git"; and then 
"git checkout tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.1-rc1 
https://github.com/apache/logging-log4j2.git";
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.12.3-rc1”

Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachelogging-1076

Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
https://repository.apache.org/content/repositories/orgapachelogging-1076/org/apache/logging/log4j/.

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

2021-12-23 Thread Ron Grabowski 
 +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  wrote:
> 
>> +1
>> 
>> Ralph
>> 
>>> On Dec 23, 2021, at 2:35 PM, Ralph Goers 
>> wrote:
>>> 
>>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
>> has recommended that we can divorce
>>> the read-only SVN repo from https://github.com/apache/log4j. However,
>> it will not be able to keep the same
>>> name as all Git repos owned by the logging project must start with
>> “logging-“.
>>> 
>>> So this vote is to:
>>> 1. Delete the apache/logging-log4j1 repo I created last night.
>>> 2. Divorce the apache/log4j repo from SVN.
>>> 3. Rename apache/log4j to apache/logging-log4j1.
>>> 4. Create a branch named “main” from the v1_2_17 tag.
>>> 5. Make main the default branch in GitHub.
>>> 
>>> While all votes are welcome Infra needs consensus from the PMC on this
>> vote so the result will separate
>>> binding from non-binding votes.
>>> 
>>> Ralph
>>> 
>>> PS - I’ve separated this from the previous vote thread since it was
>> mostly discussion. If you want to discuss
>>> this please prefix the subject with [DISCUSS]
>> 
>>

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

2021-12-26 Thread Ron Grabowski 
 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 the 
rel/2.17.0 branch name.
On Sunday, December 26, 2021, 06:48:23 AM EST, Martin Schröder 
 wrote:  
 
 Am So., 26. Dez. 2021 um 12:16 Uhr schrieb Volkan Yazıcı :
> Many people get confused by the default branch of the repository on GitHub.
> I want to make it point to `release-2.x` rather than `master`. Objections?

While you're at that:
https://logging.apache.org/log4j/2.x/source-repository.html mentions
the missing 'log4j-2.17.0' branch.

Best
    Martin

Re: [VOTE] Release Apache Log4j 2.17.1-rc1

2021-12-27 Thread Ron Grabowski 
 +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 download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for as short amount as time as required to vet the 
release. All votes are welcome and we encourage everyone to test the release, 
but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
votes and more positive than negative votes are required.

Changes in this version include:


Fixed Bugs
                * 
[LOG4J2-3290](https://issues.apache.org/jira/browse/LOG4J2-3290):
    Remove unused method.
                * 
[LOG4J2-3292](https://issues.apache.org/jira/browse/LOG4J2-3292):
    ExtendedLoggerWrapper.logMessage no longer double-logs when location is 
requested.
                * 
[LOG4J2-3289](https://issues.apache.org/jira/browse/LOG4J2-3289):
    log4j-to-slf4j no longer re-interpolates formatted message contents.
                * 
[LOG4J2-3204](https://issues.apache.org/jira/browse/LOG4J2-3204):
    Correct SpringLookup package name in Interpolator. Thanks to Francis-FY.
                * 
[LOG4J2-3284](https://issues.apache.org/jira/browse/LOG4J2-3284):
    log4j-to-slf4j takes the provided MessageFactory into account Thanks to 
Michael Vorburger.
                * 
[LOG4J2-3264](https://issues.apache.org/jira/browse/LOG4J2-3264):
    Fix MapLookup to lookup MapMessage before DefaultMap Thanks to Yanming Zhou.
                * 
[LOG4J2-3274](https://issues.apache.org/jira/browse/LOG4J2-3274):
    Buffered I/O checked had inverted logic in RollingFileAppenderBuidler. 
Thanks to Faisal Khan Thayub Khan.
                * [](https://issues.apache.org/jira/browse/LOG4J2-3274):
    Fix NPE when input is null in StrSubstitutor.replace(String, Properties).
                * 
[LOG4J2-3270](https://issues.apache.org/jira/browse/LOG4J2-3270):
    Lookups with no prefix only read values from the configuration properties 
as expected.
                * 
[LOG4J2-3256](https://issues.apache.org/jira/browse/LOG4J2-3256):
    Reduce ignored package scope of KafkaAppender. Thanks to Lee Dongjin.

Tag: 
a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
 and then "git checkout 
tags/log4j-2.17.1-rc1”  or just "git clone -b log4j-2.17.1-rc1 
https://github.com/apache/logging-log4j2.git 
"
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.17.1-rc1”

Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html 
 

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachelogging-1078/

Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
 

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
https://repository.apache.org/content/repositories/orgapachelogging-1078/org/apache/logging/log4j/

--
Matt Sicker

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

2021-12-28 Thread Ron Grabowski 

+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 1.8.0_312-bre_2021_10_20_23_15-b00)
OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)

Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.1", arch: "x86_64", family: "mac"

Darwin *** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST
2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64

Gary


On Tue, Dec 28, 2021 at 6:03 PM Ralph Goers 
wrote:


This is a vote to release Log4j 2.12.4, a security release for Java 7
users.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because…

The vote will remain open for as short amount as time as required to vet
the release. All votes are welcome and we encourage everyone to test the
release, but only Logging PMC votes are “officially” counted. As always, at
least 3 +1 votes and more positive than negative votes are required.

Changes in this version include:

Fixed Bugs

 • LOG4J2-3293: JdbcAppender now uses JndiManager to access JNDI
resources. JNDI is only enabled when system property log4j2.enableJndiJdbc
is set to true.

Tag:
a)  for a new copy do "git clone
https://github.com/apache/logging-log4j2.git"; and then "git checkout
tags/log4j-2.12.4-rc1”  or just "git clone -b log4j-2.12.4-rc1
https://github.com/apache/logging-log4j2.git";
b) for an existing working copy to “git pull” and then “git checkout
tags/log4j-2.12.4-rc1”

Web Site:  https://logging.staged.apache.org/log4j/log4j-2.12.4/index.html

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachelogging-1080

Distribution archives:
https://dist.apache.org/repos/dist/dev/logging/log4j/

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
https://repository.apache.org/content/repositories/orgapachelogging-1080/org/apache/logging/log4j/
.

Ralph

Re: [VOTE] Release Log4j 2.3.2 for Java 6

2021-12-29 Thread Ron Grabowski 
 +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, 2021, at 11:42, Matt Sicker  wrote:
> 
> My +1
> --
> Matt Sicker
> 
>> On Dec 29, 2021, at 10:35, Carter Kozak > > wrote:
>> 
>> +1
>> 
>> $ mvn -version
>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>> Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
>> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
>> /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"
>> 
>> build/tests/rat look good
>> 
>> -ck
>> 
>> On Tue, Dec 28, 2021, at 20:59, Matt Sicker wrote:
>>> This is a vote to release Log4j 2.3.2, a security release for Java 6 users.
>>> 
>>> Please download, test, and cast your votes on the log4j developers list.
>>> [] +1, release the artifacts
>>> [] -1, don't release because…
>>> 
>>> The vote will remain open for as short amount as time as required to vet 
>>> the release. All votes are welcome and we encourage everyone to test the 
>>> release, but only Logging PMC votes are “officially” counted. As always, at 
>>> least 3 +1 votes and more positive than negative votes are required.
>>> 
>>> Changes in this version include:
>>> 
>>> Fixed Bugs
>>> 
>>> Fixed Bugs:
>>> o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access 
>>> should be limited.
>>>        Backport fix for CVE-2021-44832.
>>> o LOG4J2-2819:  Add support for specifying an SSL configuration for 
>>> SmtpAppender.
>>>        Backport fix for CVE-2020-9488 to allow SSL/TLS hostname 
>>>verification.
>>> 
>>> Tag: 
>>> a)  for a new copy do "git clone 
>>> https://github.com/apache/logging-log4j2.git 
>>>  
>>> >> >" and then "git checkout 
>>> tags/log4j-2.3.2-rc1”  or just "git clone -b log4j-2.3.2-rc1 
>>> https://github.com/apache/logging-log4j2.git 
>>>  
>>> >> >"
>>> b) for an existing working copy to “git pull” and then “git checkout 
>>> tags/log4j-2.3.2-rc1”
>>> 
>>> Web Site: [none published yet; need someone to stage a generated site]
>>> 
>>> Maven Artifacts: 
>>> https://repository.apache.org/content/repositories/orgapachelogging-1081/ 
>>> 
>>> 
>>> Distribution archives: 
>>> https://dist.apache.org/repos/dist/dev/logging/log4j/ 
>>>  
>>> >> > 
>>> 
>>> You may download all the Maven artifacts by executing:
>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
>>> https://repository.apache.org/content/repositories/orgapachelogging-1081/org/apache/logging/log4j/
>>>  
>>> 
>>> 
>>> --
>>> Matt Sicker
>

Re: [VOTE] Future of Log4j 1.x

2022-01-03 Thread Ron Grabowski 

+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, abstain
  [ ] -1 object against those options

Option 1: Create a README.md that publishes the projects EOL status and do 
nothing else.
Option 2: Create a README which says the project is EOL but allow the following 
work for 1.2.18 AND create a full release:
 a.  Make the build work with a modern version of Maven.
 b.  Fix the Java version bug.
 c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
 d.  Fix CVE-2019-17571

Regards,
Christian
--
The Apache Software Foundation
V.P., Data Privacy

[ANNOUNCE] Log4j 1 End-of-Life Statement

2022-01-05 Thread Ron Grabowski 
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 various options.
Ultimately we came to the unanimous decision that the only sustainable
approach is to continue to focus on Log4j 2. The PMC hereby reconfirms
the 2015 EOL announcement of Log4j 1, meaning no resources will be
invested into the Log4j 1 codebase. We encourage users to update to
recent versions of Log4j 2. We welcome every effort to contribute to
the Log4j community. Please use the developer mailing lists to get in
touch: https://logging.apache.org/log4j/2.x/mail-lists.html

The Log4j 1 source code will continue to be publicly available but
Pull Requests will be closed as "Won't Fix". The Apache License allows
for code forks that respect Apache Software Foundation Trademarks.

Here are some of the reasons we believe this is the right choice for
the Log4j project:

* Log4j 2 supports migration from Log4j 1

We've made improvements to
https://logging.apache.org/log4j/2.x/manual/migration.html to better
explain the process. Many users are not aware that Log4j 2 now
supports Log4j 1 configuration files, since this feature is relatively
new. We believe most applications using Log4j 1 can now simply replace
the Log4j 1.x jar with Log4j 2 jars and be able to run. Users are
encouraged to contact us through the project mailing lists
(https://logging.apache.org/log4j/2.x/mail-lists.html) if there are
additional areas for improvement.

* Log4j 1 deadlock and multithreading design limitations

The decision to relaunch the Log4j project as Log4j 2 meant we had an
opportunity to correct long standing design deficiencies. One of these
fundamental design deficiencies has to do with how to handle
multithreading within the library. The following mailing list question
is but one example of known multithreading issues with Log4j 1:
https://lists.apache.org/thread/7yqrmzqgzpxmbcc7skl0vr8z33fk4hd4

* High-complexity Log4j 1 bugs

In addition to the items listed, many other issues can be found in
Bugzilla: https://bz.apache.org/bugzilla

50213: Category callAppenders synchronization causes
java.lang.Thread.State: BLOCKED
46878: Deadlock in 1.2.15 caused by AsyncAppender and
ThrowableInformation classes
41214: Deadlock with RollingFileAppender
44700: Log4J locks rolled log files (files can’t be deleted)
49481: Log4j stops writing to file, and then causes server to lockup
50323: Vulnerability in NTEventLogAppender
50463: AsyncAppender causing deadlock when dispatcher thread dies
50858: Classloader leak when using Log4j in a webapp container such as
Tomcat, WebLogic
52141: [STUCK] ExecuteThread...Blocked trying to get lock:
org/apache/log4j/Logger@0xc501e0a8[fat lock]
54009: Thread is getting Blocked
54325: Concurrency issues in AppenderAttachableImpl

* Complexities with Log4j 1 build system that could impact binary compatibility

Apart from the issues listed above, Log4j 1 suffers from a challenging
build system designed around long outdated versions of Java and
operating system specific Appenders that the current development team
cannot support. Taking shortcuts in proposed fixes means an updated
release would not support all the environments of the original 1.2.x
release. Patches to Log4j 1 would also have to be compatible with the
existing Log4j 2 migration path.

* Limited Log4j 1 community

The Apache Logging PMC and committer community has been focused on the
success of Log4j 2 for nearly a decade. There had been little to no
interest in Log4j 1 in the years leading up to the 2015 EOL
announcement. While there might be people interested in working
independently on Log4j 1, until the Logging Services community can
gauge the merit of those contributors, the PMC would have to review
and apply all patches, drive the release process, and provide future
support. We feel that effort is better spent improving non-legacy
code. We welcome community contributions in the migration components
for better tooling and support.

Regards,
Ron
--
The Apache Software Foundation
V.P., Logging Services

Re: [VOTE] Release Apache Log4j 2.19.0-rc1

2022-09-11 Thread Ron Grabowski 
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->testCompressedLayout:189 ▒ 
IndexOutOfBounds Index: 2, Size: 2
[ERROR]   GelfLayoutTest.testLayoutNoCompression:256->testCompressedLayout:189 
▒ IndexOutOfBounds Index: 2, Size: 2
[ERROR]   GelfLayoutTest.testLayoutNoHost:276->testCompressedLayout:189 ▒ 
IndexOutOfBounds Index: 2, Size: 2
[ERROR]   
GelfLayoutTest.testLayoutNoThreadContext:271->testCompressedLayout:189 ▒ 
IndexOutOfBounds Index: 2, Size: 2
[INFO]
[ERROR] Tests run: 2405, Failures: 0, Errors: 4, Skipped: 13

Different error with JDK11 on Windows:

openjdk version "11.0.16.1" 2022-08-12 LTS
OpenJDK Runtime Environment Corretto-11.0.16.9.1 (build 11.0.16.1+9-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.16.9.1 (build 11.0.16.1+9-LTS, mixed 
mode)

[ERROR] 
log4j-2.19.0-rc1\log4j-api\src\test\java\org\apache\logging\log4j\util\StackLocatorUtilTest.java:[31,18]
 error: cannot find symbol
[ERROR]   symbol:   class Reflection
[ERROR]   location: package sun.reflect

On 2022/09/11 16:12:51 Gary Gregory wrote:
> I am away from home and my mac, so I am testing on Windows where I always
> get these failures:
> 
> 
> [INFO]
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running org.apache.logging.log4j.core.layout.GelfLayoutTest
> ERROR StatusLogger Recovering from
> StringBuilderEncoder.encode('{"version":"1.1","host":"US-L-GG02","timestamp":1662912585.090,"level":3,"_thread":"main","_logger":"","_Key1":"Value1","_Key2":"OpenJDK
> Runtime Environment (build 1.8.0_342-b07) from
> Temurin","_MdcKey1":"MdcValue1","_MdcKey2":"MdcValue2","full_message":"java.lang.RuntimeException:
> some error\r\n\tat
> org.apache.logging.log4j.core.layout.GelfLayoutTest.testCompressedLayout(GelfLayoutTest.java:135)\r\n\tat
> org.apache.logging.log4j.core.layout.GelfLayoutTest.testLayoutNoHost(GelfLayoutTest.java:276)\r\n\tat

[snip]

> 
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]
>  GelfLayoutTest.testLayoutNewLineDelimiter:286->testCompressedLayout:189 »
> IndexOutOfBounds Index: 2, Size: 2
> [ERROR]
>  GelfLayoutTest.testLayoutNoCompression:256->testCompressedLayout:189 »
> IndexOutOfBounds Index: 2, Size: 2
> [ERROR]   GelfLayoutTest.testLayoutNoHost:276->testCompressedLayout:189 »
> IndexOutOfBounds Index: 2, Size: 2
> [ERROR]
>  GelfLayoutTest.testLayoutNoThreadContext:271->testCompressedLayout:189 »
> IndexOutOfBounds Index: 2, Size: 2
> [INFO]
> [ERROR] Tests run: 12, Failures: 0, Errors: 4, Skipped: 0
> [INFO]
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  16.182 s
> [INFO] Finished at: 2022-09-11T09:09:46-07:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test)
> on project log4j-core:
> [ERROR]
> [ERROR] Please refer to
> C:\temp\apache-log4j-2.19.0-src\log4j-core\target\surefire-reports for the
> individual test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> 
> Thoughts?
> 
> Gary
> 
> On Fri, Sep 9, 2022, 15:56 Ralph Goers  wrote:
> 
> > This is a vote to release Log4j 2.19.0, the next version of the Log4j 2
> > project.
> >
> > Note that the security page on the web site was updated to better describe
> > CVE-2021-44228 and CVE-2021-45046. Please review those changes.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for 72 hours. All votes are welcome and we
> > encourage everyone to test the release, but only Logging PMC votes are
> > “officially” counted. As always, at least 3 +1 votes and more positive than
> > negative votes are required.
> >
> > Changes in this version include:
> >
> > New Features
> > • LOG4J2-3583: Add support for SLF4J2 stack-valued MDC. Thanks to
> > Pierrick Terrettaz.
> > • LOG4J2-2975: Add implementation of SLF4J2 fluent API. Thanks to
> > Daniel Gray.
> > Fixed Bugs
> > • LOG4J2-357