Re: Logger names for nested classes

[Apache]

You cannot replace. We always must support dots. But some people have asked for 
'/' as well.

Sent from my iPad

> On Aug 13, 2017, at 8:38 AM, Dominik Psenner  wrote:
> 
> Yes
> 
>> On 13 Aug 2017 5:13 p.m., "Gary Gregory"  wrote:
>> 
>> You are talking about replacing $ with dot in the getLogger(Class) API?
>> 
>> Gary
>> 
>>> On Aug 13, 2017 01:57, "Dominik Psenner"  wrote:
>>> 
>>> Could the $ be replaced by a dot when the logger is instantiated? Log4net
>>> picks the class name as logger name but also allows custom logger names.
>>> 
>>> On 13 Aug 2017 8:30 a.m., "Ralph Goers" 
>>> wrote:
>>> 
 Rather than implementing this I would rather have the separator chars
>> be
 specifiable in the configuration. Blatantly making this change might
>>> cause
 compatibility problems, although I am not really sure how it could.
 
 Ralph
 
> On Aug 12, 2017, at 11:29 AM, Gary Gregory 
 wrote:
> 
> Hi All,
> 
> I you use nested classes to build loggers, you end up with logger
>> names
> like A$N1, A$N2 and so on.
> 
> If you then set a logger level in a config using "A", it does not
>>> affect
> A$N1 and A$N2 as you might expect, since "$" is not a ".".
> 
> What about treating "$" like a "."?
> 
> Thoughts?
> 
> Gary
 
 
 
>>> 
>> 

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

[Apache]

I guess it was changed from getPid() to pid() after 156. I will have to see if 
Jenkins has a newer release.

Sent from my iPad

> On Aug 20, 2017, at 7:51 PM, Apache Jenkins Server 
>  wrote:
> 
> See 
> <https://builds.apache.org/job/Log4j%202.x/3005/display/redirect?page=changes>
> 
> Changes:
> 
> [rgoers] Add missing license header. Message should implement
> 
> --
> Started by an SCM change
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on ubuntu-4 (ubuntu trusty) in workspace 
> <https://builds.apache.org/job/Log4j%202.x/ws/>
>> git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>> git config remote.origin.url 
>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git # timeout=10
> Fetching upstream changes from 
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
>> git --version # timeout=10
>> git fetch --tags --progress 
>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git 
>> +refs/heads/*:refs/remotes/origin/*
>> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision c9a92d9de75f73390b3afa2ca9ade3097e478281 
> (refs/remotes/origin/master)
> Commit message: "Add missing license header. Message should implement 
> StringBuilderFormattable"
>> git config core.sparsecheckout # timeout=10
>> git checkout -f c9a92d9de75f73390b3afa2ca9ade3097e478281
>> git rev-list 39114a7af34a01312bcbefadf3e905dcb6fde75b # timeout=10
> [EnvInject] - Executing scripts and injecting environment variables after the 
> SCM step.
> [EnvInject] - Injecting as environment variables the properties content 
> LANG=en_US.UTF-8
> 
> [EnvInject] - Variables injected successfully.
> Parsing POMs
> Modules changed, recalculating dependency graph
> Established TCP socket on 49485
> maven33-agent.jar already up to date
> maven33-interceptor.jar already up to date
> maven3-interceptor-commons.jar already up to date
> [Log4j 2.x] $ /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m 
> -XX:MaxPermSize=256m -cp 
> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
>  jenkins.maven3.agent.Maven33Main 
> /home/jenkins/tools/maven/apache-maven-3.3.9 
> /home/jenkins/jenkins-slave/slave.jar 
> /home/jenkins/jenkins-slave/maven33-interceptor.jar 
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 49485
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
> support was removed in 8.0
> <===[JENKINS REMOTING CAPACITY]===>   channel started
> Executing Maven:  -B -f 
> <https://builds.apache.org/job/Log4j%202.x/ws/pom.xml> 
> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 -t 
> jenkins-toolchains.xml -DuseJava7 -Djenkins clean install
> [INFO] Scanning for projects...
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for 
> org.apache.logging.log4j.samples:log4j-samples-flume-remote:war:2.9-SNAPSHOT
> [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but 
> found duplicate declaration of plugin 
> org.apache.maven.plugins:maven-deploy-plugin @ 
> org.apache.logging.log4j.samples:log4j-samples-flume-remote:[unknown-version],
>  
> <https://builds.apache.org/job/Log4j%202.x/ws/log4j-samples/flume-remote/pom.xml,>
>  line 129, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for 
> org.apache.logging.log4j.samples:log4j-samples-flume-embedded:war:2.9-SNAPSHOT
> [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but 
> found duplicate declaration of plugin 
> org.apache.maven.plugins:maven-deploy-plugin @ 
> org.apache.logging.log4j.samples:log4j-samples-flume-embedded:[unknown-version],
>  
> <https://builds.apache.org/job/Log4j%202.x/ws/log4j-samples/flume-embedded/pom.xml,>
>  line 141, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.logging.log4j:log4j-bom:pom:2.9-SNAPSHOT
> [WARNING] 'parent.relativePath' of POM 
> org.apache.logging.log4j:log4j-bom:2.9-SNAPSHOT 
> (<https://builds.apache.org/job/Log4j%202.x/ws/log4j-bom/pom.xml)> points at 
> org.apache.logging.log4j:log4j instead of org.apache.logging:logging-parent, 
> please verify your project structure @ line 19, column 11
> [W

Log4J 2.9.1 release

[Apache]

I am thinking about doing the Log4J 2.9.1 release at the end of the week as 
there are a couple of bugs I'd like published by the time Java 9 is released.

Ralph

Re: Log4j support for Tomcat, TomEE, JBoss, etc.

[Apache]

I created a Log4J-appserver module and added the Tomcat support there. I took a 
look at jetty and it supports Log4J by routing it through slf4j. I'd like to 
change that but I am not too familiar with the internals of jetty so that might 
take a bit.

Ralph

> On Sep 7, 2017, at 4:47 AM, Mikael Ståldal  wrote:
> 
> But is it more generic than JavaEE? If not, a generic name is misleading.
> 
> 
>> On 2017-09-07 00:07, Remko Popma wrote:
>> log4j-container?
>> (To be more generic than javaee)
>>> On Sep 7, 2017, at 4:56, Ralph Goers  wrote:
>>> 
>>> Yes, the intent would be to allow containers to use Log4j as their logging 
>>> implementation.
>>> 
>>> Ralph
>>> 
 On Sep 6, 2017, at 12:26 PM, Mikael Ståldal  wrote:
 
 Is the point to integrate with JavaEE containers, not necessarily from a 
 web app?
 
 Then I would suggest a new module log4j-javaee, and to put it in the main 
 repo.
 
 
> On 2017-09-06 20:49, Ralph Goers wrote:
> On the commons list I got some pointers on how to integrate with Tomcat 
> 8.5+ and TomEE. I’ve written the class that is required but am wondering 
> where to put it. It could go in log4j-core, but that isn’t where we have 
> been putting these things. It really shouldn’t go in log4j-web as users 
> may not want that jar just to get the integration with log4j.
> I am thinking a new module should be created for this - something like 
> log4j-containers. If I do that does it belong in log4j2 or in 
> log4j-tools, log4j-boot or some other repo?
 
>>> 
>>> 
> 
> 

Re: instantiation problem

[Apache]

Can you try with the latest code in master? This may have been fixed.

Ralph

> On Sep 28, 2017, at 3:50 AM, Daan Hoogland  
> wrote:
> 
> H devs,
>  
> The following issue related to your 
> https://issues.apache.org/jira/browse/LOG4J2-1971 happened to me. I added a 
> comment there but as it is closed I would like to ring a bell here as well.
> In Apache CloudStack, we have the the long overdue need to move to log4j2 so 
> I gave a stab at it and one of the obstackles is a thing called SshHelper. It 
> gets instantiated with a logger from a test class but the error as mentioned 
> in above ticket occurs: Caused by: java.util.ServiceConfigurationError: 
> org.apache.logging.log4j.spi.Provider: Provider 
> org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
> It is only mentioned there and not the central topic.
> Is this familiar or a known issue mentioned in another ticket? We load in 
> log4j 2.9.1 using maven and java 1.8.0
>  
> Kind regards, (a.k.a.) dahn
> 
>  
> 
> 
> Daan Hoogland
> Senior Software Developer
> s: +31 61400 4545 | d: +44(0) 20 3603 0540
> e: daan.hoogl...@shapeblue.com  |  w: www.shapeblue.com  |  t:  @shapeblue
> a: 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue 
> Services India LLP is a company incorporated in India and is operated under 
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
> incorporated in Brasil and is operated under license from Shape Blue Ltd. 
> ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa 
> and is traded under license from Shape Blue Ltd. ShapeBlue is a registered 
> trademark.This email and any attachments to it may be confidential and are 
> intended solely for the use of the individual to whom it is addressed. Any 
> views or opinions expressed are solely those of the author and do not 
> necessarily represent those of Shape Blue Ltd or related companies. If you 
> are not the intended recipient of this email, you must neither take any 
> action based upon its contents, nor copy or show it to anyone. Please contact 
> the sender if you believe you have received this email in error.
> 
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build | CSForge – rapid IaaS deployment framework
> CloudStack Consulting | CloudStack Software Engineering
> CloudStack Infrastructure Support | CloudStack Bootcamp Training Courses

Re: [jira] [Updated] (LOG4J2-2121) DefaultRolloverStrategy max = 5 does not limit nuber of files

[Apache]

From your configuration the limit is 5 per rollover interval. You are 
specifying an interval of one day. Are you getting more than 5 per day?

Ralph

> On Nov 16, 2017, at 1:44 AM, Seweryn Habdank-Wojewodzki (JIRA) 
>  wrote:
> 
> 
> [ 
> https://issues.apache.org/jira/browse/LOG4J2-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Seweryn Habdank-Wojewodzki updated LOG4J2-2121:
> ---
>Description: 
> Dears,
> 
> I have very simple configuration of the RollingFile appender
> 
> 
> {code:xml}
>  fileName="${env:LOG_DIR}/${application}/endpoint.log"
>
> filePattern="$${env:LOG_DIR}/$${application}/$${date:-MM}/endpoint-%d{-MM-dd}-%i.log">
>
>%d{-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
>
>
>
>
>
> 
> {code}
> 
> This configuration works partly good. Every day there is created file in 
> folder _-MM_.
> That is expected.
> What is not expected - it is that the process is not limited at all. I mean 
> there are more than 5 files in all folders.
> 
> Questions: 
> Is it something wrong with configuration?
> is max=5 considered to be the numeber of files or folders (in my case months)?
> or max=5 is ignored at all.
> 
> I had read some hints in: [How does Log4j2 DefaultRolloverStrategy's max 
> attribute really 
> work?|https://stackoverflow.com/questions/24551768/how-does-log4j2-defaultrolloverstrategys-max-attribute-really-work]
> 
> Thanks in advance for help.
> 
>  was:
> Dears,
> 
> I have very simple configuration of the RollingFile appender
> 
> 
> {code:xml}
>  fileName="${env:LOG_DIR}/${application}/endpoint.log"
>
> filePattern="$${env:LOG_DIR}/$${application}/$${date:-MM}/endpoint-%d{-MM-dd}-%i.log">
>
>%d{-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
>
>
>
>
>
> 
> {code}
> 
> This configuration works partly good. Every day there is created file in 
> folder _-MM_.
> That is expected.
> What is not expected - it is that the process is not limited at all. I mean 
> there are more than 5 files in all folders.
> 
> Questions: 
> Is it something wrong with configuration?
> is max=5 considered to be the numeber of files or folders (in my case months)?
> or max=5 is ignored at all.
> 
> Thanks in advance for help.
> 
> 
>> DefaultRolloverStrategy max = 5 does not limit nuber of files
>> -
>> 
>>Key: LOG4J2-2121
>>URL: https://issues.apache.org/jira/browse/LOG4J2-2121
>>Project: Log4j 2
>> Issue Type: Question
>>Environment: Linux RedHat
>>   Reporter: Seweryn Habdank-Wojewodzki
>> 
>> Dears,
>> I have very simple configuration of the RollingFile appender
>> {code:xml}
>> > fileName="${env:LOG_DIR}/${application}/endpoint.log"
>>
>> filePattern="$${env:LOG_DIR}/$${application}/$${date:-MM}/endpoint-%d{-MM-dd}-%i.log">
>>
>>%d{-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
>>
>>
>>
>>
>>
>> 
>> {code}
>> This configuration works partly good. Every day there is created file in 
>> folder _-MM_.
>> That is expected.
>> What is not expected - it is that the process is not limited at all. I mean 
>> there are more than 5 files in all folders.
>> Questions: 
>> Is it something wrong with configuration?
>> is max=5 considered to be the numeber of files or folders (in my case 
>> months)?
>> or max=5 is ignored at all.
>> I had read some hints in: [How does Log4j2 DefaultRolloverStrategy's max 
>> attribute really 
>> work?|https://stackoverflow.com/questions/24551768/how-does-log4j2-defaultrolloverstrategys-max-attribute-really-work]
>> Thanks in advance for help.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
> 

Re: [VOTE] Release Log4j 2.10.0-rc1

[Apache]

The fact that you can’t see a difference is why I think it is a code page issue 
and also why I think the failure is insignificant to the release.

Ralph

> On Nov 20, 2017, at 4:40 AM, Remko Popma  wrote:
> 
> Ran another build from the release tag, with Java 7. Build succeeds.
> 
> I'll look at the checksums and the site next.
> 
> Gary, could you run another clean build?
> The error messages look strange: I cannot see any difference between the
> expected and the actual result in the error output...
> 
> 
> 
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-11T01:41:47+09:00)
> Maven home: C:\apps\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: C:\apps\jdk1.7.0_55\jre
> Default locale: en_US, platform encoding: MS932
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [
> 3.940 s]
> [INFO] Apache Log4j API Java 9 support  SUCCESS [
> 12.324 s]
> [INFO] Apache Log4j API ... SUCCESS [
> 36.662 s]
> [INFO] Apache Log4j Core ...... SUCCESS [22:30
> min]
> [INFO] Apache Log4j Core Integration Tests  SUCCESS [01:26
> min]
> [INFO] Apache Log4j 1.x Compatibility API . SUCCESS [
> 19.337 s]
> [INFO] Apache Log4j SLF4J Binding . SUCCESS [
> 10.867 s]
> [INFO] Apache Log4j to SLF4J Adapter .. SUCCESS [
> 5.751 s]
> [INFO] Apache Log4j Commons Logging Bridge  SUCCESS [
> 5.527 s]
> [INFO] Apache Log4j Flume Bridge .. SUCCESS [
> 35.251 s]
> [INFO] Apache Log4j Web ... SUCCESS [
> 13.574 s]
> [INFO] Apache Log4j Tag Library ... SUCCESS [
> 24.771 s]
> [INFO] Apache Log4j JMX GUI ... SUCCESS [
> 2.966 s]
> [INFO] Apache Log4j Samples ... SUCCESS [
> 0.846 s]
> [INFO] Apache Log4j Samples: Flume - Common ... SUCCESS [
> 4.211 s]
> [INFO] Apache Log4j Samples: Flume - Remote ... SUCCESS [
> 3.523 s]
> [INFO] Apache Log4j Samples: Flume - Embedded ..... SUCCESS [
> 9.808 s]
> [INFO] Apache Log4j Samples: Configuration .... SUCCESS [
> 4.508 s]
> [INFO] Apache Log4j Samples: LoggerProperties . SUCCESS [
> 4.883 s]
> [INFO] Apache Log4j OSGi ...... SUCCESS [
> 9.422 s]
> [INFO] Apache Log4j BOM ... SUCCESS [
> 1.082 s]
> [INFO] Apache Log4j CouchDB ... SUCCESS [
> 2.306 s]
> [INFO] Apache Log4j MongoDB ... SUCCESS [
> 4.873 s]
> [INFO] Apache Log4j Cassandra . SUCCESS [
> 27.022 s]
> [INFO] Apache Log4J Performance Tests . SUCCESS [
> 58.354 s]
> [INFO] Apache Log4j Streaming Interface ... SUCCESS [
> 15.511 s]
> [INFO] Apache Log4j JUL Adapter ... SUCCESS [
> 15.085 s]
> [INFO] Apache Log4j Liquibase Binding . SUCCESS [
> 4.396 s]
> [INFO] Apache Log4j App Server Support  SUCCESS [
> 1.993 s]
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 29:39 min
> [INFO] Finished at: 2017-11-20T20:25:57+09:00
> [INFO] Final Memory: 55M/451M
> [INFO]
> 
> 
> 
>> On Mon, Nov 20, 2017 at 5:06 PM, Remko Popma  wrote:
>> 
>> 
>>> On Nov 20, 2017, at 15:21, Ralph Goers 
>> wrote:
>>> 
>>> Oh, and I wouldn’t be surprised if the problem is caused by you using
>> MS932 and Greg using cp1252.
>> 
>> From Gary’s error messages  it seems more like a white space/newline issue
>> which is odd  because it works on my Windows and the tests use
>> String.format with %n to avoid this exact issue.
>> 
>> 
>>> 
>>> Ralph
>>> 
>>> 
>>>> On Nov 19, 2017, at 11:12 PM, Remko Popma 
>> wrote:
>>>> 
>>>> Building current master (211326b) succeeds for me when running `mvn
>> clean
>>>> verify` on
>>>> 
>>>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>>>> 2015-11-11T

Re: Event batch

[Apache]

The Logging api only allows you to log a single event at a time so it doesn’t 
make sense for an appender to have a method that accepts multiple events since 
it can’t happen. That said, appenders can queue the events and send them 
downstream in batches. I believe some of the appenders do that now.

Is there some use case I am not aware of where this method could be called?

Ralph

> On Jan 9, 2018, at 6:02 AM, Jochen Wiedmann  wrote:
> 
> Hi,
> 
> currently writing my first appender, and wondering about the following:
> 
> The Appender interface specifies a method for logging a single event.
> However, my custom Appender would greatly benefit in terms of
> performance, if I could implement an additional method
> append(LogEvent[] events). Now, I wonder if such batching has been
> omitted from the API intentionally. Or, alternatively, if I might
> replace my custom logger with a modified instance of AsyncAppender?
> 
> Thanks,
> 
> Jochen
> 

Re: Moving from Log4j 1.2 to Log4j 2.0 to handle concurrency/deadlocks/blocked threads issues.

[Apache]

Log4j 2 does not lock when calling appenders so you will not have the deadlock 
you show. 

Ralph

> On Jan 17, 2018, at 4:28 AM, Vikas Mangla  wrote:
> 
>  
>  
> Just to update, the kind of deadlocks we observe in the application as 
> attached.
>  
>  
>  
> From: Vikas Mangla 
> Sent: Wednesday, January 17, 2018 4:55 PM
> To: 'log4j-...@logging.apache.org' 
> Subject: Moving from Log4j 1.2 to Log4j 2.0 to handle 
> concurrency/deadlocks/blocked threads issues.
>  
> Hi Team,
>  
> The request here is to understand if moving from Log4j 1.2 to Log4j 2.0 
> version handles the concurrency/deadlocks/blocked threads we have on the 
> appender.
>  
> Our application is using Log4j 1.2 version and at time, we have to deal with 
> quite a such situations where under high concurrent loads, we have threads 
> getting blocked on below:
>  
> "[STUCK] ExecuteThread: '225' for queue: 'weblogic.kernel.Default 
> (self-tuning)'" daemon prio=10 tid=0x2b65d850c800 nid=0x768b waiting for 
> monitor entry [0x2b65f46c4000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.log4j.Category.callAppenders(Category.java:201)
> - waiting to lock <0x000700c46318> (a org.apache.log4j.Logger)
> at org.apache.log4j.Category.forcedLog(Category.java:388)
> at org.apache.log4j.Category.log(Category.java:835)
> at com.comverse.api.framework.log.LogUtil.writeLog(LogUtil.java:653)
> at com.comverse.api.framework.log.LogUtil.log(LogUtil.java:469)
> at 
> com.comverse.api.framework.log.LogUtil.defensiveLog(LogUtil.java:865)
>  
>  
>  
>  
> Appreciate your suggestion to move to Log4j 2.
>  
>  
> Thanks,
> Vikas Mangla
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> you may review at https://www.amdocs.com/about/email-disclaimer
> 

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

[Apache]

I haven’t looked yet but make sure the new module dependencies are added to 
Log4J-distribution.

Ralph

> On Jan 29, 2018, at 6:55 AM, Gary Gregory  wrote:
> 
> On Sun, Jan 28, 2018 at 7:38 PM, Gary Gregory 
> wrote:
> 
>> 
>> 
>> On Sun, Jan 28, 2018 at 2:25 PM, Ralph Goers 
>> wrote:
>> 
>>> I should add that each module must have a unique package hierarchy so, in
>>> general, the package names should be org.apache.logging.log4j.modulename.
>>> In this case it would be org.apache.logging.log4j.jeromq.apppender.  The
>>> mom package probably has no value.
>>> 
>> 
>> I'll change the packages and write the changes in the release notes.
>> 
> 
> Please review git master for the package name changes and release notes.
> 
> Gary
> 
> 
>> 
>> Gary
>> 
>> 
>>> 
>>> Ralph
>>> 
 On Jan 28, 2018, at 2:23 PM, Ralph Goers 
>>> wrote:
 
 Any component that is not in the core module MUST NOT use the core
>>> package. That would make it impossible to package them as Java 9 modules.
 
 Ralph
 
> On Jan 28, 2018, at 11:31 AM, Gary Gregory 
>>> wrote:
> 
> Hi All,
> 
> Now that the ZeroMQ via JeroMQ support is in its own module
>>> log4j-jeromq, I
> wonder if the Java package should change from
> 
> org.apache.logging.log4j.core.appender.mom.jeromq
> 
> to
> 
> org.apache.logging.log4j.appender.mom.jeromq
> 
> ?
> 
> Same for the recently moved JPA appender.
> 
> Same for impending move of the Kafka appender.
> 
> This would break BC for Core for apps that directly reference these
> classes. As opposed to referencing the appenders from an XML/JSON/YAML
> config file.
> 
> Gary
 
>>> 
>>> 
>>> 
>> 

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

[Apache]

That spot looks ok to me. Please make the branch

Sent from my iPad

> On Jan 29, 2018, at 10:43 PM, Remko Popma  wrote:
> 
> If you want I can create a “release-2.11” or “release-2.x” branch from that 
> commit. 
> 
> 
> 
>> On Jan 30, 2018, at 14:17, Remko Popma  wrote:
>> 
>> I think it’s possible to search for a commit hash in IntelliJ, but here is a 
>> github link:
>> https://github.com/apache/logging-log4j2/commit/21bc3aa3bf8d8a043459c6a58e774b82a617a058
>> 
>> LOG4J2-2225 provide alias for SystemMillisClock so the fully qualifie…
>> …d class name doesn't need to be published
>> 
>> (This should be included, the next commit should be excluded. )
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> On Jan 30, 2018, at 12:51, Ralph Goers  wrote:
>>> 
>>> I agree in principal but I am having a hard time figuring out which commit 
>>> that was.
>>> 
>>> Ralph
>>> 
>>>> On Jan 29, 2018, at 4:19 PM, Remko Popma  wrote:
>>>> 
>>>> Any feedback on the idea to cut a branch from commit 21bc3aa and release
>>>> 2.11 from that branch?
>>>> 
>>>> In the release notes we can announce that the next release will have
>>>> internal classes moved and packages renamed so future releases will have
>>>> binary compatibility issues.
>>>> 
>>>> To me it makes sense to therefore name the next release 3.0 to signal this
>>>> incompatibility to users.
>>>> 
>>>> Having a 3.0 release doesn’t necessarily mean we immediately start
>>>> requiring Java 8. That can could come in a subsequent release.
>>>> 
>>>> 
>>>> 
>>>>> On Tue, Jan 30, 2018 at 2:26 Remko Popma  wrote:
>>>>> 
>>>>> I agree with Ralph.
>>>>> We can still do this.
>>>>> Maybe we should start a 2.11 branch from an earlier commit, from before we
>>>>> started to rename packages, and cut a 2.11 release from that branch?
>>>>> 
>>>>> On Tue, Jan 30, 2018 at 2:08 AM, Ralph Goers 
>>>>> wrote:
>>>>> 
>>>>>> If are going to call it 3.0 I would have liked to cut a release before
>>>>>> all this modularization work and then created a branch so we could 
>>>>>> maintain
>>>>>> it if necessary.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Jan 29, 2018, at 10:04 AM, Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> If we are going to make breaking changes in this release it may be
>>>>>> wise to
>>>>>>>> also do any package renaming in this release to keep the disruption
>>>>>> limited
>>>>>>>> to a single release instead of multiple.
>>>>>>>> 
>>>>>>>> Specifically, I propose we take this release to do all package
>>>>>> renaming to
>>>>>>>> clarify the difference between classes that are "internal" to Log4j
>>>>>> core
>>>>>>>> and should not be depended on, and packages that we intend to export
>>>>>> when
>>>>>>>> Log4j core becomes a Java 9 module.
>>>>>>>> 
>>>>>>>> This likely means introducing new "internal" packages and moving
>>>>>> classes
>>>>>>>> and interfaces into these new packages.
>>>>>>>> 
>>>>>>>> I believe this is in line with what Matt proposed a while ago as the
>>>>>> plugin
>>>>>>>> API for core. All classes and interfaces that are not in an
>>>>>>>> "internal" package are safe to depend on and we commit to preserving
>>>>>> binary
>>>>>>>> compatibility for such packages. Everything in a package with
>>>>>> "internal" in
>>>>>>>> the name is subject to change.
>>>>>>>> 
>>>>>>>> Should we aim to complete this work before the 2.11 release?
>>>>>>>> 
>>>>>>> 
>>>>>>> That's OK with me, and at this point, even though log4j-core is not
>>>>>>> log4j-api, I would consider calling the release 3.0.
>>>>>>> 
>>>>>>> Gary
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 

Re: release 2.11.0 site

[Apache]

We are using the latest version of the clirr plugin.

Ralph

> On Mar 5, 2018, at 9:57 PM, Gary Gregory  wrote:
> 
> The site is using an old version of maven-site-plugin which in turns
> depends (IIRC) on a version of Apache BCEL that does not know what to do
> with Java 8 and/or 9 byte codes.
> 
> I'm pretty sure that the current version of maven-site-plugin (3.7) has
> updated its dependency on BCEL to the latest where I updated the code to
> avoid this exception.
> 
> Gary
> 
> On Mon, Mar 5, 2018 at 9:06 PM, Ralph Goers 
> wrote:
> 
>> I am afraid I am unable to build the site for release 2.11.0 and I don’t
>> know why. It fails with the stack trace below, but as far as I know nothing
>> significant has changed in this area since the last release.  Any ideas?
>> 
>> Ralph
>> 
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-site-plugin:3.4:site
>> (default-site) on project log4j-api: Execution default-site of goal
>> org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte
>> tag in constant pool: 19 -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
>> goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site)
>> on project log4j-api: Execution default-site of goal
>> org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte
>> tag in constant pool: 19
>>at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:213)
>>at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:154)
>>at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:146)
>>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
>> buildProject(LifecycleModuleBuilder.java:117)
>>at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
>> buildProject(LifecycleModuleBuilder.java:81)
>>at org.apache.maven.lifecycle.internal.builder.singlethreaded.
>> SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>at org.apache.maven.lifecycle.internal.LifecycleStarter.
>> execute(LifecycleStarter.java:128)
>>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>>at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
>>at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
>>at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>>at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>>at java.lang.reflect.Method.invoke(Method.java:606)
>>at org.codehaus.plexus.classworlds.launcher.Launcher.
>> launchEnhanced(Launcher.java:289)
>>at org.codehaus.plexus.classworlds.launcher.Launcher.
>> launch(Launcher.java:229)
>>at org.codehaus.plexus.classworlds.launcher.Launcher.
>> mainWithExitCode(Launcher.java:415)
>>at org.codehaus.plexus.classworlds.launcher.Launcher.
>> main(Launcher.java:356)
>> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
>> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.4:site
>> failed: Invalid byte tag in constant pool: 19
>>at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
>> DefaultBuildPluginManager.java:145)
>>at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:208)
>>... 20 more
>> Caused by: org.apache.bcel.classfile.ClassFormatException: Invalid byte
>> tag in constant pool: 19
>>at org.apache.bcel.classfile.Constant.readConstant(
>> Constant.java:167)
>>at org.apache.bcel.classfile.ConstantPool.(
>> ConstantPool.java:66)
>>at org.apache.bcel.classfile.ClassParser.readConstantPool(
>> ClassParser.java:239)
>>at org.apache.bcel.classfile.ClassParser.parse(ClassParser.
>> java:144)
>>at net.sf.clirr.core.internal.bcel.BcelTypeArrayBuilder.
>> extractClass(BcelTypeArrayBuilder.java:135)
>>at net.sf.clirr.core.internal.bcel.BcelTypeArrayBuilder.
>> createClassSet(BcelTypeArrayBuilder.java:82)
>>at org.codehaus.mojo.clirr.AbstractClirrMojo.
>> reso

Re: release 2.11.0 site

[Apache]

But that does give me an idea. If there is a newer version of bcel I can 
override the plugin to use it. I will try that tomorrow.

Ralph

> On Mar 5, 2018, at 11:12 PM, Apache  wrote:
> 
> We are using the latest version of the clirr plugin.
> 
> Ralph
> 
>> On Mar 5, 2018, at 9:57 PM, Gary Gregory  wrote:
>> 
>> The site is using an old version of maven-site-plugin which in turns
>> depends (IIRC) on a version of Apache BCEL that does not know what to do
>> with Java 8 and/or 9 byte codes.
>> 
>> I'm pretty sure that the current version of maven-site-plugin (3.7) has
>> updated its dependency on BCEL to the latest where I updated the code to
>> avoid this exception.
>> 
>> Gary
>> 
>> On Mon, Mar 5, 2018 at 9:06 PM, Ralph Goers 
>> wrote:
>> 
>>> I am afraid I am unable to build the site for release 2.11.0 and I don’t
>>> know why. It fails with the stack trace below, but as far as I know nothing
>>> significant has changed in this area since the last release.  Any ideas?
>>> 
>>> Ralph
>>> 
>>> [ERROR] Failed to execute goal 
>>> org.apache.maven.plugins:maven-site-plugin:3.4:site
>>> (default-site) on project log4j-api: Execution default-site of goal
>>> org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte
>>> tag in constant pool: 19 -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
>>> goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site)
>>> on project log4j-api: Execution default-site of goal
>>> org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte
>>> tag in constant pool: 19
>>>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>>> MojoExecutor.java:213)
>>>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>>> MojoExecutor.java:154)
>>>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>>> MojoExecutor.java:146)
>>>   at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
>>> buildProject(LifecycleModuleBuilder.java:117)
>>>   at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
>>> buildProject(LifecycleModuleBuilder.java:81)
>>>   at org.apache.maven.lifecycle.internal.builder.singlethreaded.
>>> SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>>   at org.apache.maven.lifecycle.internal.LifecycleStarter.
>>> execute(LifecycleStarter.java:128)
>>>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>>>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>>>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>>>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
>>>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
>>>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
>>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>   at sun.reflect.NativeMethodAccessorImpl.invoke(
>>> NativeMethodAccessorImpl.java:57)
>>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>> DelegatingMethodAccessorImpl.java:43)
>>>   at java.lang.reflect.Method.invoke(Method.java:606)
>>>   at org.codehaus.plexus.classworlds.launcher.Launcher.
>>> launchEnhanced(Launcher.java:289)
>>>   at org.codehaus.plexus.classworlds.launcher.Launcher.
>>> launch(Launcher.java:229)
>>>   at org.codehaus.plexus.classworlds.launcher.Launcher.
>>> mainWithExitCode(Launcher.java:415)
>>>   at org.codehaus.plexus.classworlds.launcher.Launcher.
>>> main(Launcher.java:356)
>>> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
>>> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.4:site
>>> failed: Invalid byte tag in constant pool: 19
>>>   at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
>>> DefaultBuildPluginManager.java:145)
>>>   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>>> MojoExecutor.java:208)
>>>   ... 20 more
>>> Caused by: org.apache.bcel.classfile.ClassFormatException: Invalid byte
>>> tag in constant pool: 19
>>>   at org.apache.bcel.classfile.Constant.readConstant(
>>> Constant.java:167)
>>>   at org.apache.bcel.classfile.ConstantPool.(
>>> ConstantPool.java:66)
>>>   at org.apache.b

Re: org.apache.logging.log4j.core.layout.AbstractStringLayout.getContentType() does not use Charset

[Apache]

But I would expect getContentType to return a mime type, not a charset.

Ralph

> On Mar 6, 2018, at 9:17 PM, Gary Gregory  wrote:
> 
>> On Tue, Mar 6, 2018 at 6:01 PM, Remko Popma  wrote:
>> 
>> Sorry, I don’t follow.
>> Why not get the appender’s layout and get the charset by calling
>> getCharset()?
>> 
> 
> Right now, I have this ugly non-OO code:
> 
>final Layout layout =
> appender.getLayout();
>final Charset charset;
>if (layout instanceof StringLayout) {
>charset = ((StringLayout) layout).getCharset();
>} else {
>charset =
> ContentType.parse(layout.getContentType()).getCharset();
>}
> 
> If getContentType() always returned the right thing, I would not need a
> conditional.
> 
> Gary
> 
> 
>> 
>> 
>> 
>>> On Mar 7, 2018, at 7:21, Gary Gregory  wrote:
>>> 
>>> Here is my current use case: I'd like to be able to query
>> getContentType()
>>> on an FILE appender (File, RollingFile, RAF, ...) and get the proper
>>> charset if the layout for that appender defines it.
>>> 
>>> Gary
>>> 
 On Tue, Mar 6, 2018 at 3:16 PM, Matt Sicker  wrote:
 
 Not all MIME types actually use the encoding parameter. For example,
 "application/json;charset=UTF-8" is technically an invalid MIME type
>> (it's
 supposed to be "application/json", and it's assumed to be UTF-8 because
 that's the only official charset for JSON). Providing the charset
 separately makes semantic sense to me.
 
> On 6 March 2018 at 16:04, Gary Gregory  wrote:
> 
> Right. AbstractStringLayout says:
> 
>   @Override
>   public Charset getCharset() {
>   return charset;
>   }
> 
>   /**
>* @return The default content type for Strings.
>*/
>   @Override
>   public String getContentType() {
>   return "text/plain";
>   }
> 
> Gary
> 
> 
> 
> On Tue, Mar 6, 2018 at 2:52 PM, Remko Popma 
 wrote:
> 
>> (Away from pc) by “use”, do you mean that the string returned by
>> getContentType() doesn’t include a charset?
>> 
>> From memory, I remember the only place this method is used is in the
>> HtmlAppender. Are there other places?
>> 
>> (Shameless plug) Every java main() method deserves
>> http://picocli.info
>> 
>>> On Mar 7, 2018, at 1:37, Gary Gregory 
 wrote:
>>> 
>>> Hi All,
>>> 
>>> It looks
>>> like org.apache.logging.log4j.core.layout.AbstractStringLayout.
>> getContentType()
>>> does NOT use its charset.
>>> 
>>> Can anyone foresee a problem with fixing this?
>>> 
>>> Gary
>> 
> 
 
 
 
 --
 Matt Sicker 
 
>> 

Re: Building log4j2 from console supporting ANSI colors fails

[Apache]

Please do. Thanks!

Ralph

> On Mar 20, 2018, at 11:20 PM, Atle Tokle  wrote:
> 
> I made a fresh clone from master today, and looked into it myself.
> In CommandLineHelpTest.java all the tests that is failing is instanciating
> a Help class. In all cases it have an alternative constructor where you can
> specify Help.Ansi.OFF to avoid that the test depends on the console it run
> from.
> 
> CommandLineTest did also have 3 faults, and here it is CommandLine.run()
> that needs Help.Ansi.OFF as it's third argument. I can send you patch if
> you tell me how you want it.
> 
> Atle
> 
> 
>> Den søn. 11. mar. 2018 kl. 11:04 skrev Remko Popma :
>> 
>> Thanks for reporting this. I’ll take a look.
>> 
>> Remko
>> 
>>> On Mar 11, 2018, at 17:32, Atle Tokle  wrote:
>>> 
>>> I tried to build from GIT bash on windows 10, and first test that failed
>>> was
>>> 
>>> testSynopsisOrderCorrectWhenParametersDeclaredOutOfOrder in
>>> 
>>> org.apache.logging.log4j.core.tools.picocli.
>>> 
>>> CommandLineHelpTest:2008
>>> 
>>> 
>>> It seems like the expected result
>>> 
>>> format("  %n") on line 2014 always assumes
>>> that no ANSI color codes is output, while the actual results have ANSI
>>> codes.
>>> 
>>> I looked into the code, and saw that one of the things that was check
>>> was if TERM environment variable started with xterm, and did a test
>>> where I first did
>>> 
>>> export TERM=z
>>> 
>>> and did then build it again. Now without faults.
>>> 
>>> The test should have more control on what environment it is running
>>> on. It is several other tests in the same testclass that fails because
>>> of same issue.
>>> 
>>> 
>>> I guess this is the same fault that Gary Gregory experienced here
>>> https://www.mail-archive.com/dev@logging.apache.org/msg05223.html
>>> 
>>> in message from Nov 19, 2017, at 6:32 PM
>>> 
>>> 
>>> Best regards
>>> 
>>> Atle
>> 

Re: Building log4j2 from console supporting ANSI colors fails

[Apache]

Obviously I didn’t see Remko’s reply before sending mine.

Ralph

> On Mar 21, 2018, at 4:57 AM, Apache  wrote:
> 
> Please do. Thanks!
> 
> Ralph
> 
>> On Mar 20, 2018, at 11:20 PM, Atle Tokle  wrote:
>> 
>> I made a fresh clone from master today, and looked into it myself.
>> In CommandLineHelpTest.java all the tests that is failing is instanciating
>> a Help class. In all cases it have an alternative constructor where you can
>> specify Help.Ansi.OFF to avoid that the test depends on the console it run
>> from.
>> 
>> CommandLineTest did also have 3 faults, and here it is CommandLine.run()
>> that needs Help.Ansi.OFF as it's third argument. I can send you patch if
>> you tell me how you want it.
>> 
>> Atle
>> 
>> 
>>> Den søn. 11. mar. 2018 kl. 11:04 skrev Remko Popma :
>>> 
>>> Thanks for reporting this. I’ll take a look.
>>> 
>>> Remko
>>> 
>>>> On Mar 11, 2018, at 17:32, Atle Tokle  wrote:
>>>> 
>>>> I tried to build from GIT bash on windows 10, and first test that failed
>>>> was
>>>> 
>>>> testSynopsisOrderCorrectWhenParametersDeclaredOutOfOrder in
>>>> 
>>>> org.apache.logging.log4j.core.tools.picocli.
>>>> 
>>>> CommandLineHelpTest:2008
>>>> 
>>>> 
>>>> It seems like the expected result
>>>> 
>>>> format("  %n") on line 2014 always assumes
>>>> that no ANSI color codes is output, while the actual results have ANSI
>>>> codes.
>>>> 
>>>> I looked into the code, and saw that one of the things that was check
>>>> was if TERM environment variable started with xterm, and did a test
>>>> where I first did
>>>> 
>>>> export TERM=z
>>>> 
>>>> and did then build it again. Now without faults.
>>>> 
>>>> The test should have more control on what environment it is running
>>>> on. It is several other tests in the same testclass that fails because
>>>> of same issue.
>>>> 
>>>> 
>>>> I guess this is the same fault that Gary Gregory experienced here
>>>> https://www.mail-archive.com/dev@logging.apache.org/msg05223.html
>>>> 
>>>> in message from Nov 19, 2017, at 6:32 PM
>>>> 
>>>> 
>>>> Best regards
>>>> 
>>>> Atle
>>> 
> 
> 
> 

Re: [VOTE] Migrate git repositories to gitbox

[Apache]

+1

Ralph


> On Apr 29, 2018, at 7:38 PM, Ílson Bolzan  wrote:
> 
> +1
> 
>> On Sun, Apr 29, 2018 at 3:20 PM, Matt Sicker  wrote:
>> 
>> Good point on the clarification. I said all git repos, and that actually
>> entails:
>> 
>> * chainsaw
>> * log4cxx
>> * log4j2 and all its repos
>> * log4net
>> * log4php
>> * parent pom
>> 
>> In fact, the only repos this doesn't cover are the old log4j 1 svn repos
>> that we have.
>> 
>>> On 29 April 2018 at 05:08, Dominik Psenner  wrote:
>>> 
>>> +1
>>> 
>>> Also for the log4net repository.
>>> 
>>>> On Sat, 28 Apr 2018, 23:59 Remko Popma,  wrote:
>>>> 
>>>> +1
>>>> 
>>>> On Sat, Apr 28, 2018 at 11:48 PM, Gary Gregory >> 
>>>> wrote:
>>>> 
>>>>> +1
>>>>> 
>>>>> Gary
>>>>> 
>>>>>> On Sat, Apr 28, 2018, 17:12 Matt Sicker  wrote:
>>>>>> 
>>>>>> This is a vote to migrate from the existing git-wip-us
>> infrastructure
>>>> to
>>>>>> the currently supported gitbox infrastructure that Infra advocates
>>> for
>>>>>> using nowadays. Using gitbox will allow our projects to integrate
>>>> better
>>>>>> with GitHub including the ability to merge PRs directly from the
>> site
>>>> and
>>>>>> the ability to push commits to GitHub and have them be
>> automatically
>>>>>> mirrored back to Apache. Not only that, but new Apache projects
>>> cannot
>>>>> use
>>>>>> the old git-wip-us infrastructure anymore, so it makes sense to
>>> migrate
>>>>> to
>>>>>> the best supported option going forward.
>>>>>> 
>>>>>> The migration process will entail the following:
>>>>>> 
>>>>>> * Marking existing git repo as read-only
>>>>>> * Moving repo to gitbox
>>>>>> * Update website and pom.xml with new SCM URLs
>>>>>> * Update local git clones with the new remote URL(s)
>>>>>> 
>>>>>> Note that this vote only applies to the source code. I'm not
>>>> considering
>>>>>> using GitHub Issues instead of Jira, for example. Note also that
>> this
>>>>> vote
>>>>>> does not apply to the use of subversion for publishing the site
>>>>> (svnpubsub)
>>>>>> nor the use of it for publishing releases (only available via svn),
>>>>> though
>>>>>> moving the sites from svnpubsub to gitpubsub (i.e., storing the
>>>> generated
>>>>>> site in a branch called "asf-site", similar to the "gh-pages"
>> branch
>>>>>> feature on GitHub) would be a related topic to cover separately.
>>>>>> 
>>>>>> Please vote +1, +0, -0, or -1.
>>>>>> 
>>>>>> --
>>>>>> Matt Sicker 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 

Re: Log4j-audit release

[Apache]

Ok. I will take a look in the morning.

Sent from my iPad

> On Jun 10, 2018, at 12:23 AM, Remko Popma  wrote:
> 
> That is with
> C:\Users\remko\IdeaProjects\logging-log4j-audit-sample>mvn --version
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T16:58:13+09:00)
> Maven home: C:\apps\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: C:\apps\jdk1.8.0_161\jre
> Default locale: en_GB, platform encoding: MS932
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> 
>> On Sun, Jun 10, 2018 at 4:21 PM, Remko Popma  wrote:
>> 
>> getting this now
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Audit Sample Parent  SUCCESS [
>> 0.839 s]
>> [INFO] audit-service-api .. FAILURE [
>> 0.006 s]
>> [INFO] audit-service-war .. SKIPPED
>> [INFO] audit-service .. SKIPPED
>> [INFO] sample-app . SKIPPED
>> [INFO] 
>> 
>> [INFO] BUILD FAILURE
>> [INFO] 
>> 
>> [INFO] Total time: 1.116 s
>> [INFO] Finished at: 2018-06-10T16:11:08+09:00
>> [INFO] Final Memory: 12M/245M
>> [INFO] 
>> 
>> [ERROR] Plugin 
>> org.apache.logging.log4j:log4j-audit-maven-plugin:1.0.0-SNAPSHOT
>> or one of its dependencies could not be resolved: Could not find artifact
>> org.apache.logging.log4j:log4j-audit-maven-plugin:jar:1.0.0-SNAPSHOT ->
>> [Help 1]
>> [ERROR]
>> 
>> 
>> On Sun, Jun 10, 2018 at 2:53 PM, Ralph Goers 
>> wrote:
>> 
>>> I finally have had time to take a breath and do something with this. I
>>> have tried to incorporate many of your comments in the documentation. I
>>> have updated my web site accordingly. Some comments are below.
>>> 
>>> I really would like feedback on more than just the site as I need to
>>> release this.
>>> 
>>>> On May 7, 2018, at 5:42 PM, Remko Popma  wrote:
>>>> 
>>>> I had time to look at this during the flight, here it is:
>>>> 
>>>> 
>>>> index.html
>>>> 
>>>> typo: Diagnostic logs are critical in aiding in maintaining the
>>>> servicability -> critical in maintaining?
>>>> 
>>>> Overall, the first three sections, "What is Audit Logging", What is the
>>>> difference between audit logging and normal logging?" and "What is Log4j
>>>> Audit?" are very good: give good overview of the purpose and don't
>>> assume
>>>> prior knowledge.
>>>> 
>>>> From the "Features" section, the narrative changes perspective from what
>>>> users would want to what Log4j Audit provides.
>>>> I would add a few sentences to that transition, something like:
>>>> 
>>>> {quote}
>>>> (after Features)
>>>> Each application has its own audit events. Before using Log4j Audit,
>>>> applications need to define AuditMessages that capture the exact
>>> attributes
>>>> of its audit events. The [Getting Started](link) page provides a
>>> tutorial
>>>> that explains how to define audit events for an application.
>>>> 
>>>> (after Audit Event Catalog header)
>>>> Once audit events are defined, they need to be maintained: as the
>>>> application evolves, developers will inevitably discover they need to
>>> add,
>>>> remove or change attributes of the audit events. Log4j Audit can persist
>>>> the audit event definitions in a JSON file. This file becomes the Audit
>>>> Event Catalog for the application. Log4j Audit is designed to store the
>>>> event definition file in a Git repository so that the evolution of the
>>>> audit events themselves have an audit trail in the Git history of the
>>> file.
>>>> Log4j Audit provides a web interface for editing the events.
>>>> 
>>>> Log4j Audit uses the catalog of events to determine ... (continue with
>>>> current text of Audit Event Catalog)
>>>> {quote}
>>>> 
>>>> Question about the Requirements section: it 

Re: Log4j-audit release

[Apache]

Oh. You don’t have the maven plugin. Since it hasn’t been released yet you will 
have to build the Log4J audit project.

Sent from my iPad

> On Jun 10, 2018, at 12:23 AM, Remko Popma  wrote:
> 
> That is with
> C:\Users\remko\IdeaProjects\logging-log4j-audit-sample>mvn --version
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T16:58:13+09:00)
> Maven home: C:\apps\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: C:\apps\jdk1.8.0_161\jre
> Default locale: en_GB, platform encoding: MS932
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> 
>> On Sun, Jun 10, 2018 at 4:21 PM, Remko Popma  wrote:
>> 
>> getting this now
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Audit Sample Parent  SUCCESS [
>> 0.839 s]
>> [INFO] audit-service-api .. FAILURE [
>> 0.006 s]
>> [INFO] audit-service-war .. SKIPPED
>> [INFO] audit-service .. SKIPPED
>> [INFO] sample-app . SKIPPED
>> [INFO] 
>> 
>> [INFO] BUILD FAILURE
>> [INFO] 
>> 
>> [INFO] Total time: 1.116 s
>> [INFO] Finished at: 2018-06-10T16:11:08+09:00
>> [INFO] Final Memory: 12M/245M
>> [INFO] 
>> 
>> [ERROR] Plugin 
>> org.apache.logging.log4j:log4j-audit-maven-plugin:1.0.0-SNAPSHOT
>> or one of its dependencies could not be resolved: Could not find artifact
>> org.apache.logging.log4j:log4j-audit-maven-plugin:jar:1.0.0-SNAPSHOT ->
>> [Help 1]
>> [ERROR]
>> 
>> 
>> On Sun, Jun 10, 2018 at 2:53 PM, Ralph Goers 
>> wrote:
>> 
>>> I finally have had time to take a breath and do something with this. I
>>> have tried to incorporate many of your comments in the documentation. I
>>> have updated my web site accordingly. Some comments are below.
>>> 
>>> I really would like feedback on more than just the site as I need to
>>> release this.
>>> 
>>>> On May 7, 2018, at 5:42 PM, Remko Popma  wrote:
>>>> 
>>>> I had time to look at this during the flight, here it is:
>>>> 
>>>> 
>>>> index.html
>>>> 
>>>> typo: Diagnostic logs are critical in aiding in maintaining the
>>>> servicability -> critical in maintaining?
>>>> 
>>>> Overall, the first three sections, "What is Audit Logging", What is the
>>>> difference between audit logging and normal logging?" and "What is Log4j
>>>> Audit?" are very good: give good overview of the purpose and don't
>>> assume
>>>> prior knowledge.
>>>> 
>>>> From the "Features" section, the narrative changes perspective from what
>>>> users would want to what Log4j Audit provides.
>>>> I would add a few sentences to that transition, something like:
>>>> 
>>>> {quote}
>>>> (after Features)
>>>> Each application has its own audit events. Before using Log4j Audit,
>>>> applications need to define AuditMessages that capture the exact
>>> attributes
>>>> of its audit events. The [Getting Started](link) page provides a
>>> tutorial
>>>> that explains how to define audit events for an application.
>>>> 
>>>> (after Audit Event Catalog header)
>>>> Once audit events are defined, they need to be maintained: as the
>>>> application evolves, developers will inevitably discover they need to
>>> add,
>>>> remove or change attributes of the audit events. Log4j Audit can persist
>>>> the audit event definitions in a JSON file. This file becomes the Audit
>>>> Event Catalog for the application. Log4j Audit is designed to store the
>>>> event definition file in a Git repository so that the evolution of the
>>>> audit events themselves have an audit trail in the Git history of the
>>> file.
>>>> Log4j Audit provides a web interface for editing the events.
>>>> 
>>>> Log4j Audit uses the catalog of events to determine ... (continue with
>>>> current text of Audit Event Catalog)
>>>> {quote}

Re: Log4j-audit release

[Apache]

One thing I forgot to mention. Although Log4J audit doesn’t make use of the 
product or category the catalog’s usefulness really comes into play when you 
want to create a UI to query and display the audit events. In that case 
associating events with products and/or categories can be quite helpful.

Ralph

> On Jun 10, 2018, at 1:36 AM, Apache  wrote:
> 
> Oh. You don’t have the maven plugin. Since it hasn’t been released yet you 
> will have to build the Log4J audit project.
> 
> Sent from my iPad
> 
>> On Jun 10, 2018, at 12:23 AM, Remko Popma  wrote:
>> 
>> That is with
>> C:\Users\remko\IdeaProjects\logging-log4j-audit-sample>mvn --version
>> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
>> 2017-10-18T16:58:13+09:00)
>> Maven home: C:\apps\apache-maven-3.5.2\bin\..
>> Java version: 1.8.0_161, vendor: Oracle Corporation
>> Java home: C:\apps\jdk1.8.0_161\jre
>> Default locale: en_GB, platform encoding: MS932
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>> 
>> 
>>> On Sun, Jun 10, 2018 at 4:21 PM, Remko Popma  wrote:
>>> 
>>> getting this now
>>> 
>>> [INFO] Reactor Summary:
>>> [INFO]
>>> [INFO] Audit Sample Parent  SUCCESS [
>>> 0.839 s]
>>> [INFO] audit-service-api .. FAILURE [
>>> 0.006 s]
>>> [INFO] audit-service-war .. SKIPPED
>>> [INFO] audit-service .. SKIPPED
>>> [INFO] sample-app . SKIPPED
>>> [INFO] 
>>> 
>>> [INFO] BUILD FAILURE
>>> [INFO] 
>>> 
>>> [INFO] Total time: 1.116 s
>>> [INFO] Finished at: 2018-06-10T16:11:08+09:00
>>> [INFO] Final Memory: 12M/245M
>>> [INFO] 
>>> 
>>> [ERROR] Plugin 
>>> org.apache.logging.log4j:log4j-audit-maven-plugin:1.0.0-SNAPSHOT
>>> or one of its dependencies could not be resolved: Could not find artifact
>>> org.apache.logging.log4j:log4j-audit-maven-plugin:jar:1.0.0-SNAPSHOT ->
>>> [Help 1]
>>> [ERROR]
>>> 
>>> 
>>> On Sun, Jun 10, 2018 at 2:53 PM, Ralph Goers 
>>> wrote:
>>> 
>>>> I finally have had time to take a breath and do something with this. I
>>>> have tried to incorporate many of your comments in the documentation. I
>>>> have updated my web site accordingly. Some comments are below.
>>>> 
>>>> I really would like feedback on more than just the site as I need to
>>>> release this.
>>>> 
>>>>> On May 7, 2018, at 5:42 PM, Remko Popma  wrote:
>>>>> 
>>>>> I had time to look at this during the flight, here it is:
>>>>> 
>>>>> 
>>>>> index.html
>>>>> 
>>>>> typo: Diagnostic logs are critical in aiding in maintaining the
>>>>> servicability -> critical in maintaining?
>>>>> 
>>>>> Overall, the first three sections, "What is Audit Logging", What is the
>>>>> difference between audit logging and normal logging?" and "What is Log4j
>>>>> Audit?" are very good: give good overview of the purpose and don't
>>>> assume
>>>>> prior knowledge.
>>>>> 
>>>>> From the "Features" section, the narrative changes perspective from what
>>>>> users would want to what Log4j Audit provides.
>>>>> I would add a few sentences to that transition, something like:
>>>>> 
>>>>> {quote}
>>>>> (after Features)
>>>>> Each application has its own audit events. Before using Log4j Audit,
>>>>> applications need to define AuditMessages that capture the exact
>>>> attributes
>>>>> of its audit events. The [Getting Started](link) page provides a
>>>> tutorial
>>>>> that explains how to define audit events for an application.
>>>>> 
>>>>> (after Audit Event Catalog header)
>>>>> Once audit events are defined, they need to be maintained: as the
>>>>> application evolves, developers will inevitably discover they need to
>>

Re: Log4j-audit release

[Apache]

No. It implements that feature through the request context but I wouldn’t use a 
catalog for simple trace logging.

Ralph

> On Jun 11, 2018, at 4:29 AM, Matt Sicker  wrote:
> 
> One thing I didn’t notice until now is that this is a superset of
> distributed trace logging. Would you say that’s accurate?
> 
>> On Mon, Jun 11, 2018 at 00:54, Apache  wrote:
>> 
>> One thing I forgot to mention. Although Log4J audit doesn’t make use of
>> the product or category the catalog’s usefulness really comes into play
>> when you want to create a UI to query and display the audit events. In that
>> case associating events with products and/or categories can be quite
>> helpful.
>> 
>> Ralph
>> 
>>> On Jun 10, 2018, at 1:36 AM, Apache  wrote:
>>> 
>>> Oh. You don’t have the maven plugin. Since it hasn’t been released yet
>> you will have to build the Log4J audit project.
>>> 
>>> Sent from my iPad
>>> 
>>>> On Jun 10, 2018, at 12:23 AM, Remko Popma 
>> wrote:
>>>> 
>>>> That is with
>>>> C:\Users\remko\IdeaProjects\logging-log4j-audit-sample>mvn --version
>>>> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
>>>> 2017-10-18T16:58:13+09:00)
>>>> Maven home: C:\apps\apache-maven-3.5.2\bin\..
>>>> Java version: 1.8.0_161, vendor: Oracle Corporation
>>>> Java home: C:\apps\jdk1.8.0_161\jre
>>>> Default locale: en_GB, platform encoding: MS932
>>>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>>>> 
>>>> 
>>>>> On Sun, Jun 10, 2018 at 4:21 PM, Remko Popma 
>> wrote:
>>>>> 
>>>>> getting this now
>>>>> 
>>>>> [INFO] Reactor Summary:
>>>>> [INFO]
>>>>> [INFO] Audit Sample Parent  SUCCESS [
>>>>> 0.839 s]
>>>>> [INFO] audit-service-api .. FAILURE [
>>>>> 0.006 s]
>>>>> [INFO] audit-service-war .. SKIPPED
>>>>> [INFO] audit-service .. SKIPPED
>>>>> [INFO] sample-app . SKIPPED
>>>>> [INFO] 
>>>>> 
>>>>> [INFO] BUILD FAILURE
>>>>> [INFO] 
>>>>> 
>>>>> [INFO] Total time: 1.116 s
>>>>> [INFO] Finished at: 2018-06-10T16:11:08+09:00
>>>>> [INFO] Final Memory: 12M/245M
>>>>> [INFO] 
>>>>> 
>>>>> [ERROR] Plugin
>> org.apache.logging.log4j:log4j-audit-maven-plugin:1.0.0-SNAPSHOT
>>>>> or one of its dependencies could not be resolved: Could not find
>> artifact
>>>>> org.apache.logging.log4j:log4j-audit-maven-plugin:jar:1.0.0-SNAPSHOT ->
>>>>> [Help 1]
>>>>> [ERROR]
>>>>> 
>>>>> 
>>>>> On Sun, Jun 10, 2018 at 2:53 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>>> wrote:
>>>>> 
>>>>>> I finally have had time to take a breath and do something with this. I
>>>>>> have tried to incorporate many of your comments in the documentation.
>> I
>>>>>> have updated my web site accordingly. Some comments are below.
>>>>>> 
>>>>>> I really would like feedback on more than just the site as I need to
>>>>>> release this.
>>>>>> 
>>>>>>> On May 7, 2018, at 5:42 PM, Remko Popma 
>> wrote:
>>>>>>> 
>>>>>>> I had time to look at this during the flight, here it is:
>>>>>>> 
>>>>>>> 
>>>>>>> index.html
>>>>>>> 
>>>>>>> typo: Diagnostic logs are critical in aiding in maintaining the
>>>>>>> servicability -> critical in maintaining?
>>>>>>> 
>>>>>>> Overall, the first three sections, "What is Audit Logging", What is
>> the
>>>>>>> difference between audit logging and normal logging?" and "What is
>> Log4j
>>>>>>> Audit?" are very goo

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

[Apache]

Today this vote will have been open 1 week. I would ask that you please find 
the time to review it and vote.

Ralph

> On Jun 15, 2018, at 5:34 PM, Gary Gregory  wrote:
> 
> Good points.
> 
> I see use cases for audit logging in at least two of my products at work,
> so I have no doubts as to the usefulness of this project.
> 
> Gary
> 
> On Fri, Jun 15, 2018 at 6:10 PM Ralph Goers 
> wrote:
> 
>> The only criteria I am aware of for voting for a release is that it has
>> the proper notice and license files and is properly signed. AFAIK nothing
>> says it has to actually build. That said, voting on such a release would be
>> stupid.
>> 
>> Obviously, I would like others to use (and support) the project or I
>> wouldn’t have bothered creating it here. At the same time I really wouldn’t
>> like to have the software just languish.
>> 
>> The bottom line is you should use whatever criteria makes YOU comfortable,
>> not me.
>> 
>> Ralph
>> 
>>> On Jun 15, 2018, at 4:29 PM, Gary Gregory 
>> wrote:
>>> 
>>> Ralph,
>>> 
>>> I kind of feel bad just VOTing by running through the build motions and
>> not
>>> having an application to actually test. That would just mean that I can
>>> build the software and look at reports.
>>> 
>>> Do you feel comfortable with this kind of VOTE?
>>> 
>>> Gary
>>> 
>>> On Fri, Jun 15, 2018 at 5:08 PM Ralph Goers 
>>> wrote:
>>> 
>>>> This vote has now been open 5 days and needs one more +1 vote from a PMC
>>>> member. Again, votes from everyone are welcome.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Jun 14, 2018, at 4:35 PM, Ralph Goers 
>>>> wrote:
>>>>> 
>>>>> Thanks Matt. Gary replied that he had started reviewing it 2 days OK.
>>>> Mikael’s vote also would count on this but he has been very quiet for
>> the
>>>> last several months. I hope all is well.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On Jun 14, 2018, at 7:58 AM, Matt Sicker  wrote:
>>>>>> 
>>>>>> I'll be back home tomorrow where I have computers set up for testing
>>>> Apache
>>>>>> releases.
>>>>>> 
>>>>>>> On 12 June 2018 at 22:10, Remko Popma  wrote:
>>>>>>> 
>>>>>>> +1
>>>>>>> 
>>>>>>> (Shameless plug) Every java main() method deserves
>> http://picocli.info
>>>>>>> 
>>>>>>>> On Jun 13, 2018, at 9:03, Gary Gregory 
>>>> wrote:
>>>>>>>> 
>>>>>>>> I started reading the site, which is good so far... should be able
>> to
>>>>>>>> continue tomorrow...
>>>>>>>> 
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>>> On Tue, Jun 12, 2018, 17:35 Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 48 hours have passed with no votes or discussion.
>>>>>>>>> 
>>>>>>>>> Ralph
>>>>>>>>> 
>>>>>>>>>> On Jun 10, 2018, at 2:26 PM, Ralph Goers <
>>>> ralph.go...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> This is a vote to release Log4j-Audit 1.0.0, the first release of
>>>> the
>>>>>>>>> Log4j Audit 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.
>>>>>>>>>> 
>>>>>>>>>> Tag:
>>>>>>>>>> a)  for a new copy do "git clone
>>>>>>>>> https://git-wip-us.apache.org/repos/asf/logging-log4j-audit.git";
>> and
>>>>>>> then
>>>>>>>>> "git checkout tags/log4-audit-1.0.0-rc1”
>>>>>>>>>> b) for an existing working copy to “git pull” and then “git
>> checkout
>>>>>>>>> tags/log4j-audit-1.0.0-rc1”
>>>>>>>>>> 
>>>>>>>>>> Web Site:  http://rgoers.github.io/log4j-audit/index.html
>>>>>>>>>> 
>>>>>>>>>> Maven Artifacts:
>>>>>>>>> https://repository.apache.org/content/repositories/
>>>>>>> orgapachelogging-1035/
>>>>>>>>>> 
>>>>>>>>>> Distribution archives:
>>>>>>>>> https://dist.apache.org/repos/dist/dev/logging/log4j-audit/
>>>>>>>>>> 
>>>>>>>>>> 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-1035/org/apache/logging/log4j/
>>>>>>>>>> 
>>>>>>>>>> Ralph
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Matt Sicker 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 

Re: CI for Log4j Audit

[Apache]

If you are familiar with Jenkins you should just be able to create one.

Ralph

> On May 7, 2019, at 12:53 AM, Andrei Ivanov  wrote:
> 
> Hi,
> I'm trying to see if there's a CI job defined for the Audit project.
> 
> I'm looking at https://builds.apache.org/view/L/view/Logging/ and I don't
> see one.
> 
> If I am correct, how can one be defined?
> 
> Regards,
> Andrei

Re: Hide message in throwable

[Apache]

The code you highlight is there to include the throwable converter if one is 
not specified. If you add your own throwable converter then handlesThrowable 
will be true and that code won’t be run.

You can also hide the exception with %noex.

Under what circumstances do you want to hide the exception? You may be able to 
use a pattern selector to choose the pattern.

Ralph

> On May 24, 2019, at 4:14 AM, Gaurav  wrote:
> 
> 
> 
>> On 2019/05/22 15:36:11, "Carter Kozak"  wrote: 
>> Once you've implemented a LogEventPatternConverter which overrides 
>> "handlesThrowable" to return true, you will also need to use that pattern in 
>> the PatternLayout pattern. This can be a little bit confusing since the 
>> pattern layout will automatically add a default throwable pattern converter 
>> to the end without specifying "%ex". This is because alwaysWriteExceptions 
>> defaults to true, and the pattern doesn't already include a converter which 
>> returns true from "handlesThrowable". So updating the pattern "%m%n" to 
>> "%m%n%noMessageThrowable" (replacing "noMessageThrowable" with the pattern 
>> you have specified on your converter).
>> 
>> Apologies if I've misunderstood the issue.
>> 
>> -ck
>>> On Wed, May 22, 2019, at 11:21, Matt Sicker wrote:
>>> Did you include the @ConverterKeys annotation on your converters? You
>>> shouldn't need to make a new layout I think.
>>> 
 On Wed, 22 May 2019 at 06:18, Gaurav  wrote:
 
 
 
> On 2019/05/16 14:59:56, Matt Sicker  wrote:
> Instead of extending the plugin classes, you can create your own
> plugins. PatternConverters are relatively trivial plugins, so I
> wouldn't worry too much about code duplication.
> 
> I could be missing a feature, though.
> 
>> On Thu, 16 May 2019 at 09:32, Gaurav  wrote:
>> 
>> Hi,
>> 
>> I want to hide the message in the throwable.
>> 
>> What I've tried -
>> 1. Create a custom layout by extending AbstractStringLayout.
>> 2. Create a pattern parser.
>> 3. Create a pattern converter by extending ThrowablePatternConverter.
>> 
>> Is there a simpler way to do this?
>> 
>> In log4j1.2, it was simple to just extend the classes, but the classes 
>> in log4j2 are final.
>> 
>> Please assist.
> 
> 
> 
> --
> Matt Sicker 
> Hi,
 I've created -
 1.A custom pattern converter plugin extending LogEventPatternConverter
 2.A custom layout plugin extending AbstractStringLayout.
 3.A custom pattern parser similar to "PatternParser" class in log4j2.
 
 But, as, I am dealing with throwables and cannot modify log4j2 jar, I need 
 to plug the custom pattern converter instance in my parser class.
 
 if (alwaysWriteExceptions && !handlesThrowable) {
 final LogEventPatternConverter pc = TestPatternConverter.newInstance();
 list.add(new PatternFormatter(pc, FormattingInfo.getDefault()));
 }
 
 But, at the startup, it is throwing the following exception -
 
 Caused by: java.lang.ClassCastException: com.test.TestPatternParser cannot 
 be cast to org.apache.logging.log4j.core.pattern.PatternParser
 at 
 org.apache.logging.log4j.core.layout.PatternLayout.createPatternParser(PatternLayout.java:244)
 at 
 org.apache.logging.log4j.core.layout.PatternLayout$SerializerBuilder.build(PatternLayout.java:375)
 ... 32 more
 
 Please assist.
>>> 
>>> 
>>> 
>>> -- 
>>> Matt Sicker 
>>> 
>> Hi Ralph,
> I need to support handling of throwables in logging statements.
> Case 1: If the layout is PatternLayout, then keep using original log4j2 
> layout functionality.
> Case 2: If the layout is my custom layout, then just hide the exception 
> message and keep other layout features as is!
> 
> *Note: The log4j2.xml configuration will contain rolling file appenders where 
> they could either have a patternlayout or a customlayout.
> 
> If I just create a new PatternConverter, then it will replace log4j2's 
> converter keys such as %ex.
> 
> I cannot just create a new PatternConverter for this use case, as to handle 
> throwables, "PatternParser" class has the following code- 
> 
> if (alwaysWriteExceptions && !handlesThrowable) {
>final LogEventPatternConverter pc = 
> ExtendedThrowablePatternConverter.newInstance(config, null);
>list.add(new PatternFormatter(pc, FormattingInfo.getDefault()));
> }
> 
> Here, the only way to hide throwable message is to replace 
> "ExtendedThrowablePatternConverter" with my "CustomPatternConverter".
> 
> Please assist if there is a better way to do this.
> 
> 
> 

Re: PR for LOG4J2-2639

[Apache]

Yeah, I have thought quite a bit about this and have never been able to come up 
with a solution that didn’t require modifications to Java. With the new 
withLocation method it should be possible to provide a null value that gets 
replaced with a constant that is generated by the annotation processor, but it 
seems many people like to disable annotation processing at compile time. It 
would also mean that users wouldn’t be debugging the “real” code but a modified 
copy.

Ralph

> On Jun 23, 2019, at 1:50 AM, Matt Sicker  wrote:
> 
> It certainly sounds interesting to me, though I say that about a lot of
> things (which are all interesting though!). For Java, I’d imagine we’d need
> to do something at the compiler level unless there’s enough information in
> the bytecode to reconstruct the proper Java source location info. If only
> Java had a macro for line numbers and other compile time info like C and
> Python do.
> 
>> On Sun, Jun 23, 2019 at 03:46, Remko Popma  wrote:
>> 
>> It would be ideal if location information could be collected at compile
>> time. It is constant and unchanging information after all and it seems
>> silly to have to dynamically calculate this at runtime.
>> 
>> While Java doesn’t have compile time macros I was wondering if there’s
>> anything else we can do.
>> 
>> One potential option is using the annotation processing API to hook into
>> the compiler AST tree (but requires annotations, so may not be the solution
>> for us).
>> 
>> Another option (perhaps a better one) is using a byte code manipulation
>> library to inject location information.
>> 
>> I haven’t looked into this in detail and I don’t know yet what (if any) API
>> would be needed to support this.
>> 
>> Would this be interesting to pursue?
>> 
>> Remko.
>> 
>> 
>>> On Sun, Jun 23, 2019 at 6:15 Matt Sicker  wrote:
>>> 
>>> This pattern might be useful for the Scala and Kotlin adapters since
>> those
>>> languages have some form of compile time macros (or at least Scala does,
>> as
>>> does Groovy). Though that could even fill in the location info directly
>>> rather than walking the call stack at runtime.
>>> 
>>> On Sat, Jun 22, 2019 at 12:24, Ralph Goers 
>>> wrote:
>>> 
>>>> Yes.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Jun 22, 2019, at 9:54 AM, Gary Gregory 
>>>> wrote:
>>>>> 
>>>>> 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.com/apache/logging-log4j2/pull/284>. This adds new
>>>> Logger
>>>>>> methods to allow a builder pattern to be used to accumulate the
>>>> parameters
>>>>>> to a logging call before logging the event. I got this idea from
>>>> messages
>>>>>> on the SLF4J list but I haven’t looked at that code at all so I have
>>> no
>>>>>> idea how Ceki implemented that. To be honest, the only reason I
>>>> implemented
>>>>>> this was because it allows the location information to be exposed
>> and
>>>>>> calculated in a hopefully more efficient way. I haven’t run tests to
>>>> verify
>>>>>> that but the default way of calculating a location only requires
>>>> looking up
>>>>>> 2 levels in the call stack instead of dynamically searching for the
>>>>>> matching FQCN.
>>>>>> 
>>>>>> I haven’t written the doc for this yet but a typical logging call
>>> might
>>>>>> look like:
>>>>>> 
>>>>>> logger.atDebug().withLocation().withMessage(*Hello
>>>>>> {}”).withParameters(“Sam”).withMarker(myMarker).log();
>>>>>> 
>>>>>> This feature is only implemented on master as it takes advantage of
>>>> Java 8
>>>>>> default methods to maintain backward compatibility.
>>>>>> 
>>>>>> Ralph
>>>> 
>>>> 
>>>> --
>>> Matt Sicker 
>>> 
>> 
> -- 
> Matt Sicker 

Re: Location performance

[Apache]

Yes, that was a very interesting read and describes very well how JMH works.

Ralph

> On Jul 7, 2019, at 4:30 AM, Remko Popma  wrote:
> 
> This may be of interest:
> https://www.researchgate.net/publication/333825812_What's_Wrong_With_My_Benchmark_Results_Studying_Bad_Practices_in_JMH_Benchmarks
> 
> 
> 
>> On Jul 6, 2019, at 5:49, Raman Gupta  wrote:
>> 
>> I'm no JMH expert... but, there is a lot more going on there than just
>> iterations to avoid the extra time for JIT compilation on warmup.
>> Checkout https://shipilev.net/talks/devoxx-Nov2013-benchmarking.pdf
>> for an idea of the kinds of problems naive timer-only benchmarks
>> encounter, and the different ways in which JMH solves them. There are
>> other good presentations about JMH at https://shipilev.net/ as well.
>> 
>> Secondly, JMH isn't de-optimizing the JVM (a la client JVM)
>> willy-nilly. It just provides an API that allows you to measure what
>> you (hopefully) think you are measuring e.g. blackholes to consume
>> results that would otherwise be optimized away by the JVM because the
>> result would otherwise be unused, and so forth. AFAIK,  it doesn't
>> apply these "de-optimizations" on its own -- it just provides an API
>> for you to use as needed.
>> 
>> Thirdly, I don't believe JMH does anything (by default) to optimize
>> away GC or anything like that -- it in fact allows you to consider the
>> affect of GC by running lots of iterations, so that the affect of GC
>> *is* taken into account in the benchmark. It does have a (non-default)
>> option to run a GC before each iteration for specific use cases (e.g.
>> benchmarks which generate lots of garbage). It also has a GC profiler
>> to understand the impact of GC on your results (see
>> https://github.com/Valloric/jmh-playground/blob/master/src/jmh/java/org/openjdk/jmh/samples/JMHSample_35_Profilers.java).
>> 
>> Regards,
>> Raman
>> 
>> 
>>> On Fri, Jul 5, 2019 at 4:06 PM Ralph Goers  
>>> wrote:
>>> 
>>> Actually, I would disagree. First, I don’t think the first thousand or slow 
>>> iterations running slow would matter much with 1.5 million iterations. Lets 
>>> say the first thousand take 10 times longer the the rest of the iterations. 
>>> That is still only the equivalent of 10,000 iterations. That is a blip in 
>>> 1.5 million.
>>> Second, measuring the impact of garbage collection should be a part of the 
>>> benchmark if your code is generating garbage.
>>> 
>>> Again, I am not saying JMH doesn’t have its place, but I have to think 
>>> something weird is going on when JMH is showing the no location benchmark 
>>> to be about 4 times faster than the location benchmark where the simplistic 
>>> loop test shows the elapsed time when including the location information to 
>>> be about twice that of not including. I can tell that the call to 
>>> StackWalker isn’t being optimized away because it still shows up in YourKit 
>>> as the most expensive operation. And when I turn on immediateFlush flushing 
>>> the file shows up in YourKit
>>> 
>>> Ralph
>>> 
 On Jul 5, 2019, at 12:18 PM, Matt Sicker  wrote:
 
 What I mean is that JMH is written to avoid including
 behind-the-scenes variability of the code execution that changes from
 startup until the code has been compiled to native code, garbage
 collection, synchronization points for threads (safe points), etc. All
 these things become variable noise that affects benchmarks when the
 code you're testing executes in an especially short period of time
 (e.g., appending a log event is pretty fast relatively speaking).
 
 Say you wrote a naive benchmark like this:
 
 long start = System.nanoTime();
 for (int i = 0; i < 1_000_000; i++) {
 runBenchmark();
 }
 long end = System.nanoTime();
 double averageExecutionNanos = (end - start) / 1_000_000.0;
 
 This will give incorrect results because the first thousand or so
 iterations will be run by the first gen compiler, then the next
 iterations will be run via code output from the second gen compiler
 which will be significantly faster. So then you might split that up
 into a warmup block and a measurement block. You'll still be including
 the execution time spent in garbage collection, thread
 synchronization, JIT compilation, etc., that isn't relevant to the
 benchmark for executing the code over time.
 
> On Fri, 5 Jul 2019 at 01:25, Ralph Goers  > wrote:
> 
> Well, I can infer it from the examples but it doesn’t come close to 
> explaining some of the things we use it for. I would argue that logging a 
> line whose value changes on every call, even if it is just an incremented 
> integer, that writes to a file is more than a micro-benchmark, and I 
> truly want to know how it is going to perform in real life, not with all 
> the optimizations disabled.  When I first started Log4j 2 I noticed right 
> aw

Re: Due-to in changes.xml

[Apache]

As I said, no one with commit privs should appear in the due-to. Ever. They 
already appear in the by column and in git. It diminishes the thanks we give to 
contributors to add ourselves, so I would request you please stop doing that, 
frankly I am not sure why you started as I don’t recall seeing you do that 
until recently.

Ralph

> On Aug 13, 2019, at 9:48 PM, Gary Gregory  wrote:
> 
> 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 of changes.xml. Historically we have always
>> used that to give credit to non-committers who provide patches or
>> significantly contribute to them.  As committers we get credit in the
>> source control and in the dev field of the action entry. It seems over the
>> top to be giving ourselves credit that way and, in fact, takes away from
>> the contributions we receive from non-committers as every single change is
>> due to one of us, even if all we do is commit the patch.
>> 
>> If we need to vote on this I would vote that committers names should never
>> appear in the due-to field.
>> 
>> Ralph
>> 

Re: Send LogEvent time as timestamp to Kafka Producer when using KafkaAppender

[Apache]

It hasn’t been discussed. Feel free to create a Jira issue and a pull request. 
Please make sure you include a test for your change. 

Ralph

> On Aug 21, 2019, at 12:31 AM, Federico D'Ambrosio  wrote:
> 
> Hello everyone,
> 
> I wanted to discuss with you if it's possible or if you would consider
> useful adding the possibility to send the LogEvent time as a timestamp for
> the record when using the log4j KafkaAppender. I think it could be very
> useful for everyone using Kafka as a log aggregator having the possibility
> to use the event time, rather than the time the record is being sent.
> Bear with me, I've just started looking at the souce code of KafkaAppender
> and may overlook something in the broader scope of log4j.
> 
> As far as I've seen in the source code, the message is sent by KafkaManager:
> 
> 146private void tryAppend(final LogEvent event) throws
> ExecutionException, InterruptedException, TimeoutException {147
> final Layout layout = getLayout();148
> byte[] data;149if (layout instanceof SerializedLayout) {150
>final byte[] header = layout.getHeader();151final
> byte[] body = layout.toByteArray(event);152data = new
> byte[header.length + body.length];153
> System.arraycopy(header, 0, data, 0, header.length);154
> System.arraycopy(body, 0, data, header.length, body.length);155
> } else {156data = layout.toByteArray(event);157
> }*158manager.send(data);*159}
> 
> with manager.send() implemented this way, with highlighted the creation of
> the ProducerRecord:
> 
> 108public void send(final byte[] msg) throws ExecutionException,
> InterruptedException, TimeoutException {109if (producer !=
> null) {110byte[] newKey = null;12if(key !=
> null && key.contains("${")) {113newKey =
> getLoggerContext().getConfiguration().getStrSubstitutor().replace(key).getBytes(StandardCharsets.UTF_8);114
>   } else if (key != null) {115newKey =
> key.getBytes(StandardCharsets.UTF_8);116}117*118
> final ProducerRecord newRecord = new
> ProducerRecord<>(topic, newKey, msg);*119if (syncSend)
> {120final Future response =
> producer.send(newRecord);121
> response.get(timeoutMillis, TimeUnit.MILLISECONDS);122}
> else {123producer.send(newRecord, new Callback() {124
>  @Override125public void
> onCompletion(final RecordMetadata metadata, final Exception e) {126
>if (e != null) {127
> LOGGER.error("Unable to write to Kafka in appender [" + getName() +
> "]", e);128}129        }130
>});131}132}133}
> 
> 
> Now, ProducerRecord has the additional parameters, in particular, I'm
> looking at:
> https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html#ProducerRecord-java.lang.String-java.lang.Integer-java.lang.Long-K-V-
> <https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html#ProducerRecord-java.lang.String-java.lang.Integer-java.lang.Long-K-V->
> 
> public ProducerRecord(java.lang.String topic,
>  java.lang.Integer partition,
>  java.lang.Long timestamp,
>  K
> <https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html>
> key,
>  V
> <https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html>
> value)
> 
> which would allow us to set the timestamp as *LogEvent#getTimeMillis()*,
> but would force us to also input the partition where the record should be
> sent. Still, the logic behind the partitioning within the KafkaProducer is
> so that if partition is null, then the defined partitioner will be used
> (DefaultPartitioner or the one defined by the 'partitioner.class'
> property), so, we could simply assign it as null.
> 
> In terms of interface, we could add a single flag in the KafkaAppender
> definition, something like:
> 
>  
> 
> If the 'timestamp' flag is false, then the record would be sent with the
> timestamp parameter of the ProducerRecord as null, leaving the behaviour as
> it is right now.
> 
> What do you think about that? Was this something which was already
> discussed?
> 
> Thank you for your attention,
> Federico

Blog post

[Apache]

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: Modularization

[Apache]

I have no plans to do this in master. One of the main goals of 3.0 is to be 
fully modularized. This is just one part of that.

Ralph

> On Mar 8, 2020, at 5:26 AM, Gary Gregory  wrote:
> 
> Is this worthy doing in 2.0? In 3 we can do whatever we want IMO.
> 
> Gary
> 
>> On Sat, Mar 7, 2020, 23:24 Ralph Goers  wrote:
>> 
>> I started looking at log4j-core in master today with an eye towards
>> creating the module-info.java file. As I went through it I realized we
>> would have to expose almost all of the packages because we have co-mingled
>> private implementations along with public interfaces and abstract class. We
>> really can’t move the public classes as user’s are currently referencing
>> them so I am proposing that we move the private classes. I already started
>> that with LogBuilder by creating a directory named “internal” off of core.
>> Rather than having internal directories all over the place I am thinking we
>> should mimic the same existing package structure under the internal
>> directory and move private classes there.
>> 
>> Thoughts?
>> 
>> Ralph
>> 

Re: Modularization

[Apache]

Rats. Substitute “no plans” with “only plans”.

Ralph

> On Mar 8, 2020, at 6:31 AM, Apache  wrote:
> 
> I have no plans to do this in master. One of the main goals of 3.0 is to be 
> fully modularized. This is just one part of that.
> 
> Ralph
> 
>> On Mar 8, 2020, at 5:26 AM, Gary Gregory  wrote:
>> 
>> Is this worthy doing in 2.0? In 3 we can do whatever we want IMO.
>> 
>> Gary
>> 
>>>> On Sat, Mar 7, 2020, 23:24 Ralph Goers  wrote:
>>> 
>>> I started looking at log4j-core in master today with an eye towards
>>> creating the module-info.java file. As I went through it I realized we
>>> would have to expose almost all of the packages because we have co-mingled
>>> private implementations along with public interfaces and abstract class. We
>>> really can’t move the public classes as user’s are currently referencing
>>> them so I am proposing that we move the private classes. I already started
>>> that with LogBuilder by creating a directory named “internal” off of core.
>>> Rather than having internal directories all over the place I am thinking we
>>> should mimic the same existing package structure under the internal
>>> directory and move private classes there.
>>> 
>>> Thoughts?
>>> 
>>> Ralph
>>> 

Re: TimeFilterTest

[Apache]

I started testing this. It doesn’t handle daylight savings at all and some of 
the tests make no sense. I’m rewriting it using java.time and implementing 
better tests.

Ralph

> On Mar 8, 2020, at 11:19 AM, Ralph Goers  wrote:
> 
> Is anyone else having problems with TimeFilterTest in core today?  I am in 
> Arizona so we did not spring forward as we are MST all year.  I see the test 
> is setting a timezone of America/Los Angeles.
> 
> Ralph

Re: log4net: resurrection

[Apache]

No one is ever happy moving a project to dormant status.  But it is unfair to 
users to let them think the project is being maintained when the reality is 
quite different than that. 

The main issue that needs to be overcome is getting a release out. The ASF has 
some requirements around releases that have to be met, but that isn’t the hard 
part. Most users want convenience binaries and no one who is active knows how 
to do that. There is a documented process in confluence but I have no idea how 
accurate it is. 

Once a release is able to be cut getting assistance from others would probably 
be easier. 

Also, the ASF infra team really doesn’t care about the status of the project 
and is not a driving force in this. 

To be honest, log4cxx was in a similar position. But that project has had a 
couple of people come forward and are working towards a release. We hope they 
succeed.

Ralph

> On Apr 5, 2020, at 11:56 PM, Davyd McColl  wrote:
> 
> Hi all
> 
> I'm new to this list, been using log4net for around 9 years, and only this
> week discovered that it is being made dormant (and what that means).
> 
> I've been told that the team has been looking for outside help for around 2
> years, with no-one forthcoming. Unfortunately, as I say, this is the first
> I've heard of it. I'd like to keep log4net alive because it's used
> ubiquitously and I think it's a valuable project.
> 
> I publish my own nuget packages (https://www.nuget.org/profiles/davydm)
> though obviously, not with the same methodologies of the existing log4net
> infrastructure. I see that there's a 2.0.9 release that could potentially
> happen (as per the source), whilst 2.0.8 is still the current release, so
> I'm assuming there's something holding that up. I also see 34 pull requests
> on GitHub which are in different states of activity, but many have been
> dormant since 2018.
> 
> I'd like to help, but I'm not sure where to start with the log4net infra (I
> hear there's Jira (I've had little experience) and Jenkins (I've had
> reasonable experience, but not with pipelines)). I'm not even sure what the
> state of play is for that infra. I'm sure there are good reasons for making
> the project dormant -- some of those may include the desire to free up
> infra which could be used elsewhere (or just not paid for).
> 
> As I say, I'd like to keep log4net alive. I see a few options here:
> 
> 1. I learn your infra and your processes. I integrate and try to keep
> things pretty-much as they were (though I'm sure some things would have to
> change -- all things do). I don't mind spending the time learning the
> domain, if that's agreeable to everyone and the project retains it's
> original branding and status. One thing I'm concerned about here is the
> dormant backlog
> 2. As above, with a bit of a clean-slate philosophy: I'd like to remove all
> backlog items that aren't critical and start with the least outstanding
> stuff possible. If a report is important, it will be reported again. Trying
> to trace down the authors and origins of 2+year-old reports is going to be
> frustrating. Issues which aren't attended to just become noise in the
> backlog, imo.
> 3. I fork and perform the "clean slate" approach of above, inviting others
> to use my variant and log issues there. Uptake will naturally be slow (if
> even noticeable), which will give me time to deal with incoming issues. On
> the other hand, I'd have full control and no need to bother anyone else. I
> would have to come up with a new name and make it clear that it's a fork,
> though also make it clear I'd be standing on the shoulders of giants.
> 
> Personally, I'd like (1) because it keeps the project that people rely on
> alive. Since I'm new to the mailing list, I can't discern yet the sentiment
> towards the project, except that everyone was quite happy to have it made
> dormant, so it feels like there's not a lot of desire to keep it going --
> which is ok: everything comes to an end at some point, and, as stated
> earlier, I'm sure there are good reasons for making log4net dormant. As a
> consumer of log4net, I'd much rather not have to switch over to another
> framework once there's an issue which affects me more than my logged one
> (inability to flush logs -- it was on a proof-of-concept project, so it
> isn't _that_ important to have the functionality right now).
> 
> Apologies for the rambling message. I was prompted to reach out by Ralph
> Goers in the discussion for LOG4NET-606, so I hope I haven't been a bother.
> 
> -d
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> If you say that getting the money is the most important thing
> You will spend your life completely wasting your time
> You will be doing things you don't like doing
> In order to go on living
> That is, to go on doing things you don't like doing
> 
> Which is stupid.
> 
> - Alan Watts
> https://www.youtube.com/watch?v=-gXTZM_uPMY
> 
> *Quidquid latine dictum sit, altum sonatur. *

Re: log4net: resurrection

[Apache]

The only requirement to become an experienced open source developer is passion. 
Open source developers are just people who like to work on code that everyone 
can use. That’s it. If you have the time, can help with the technical problems 
needed to get the project moving, and can collaborate with others you have 
everything you need. 

Yes, the code base is still at Github and nothing has been done that can’t be 
undone. But for the PMC to move the project out of dormant status you would 
first need to demonstrate progress, which might mean collaborating on a private 
fork until you are ready to merge it.

Ralph

> On Apr 6, 2020, at 1:10 AM, Tim Sargent  wrote:
> 
> I remember reading the call for .NET devs (a few years back) to help with
> the .NET core version for Log4Net.   That's about the time I joined the
> mailing list.
> 
> As I understand it, dormant just means it's no longer being maintained, but
> the current version is still available for download and use via NuGet.
> I've toyed with the idea of getting involved in an open source project,
> which is why I originally joined the list.  Unfortunately, I don't think I
> have the background in open source projects to be an effective contributor,
> let alone sponsor.   I'm very experienced in .NET (having been doing it
> since it was in its final preview for 1.0), and I have experience with unit
> tests, automated builds and release pipelines (though it's all MS based via
> TFS and MSTest).
> 
> Having said that, it sounds like Mr McColl has a strong interest in keeping
> it alive, and I'd be happy to offer assistance in any way he finds
> beneficial.
> 
> Thanks.
> 
>> On Mon, Apr 6, 2020 at 12:50 AM Apache  wrote:
>> 
>> No one is ever happy moving a project to dormant status.  But it is unfair
>> to users to let them think the project is being maintained when the reality
>> is quite different than that.
>> 
>> The main issue that needs to be overcome is getting a release out. The ASF
>> has some requirements around releases that have to be met, but that isn’t
>> the hard part. Most users want convenience binaries and no one who is
>> active knows how to do that. There is a documented process in confluence
>> but I have no idea how accurate it is.
>> 
>> Once a release is able to be cut getting assistance from others would
>> probably be easier.
>> 
>> Also, the ASF infra team really doesn’t care about the status of the
>> project and is not a driving force in this.
>> 
>> To be honest, log4cxx was in a similar position. But that project has had
>> a couple of people come forward and are working towards a release. We hope
>> they succeed.
>> 
>> Ralph
>> 
>>>> On Apr 5, 2020, at 11:56 PM, Davyd McColl  wrote:
>>> 
>>> Hi all
>>> 
>>> I'm new to this list, been using log4net for around 9 years, and only
>> this
>>> week discovered that it is being made dormant (and what that means).
>>> 
>>> I've been told that the team has been looking for outside help for
>> around 2
>>> years, with no-one forthcoming. Unfortunately, as I say, this is the
>> first
>>> I've heard of it. I'd like to keep log4net alive because it's used
>>> ubiquitously and I think it's a valuable project.
>>> 
>>> I publish my own nuget packages (https://www.nuget.org/profiles/davydm)
>>> though obviously, not with the same methodologies of the existing log4net
>>> infrastructure. I see that there's a 2.0.9 release that could potentially
>>> happen (as per the source), whilst 2.0.8 is still the current release, so
>>> I'm assuming there's something holding that up. I also see 34 pull
>> requests
>>> on GitHub which are in different states of activity, but many have been
>>> dormant since 2018.
>>> 
>>> I'd like to help, but I'm not sure where to start with the log4net infra
>> (I
>>> hear there's Jira (I've had little experience) and Jenkins (I've had
>>> reasonable experience, but not with pipelines)). I'm not even sure what
>> the
>>> state of play is for that infra. I'm sure there are good reasons for
>> making
>>> the project dormant -- some of those may include the desire to free up
>>> infra which could be used elsewhere (or just not paid for).
>>> 
>>> As I say, I'd like to keep log4net alive. I see a few options here:
>>> 
>>> 1. I learn your infra and your processes. I integrate and try to keep
>>> things pretty-much as they 

Re: log4net: resurrection

[Apache]

What you are seeing is exactly what I have been saying. The major problem is 
that none of the existing logging services committers know how to perform a 
release. We know there have been fixes committed that are needed. We just don’t 
know how to make them available. That is exactly why I said your focus should 
be getting a release built.

Ralph

> On Apr 6, 2020, at 10:15 PM, Davyd McColl  wrote:
> 
> That sounds promising, and I'm aware that I'm probably being a little 
> annoying by now, but I've also noticed that the source package is version is 
> at 2.0.9 where the latest release package version is 2.0.8. That version was 
> bumped 3 years ago. In between the last release date and last commits are 
> commits including at least 2 PR merges (42 and 23 ), both of which seen 
> significant.
> 
> I guess what I'm asking is what's holding up the 2.0.9 release? If I'm to 
> fork, PR and even if that PR is accepted, how do I avoid the fate of 2.0.9?
> 
> Or is that something I can assist with right now?
> 
> Please understand where I'm coming from: I'd really like to keep log4net 
> alive, but, like anyone, I have limited time resources, so I'd prefer to 
> spend that time on tasks with some reasonable probability of success.
> 
> Thanks
> -d
> 
> 
>> On April 6, 2020 23:00:36 Ralph Goers  wrote:
>> 
>> No. What I am implying is that you would begin the work necessary to perform 
>> a release on a fork. When you are ready you would submit a PR and one or 
>> more of the existing PMC members would review that and merge it. You would 
>> then collaborate with us to get the release published.
>> 
>> There is a big difference between us reviewing PRs and merging them for 
>> stuff we know little about vs us providing the karma you will need to 
>> formally get a release done.
>> 
>> Ralph
>> 
>>>> On Apr 6, 2020, at 12:57 PM, Davyd McColl  wrote:
>>> Unfortunately, this would suggest that forking and publishing under a 
>>> different package name is probably the best idea. There are, as noted 
>>> before, 34 stagnated pull requests currently at GitHub, many of which 
>>> haven't seen any attention since 2018. It would seem to be a fool's errand 
>>> to open a 35th I'm hopes that it would be the one to get attention.
>>> If I'm wrong (and I'd love to be) please correct me.
>>> -d
>>> On April 6, 2020 15:59:26 Apache  wrote:
>>>> The only requirement to become an experienced open source developer is 
>>>> passion. Open source developers are just people who like to work on code 
>>>> that everyone can use. That’s it. If you have the time, can help with the 
>>>> technical problems needed to get the project moving, and can collaborate 
>>>> with others you have everything you need.
>>>> Yes, the code base is still at Github and nothing has been done that can’t 
>>>> be undone. But for the PMC to move the project out of dormant status you 
>>>> would first need to demonstrate progress, which might mean collaborating 
>>>> on a private fork until you are ready to merge it.
>>>> Ralph
>>>>> On Apr 6, 2020, at 1:10 AM, Tim Sargent  wrote:
>>>>> I remember reading the call for .NET devs (a few years back) to help with
>>>>> the .NET core version for Log4Net.   That's about the time I joined the
>>>>> mailing list.
>>>>> As I understand it, dormant just means it's no longer being maintained, 
>>>>> but
>>>>> the current version is still available for download and use via NuGet.
>>>>> I've toyed with the idea of getting involved in an open source project,
>>>>> which is why I originally joined the list.  Unfortunately, I don't think I
>>>>> have the background in open source projects to be an effective 
>>>>> contributor,
>>>>> let alone sponsor.   I'm very experienced in .NET (having been doing it
>>>>> since it was in its final preview for 1.0), and I have experience with 
>>>>> unit
>>>>> tests, automated builds and release pipelines (though it's all MS based 
>>>>> via
>>>>> TFS and MSTest).
>>>>> Having said that, it sounds like Mr McColl has a strong interest in 
>>>>> keeping
>>>>> it alive, and I'd be happy to offer assistance in any way he finds
>>>>> beneficial.
>>>>> Thanks.
>>>>>> On Mon, Apr 6, 2020 at 12:50 AM Apache  

Re: Json Template Layout

[Apache]

Feel free to merge it. I will test it there when I can.

Ralph


> On May 22, 2020, at 4:50 AM, Volkan Yazıcı  wrote:
> 
> Hey Ralph,
> 
> Here is my status update:
> 
> -~- Benchmarks -~-
> 
> I have removed the benchmarks results. It takes ~8h for a complete run
> and I don't want to repeat that cycle after every change. I might
> revisit this idea once JTL becomes more stable in terms of its
> features.
> 
> -~- Flattening of MDC fields -~-
> 
> I have changed the MDC directive as follows:
> 
>mdc
>mdc:flatten[=][,stringify]
>mdc:pattern=[,flatten=][,stringify]
>mdc:key=[,stringify]
> 
> This also allowed JsonTemplateLayout to produce the *exact* output as
> GelfLayout and EcsLayout, where MDC keys are flattened and values are
> stringified.
> 
> -~- Null termination, newlines, Logstash, and etc. -~-
> 
> I have tried to reproduce the experiment you have shared, though could
> not really succeed due to some Docker command failure in restartApp.sh.
> Further, I find the associated Spring setup quite cumbersome to wrap my
> mind around it. That said, I have done something else: I have improved
> LogstashIT such that
> 
> 1. Logstash is configured with both "tcp" and "gelf" input plugins,
> 
> 2. LogstashIT employs JsonTemplateLayout against both inputs, repeats
>   the same using GelfLayout and EcsLayout, and verifies the populated
>   content in Elasticsearch.
> 
> One can easily validate this on the branch as follows:
> 
>$ ./mvnw clean package -DskipTests
>$ ./mvnw \
>verify -o -P docker \
>-pl 
> log4j-layout-jackson-json,log4j-plugins,log4j-core,log4j-api,log4j-layout-json-template
> \
>-Dtest="Dummy.java" -DtrimStackTrace=false -DfailIfNoTests=false
> 
> One can repeat the very same by running LogstashIT in IDE after
> starting the containers:
> 
>$ ./mvnw \
>docker:start -o -P docker \
>-pl 
> log4j-layout-jackson-json,log4j-plugins,log4j-core,log4j-api,log4j-layout-json-template
> 
> I don't know what is wrong with the Spring Cloud Config setup you have
> shared, but I have no reasons to believe that JsonTemplateLayout is the
> suspect.
> 
> Regarding your remark about everything getting escaped... This might
> happen when Logstash fails to read an input. In such a case, it puts
> the entire payload into the "message" field (hence, the escaping) and
> stores it like that.
> 
> From now on, I don't know how to proceed with this problem, in
> particular, given I believe the problem is in somewhere else but
> JsonTemplateLayout.
> 
> -~- Merging branch to master -~-
> 
> Unless there are objections, I want to merge the branch to master.
> There on I will share json-template-layout.md with the community to
> collect some feedback on the API. In particular, I have existing users
> of LogstashLayout in mind.
> 
> Kind regards.
> 
>> On Mon, May 18, 2020 at 1:18 AM Ralph Goers  
>> wrote:
>> 
>> 
>> 
 On May 17, 2020, at 2:37 PM, Volkan Yazıcı  wrote:
>>> 
>>> Thanks so much for the thorough review Ralph, really appreciated! I
>>> will address issues you have raised.
>>> 
>>> [As a side note, I have pushed changes containing performance
>>> improvements and benchmark results. The module is still dependency
>>> free and performance-wise pretty good.]
>>> 
 all the default templates separate the message from the exception
>>> 
>>> Yes, this I have also realized while studying the source code of
>>> GelfLayout. Some random thoughts:
>>> 
>>> 1. How about introducing a firstNonNull-like operator:
>>>  ${json:op:firstNonNull:${json:message},${json:exception:message}}.
>>>  Parsing this would not be trivial, given the list of variables
>>>  can include comma in various forms. Though the rest should
>>>  be tractable. (Feels like JsonTemplateLayout directives will at
>>>  some point catch up the with ones in PatternLayout.)
>> 
>> The problem here is that I want newlines in the message. I’m not sure what 
>> firstNonNull means in the context of a message. The message itself won’t 
>> have nulls. The Gelf format dictates the null is at the end of the JSON 
>> string.
>> 
>>> 
>>> 2. How about introducing a fallback parameter to the "message"
>>>  directive: ${json:message:fallback=exception:message}.
>> 
>> Again, I don’t know what that means or how it solves my problem of wanting 
>> newlines in the message.
>> 
>>> 
>>> 3. May I challenge the request: Do one really need it? You store
>>>  individual values, i.e, message and exception, in individual fields.
>>>  When one is missing and the other is present, isn't it just a
>>>  presentation layer issue to display it properly?
>> 
>> Picture how a log event looks in a file with a “standard” PatternLayout. In 
>> Kibana by default you get 3 columns, the timestamp, a field I don’t care 
>> about and the message. I want the message to appear just as it would in a 
>> log file without the timestamp. Yes, I can click on each message and see its 
>> attributes, but that takes longer. And I wa

Re: Testing Json Template Layout

[Apache]

Yes, please do.

Ralph

> On Jul 22, 2020, at 6:22 AM, Volkan Yazıcı  wrote:
> 
> Ralph, I am fine with the current state of the plugin. I don't intend to
> have further improvements in the short-term regarding KeyValuePair
> enhancements and/or escape character handling. If you are okay with it, I
> want to start rebasing this onto 2.x branch.
> 
>> On Mon, Jul 6, 2020 at 8:01 AM Ralph Goers 
>> wrote:
>> 
>> I finally got some time to start testing JsonTemplateLayout against the
>> logging in the cloud documentation. The first problem I ran into is that
>> additional fields don’t work. I don’t see any configurations that have them
>> and the Builder doesn’t have annotations on the key and value fields so I
>> suspect it just doesn’t work.  Why didn’t you just enhance KeyValuePair to
>> add the type attribute?
>> 
>> After I corrected the EventTemplateAdditionalField plugin I still can’t
>> get stack traces the way I want them. I thought you said you added the
>> ability to format the message using a pattern, but I don’t see that in the
>> documentation or in MessageResolver. Was that not included? As I said, I
>> require the stack trace to print in the message field in Kibana, not just
>> be a key in the additional data.
>> 
>> 
>> Ralph
>> 

Re: Literals in Velocity Templates

[Apache]

Don’t convert whole files. You only need to convert where there is an existing 
document that is xdoc that needs to be updated.

Ralph

> On Aug 19, 2020, at 11:53 PM, Volkan Yazıcı  wrote:
> 
> Hello,
> 
> I have started cherry-picking JsonTemplateLayout from master into
> release-2.x. There I was welcomed by a big surprise: documentation infra
> between master (AsciiDoc) and release-2.x (Xdoc, Markdown, Velocity) are
> totally different. Right now I am busy with (manually?) converting
> thousands of lines of AsciiDoc to Xdoc. Though I could not make Velocity
> Template literals work. Given the following input
> 
> 200 #[[{
> 201 "mdc": "${json:mdcfoo}",
> ...
> 218 }]]#
> 
> "./mvnw site -DskipTests" produces the following error:
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pdf-plugin:1.2:pdf (pdf) on project log4j:
> Error during document generation: Error whenn parsing Velocity file
> /home/vy/Projects/log4j2/target/pdf/site.tmp/xdoc/manual/layouts.xml.vm:
> Encountered ":mdcfoo}\",\n  \"exception\": {\n\"exception_class\": \""
> at line 201, column 17 of
> /home/vy/Projects/log4j2/target/pdf/site.tmp/xdoc/manual/layouts.xml.vm
> [ERROR] Was expecting one of:
> [ERROR] "}" ...
> [ERROR]  ...
> 
> Any ideas on how to fix it? (I prefer to avoid replacing every occurence of
> a $ with ${dollar}, for obvious reasons.)
> 
> Kind regards.

Re: [VOTE] Release Log4Net 2.0.9

[Apache]

@dslextreme.com
>>> >> >
>>> >> >> wrote:
>>> >> >> >>
>>> >> >> >> Going back through my old emails I see Dominik had the same
>>> problem
>>> >> in
>>> >> >> 2016. I forgot to update my files and now I see the instructions have
>>> >> >> changed.
>>> >> >> >>
>>> >> >> >> Ralph
>>> >> >> >>
>>> >> >> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers <
>>> >> ralph.go...@dslextreme.com>
>>> >> >> wrote:
>>> >> >> >>>
>>> >> >> >>> I figured out that the document is now at home.apache.org <
>>> >> >> http://home.apache.org/>. Unfortunately, that didn’t do me any good.
>>> >> gpg
>>> >> >> -d is failing with “No secret key”. That doesn’t seem too surprising
>>> >> since
>>> >> >> my key wasn’t used to sign the document.
>>> >> >> >>>
>>> >> >> >>> Ralph
>>> >> >> >>>
>>> >> >> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers <
>>> >> ralph.go...@dslextreme.com>
>>> >> >> wrote:
>>> >> >> >>>>
>>> >> >> >>>> Dominik,
>>> >> >> >>>>
>>> >> >> >>>> The README file says that the keys can be found at
>>> >> >> https://people.apache.org/keys/group/logging-pmc.asc <
>>> >> >> https://people.apache.org/keys/group/logging-pmc.asc>.  That url
>>> >> returns
>>> >> >> a 404. Any idea where it moved to?
>>> >> >> >>>>
>>> >> >> >>>> Ralph
>>> >> >> >>>>
>>> >> >> >>>>> On Aug 17, 2020, at 9:39 AM, Dominik Psenner <
>>> dpsen...@gmail.com>
>>> >> >> wrote:
>>> >> >> >>>>>
>>> >> >> >>>>> I guess that would be a nuget publish.
>>> >> >> >>>>>
>>> >> >> >>>>>
>>> >> https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package
>>> >> >> >>>>>
>>> >> >> >>>>> The credentials to that account are stored in the private
>>> repos of
>>> >> >> logging
>>> >> >> >>>>> pmc. Most members of the pmc should be in the set of recipients
>>> >> with
>>> >> >> their
>>> >> >> >>>>> gpg key.
>>> >> >> >>>>> --
>>> >> >> >>>>> Sent from my phone. Typos are a kind gift to anyone who
>>> happens to
>>> >> >> find
>>> >> >> >>>>> them.
>>> >> >> >>>>>
>>> >> >> >>>>> On Mon, Aug 17, 2020, 08:56 Davyd McColl 
>>> >> wrote:
>>> >> >> >>>>>
>>> >> >> >>>>>> Great!
>>> >> >> >>>>>>
>>> >> >> >>>>>> How do we get the nupkg to nuget.org? This is the final step
>>> >> that
>>> >> >> most
>>> >> >> >>>>>> users are going to be interested in.
>>> >> >> >>>>>>
>>> >> >> >>>>>> Having a look at what's at the url you posted, I have ideas on
>>> >> how
>>> >> >> to
>>> >> >> >>>>>> streamline future releases, so the next time I'm in that area,
>>> >> I'm
>>> >> >> >>>>>> definitely implementing those ideas. I don't see changes to
>>> the
>>> >> >> Release
>>> >> >> >>>>>> Notes area -- if I were to try to streamline that into a
>>> release,
>>> >> >> would a
>>> >> >> >>>>>> CHANGELOG file be useful? Or is there a better way?
>>> >> >> >>>>>>
>>> >> >> >>>>>&

Re: Log4net: 2.0.9 release notes missing

[Apache]

I do not believe the site has been updated to reflect the release. I looked 
into it but couldn’t figure out how to build the site.

Ralph

> On Aug 24, 2020, at 6:38 AM, Dominik Psenner  wrote:
> 
> Hi
> 
> People noticed that the release notes of 2.0.9 are missing while they
> should be documented here:
> 
> http://logging.apache.org/log4net/release/release-notes.html
> 
> Best regards
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.

Re: JsonTemplateLayout is ready to be shipped!

[Apache]

No, you are not expected to do anything else. While anyone can be the release 
manager, typically I have been doing them. They take a fair amount of time so I 
typically start them on a weekend when I have enough time. 

Ralph

> On Aug 27, 2020, at 6:14 AM, Volkan Yazıcı  wrote:
> 
> Would anybody mind giving some indication on an ETA, please?
> Or am I expected to do anything else further?
> 
>> On Tue, Aug 25, 2020 at 1:59 PM Volkan Yazıcı 
>> wrote:
>> 
>> Yes, you read the subject right! I will appreciate it if people can spare
>> some time on skimming through the change set one last time regarding JTL.
>> 
>> So... When are we gonna cut the ribbon for the upcoming 2.x release?
>> 

Re: A little stuck with publishing updated site / docs for log4net 2.0.9

[Apache]

I will take care of the main logging site. It currently uses the ASF CMS but we 
have to get off of it so there isn’t much point in you having to learn how to 
deal with it.

Ralph

> On Aug 28, 2020, at 12:26 AM, Davyd McColl  wrote:
> 
> Hi all
> 
> I've been trying to update content for http://logging.apache.org/log4net (in 
> particular http://logging.apache.org/log4net/release) and I'm sure I'm just 
> doing something silly or missing something.
> 
> I've followed instructions at 
> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
>  up to point 7, which is where I'm stuck: I'm not sure where to find the 
> mentioned index.twig, mainly because I'm not sure what the document is 
> referring to with "main web site". I haven't found an index.twig in 
> https://svn.apache.org/repos/infra/websites/production/logging/content/ or 
> https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly 
> possible I'm just missing it. Or that neither of these is the correct place 
> to look.
> 
> I have updated documentation and committed via SVN for 2.0.9, including 
> updating the 2.x link. I haven't marked the project as "not dormant" (yet -- 
> I'll be more confident to do so once I've seen a complete release with all 
> the entailed bits, including this site, so that I have some semblance of 
> confidence to do it again!). All I've done is update the release notes to 
> include the changes for 2.0.9, which I'm sure some people might appreciate, 
> minor though the changes may be.
> 
> Any assistance appreciated. I've already received much assistance from Ralph 
> and Matt (thanks!).
> 
> -d

Re: [VOTE] Release Log4Net 2.0.9

[Apache]

Unfortunately the staging and release locations for the release artifacts are 
still using s not. But everything else is now in git. So in a release you 
should publish the web site to the asf-staging branch of the site repo and 
publish the artifacts to the dev location of the SVN dist repo. Once they are 
approved they can be published. You should have permission to publish the web 
site already.

I will try to verify your changes tomorrow.

Ralph

> On Sep 1, 2020, at 11:11 PM, Davyd McColl  wrote:
> 
> Hi Ralph
> 
> The missing tag is my fault -- I had a `rel/2.0.9` tag locally and obviously 
> forgot to push with tags ):
> 
> I've updated the source files for the site:
> - removed the mirror references
> - updated the links for 2.0.9
> - updated the link to point to the html instead of the cgi
> 
> I've also updated the README in the project to take out the dormant status 
> commentary.
> 
> Please review & update the live site if you're happy.
> 
> Previously, as I understand it, the point of the SVN staging area was to 
> provide built artifacts for the website. Since that's not in play any more, I 
> was wondering how that's going to happen now? Someone will have to build 
> before pushing. If you'd like, I could add the target folder that is built 
> into git so that it's just a matter of copying files.
> 
> I've also added an npm script around building the site, which checks if you 
> have maven available & builds if possible -- perhaps this makes it easier for 
> the next new person (:
> 
> -d
> 
> On 2020/09/02 05:20:50, Ralph Goers  wrote:
> I also just noticed that the git repo has no tag to represent 2.0.9. Without 
> a tag essentially there is no release.
> 
> Ralph
> 
>> On Aug 24, 2020, at 3:27 PM, Ralph Goers wrote:
>> 
>> The release isn’t done yet. The web site still reflects 2.0.8. Release 
>> announcements can’t be sent out until that is updated.
>> 
>> Ralph
>> 
>>>> On Aug 24, 2020, at 2:45 PM, Remko Popma wrote:
>>> 
>>> Well done, everyone!
>>> 
>>>> On Mon, Aug 24, 2020 at 10:43 PM Matt Sicker wrote:
>>> 
>>>> Thanks again for managing the release! I’m sure you’ve just made a lot of
>>>> developers happy. :D
>>>> 
>>>> On Mon, Aug 24, 2020 at 01:40 Davyd McColl wrote:
>>>> 
>>>>> Ok, log4net 2.0.9 is up on nuget.org (:
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks for all the help (:
>>>>> 
>>>>> 
>>>>> 
>>>>> -d
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2020/08/23 19:13:36, Matt Sicker wrote:
>>>>> 
>>>>> Yes, please go ahead and finish the release. The PMC approved this
>>>>> 
>>>>> during our release vote. :)
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sun, 23 Aug 2020 at 10:22, Apache wrote:
>>>>> 
>>>>>> 
>>>>> 
>>>>>> There can’t be. That is what the release vote was for.
>>>>> 
>>>>>> 
>>>>> 
>>>>>> Ralph
>>>>> 
>>>>>> 
>>>>> 
>>>>>>> On Aug 23, 2020, at 1:02 AM, Davyd McColl wrote:
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> Thanks Dominik
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> Are there any objections to me pushing the 2.0.9 package that had
>>>> been
>>>>> approved and uploaded to https://downloads.apache.org/logging/log4net/
>>>> to
>>>>> nuget.org?
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> -d
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>>> On August 23, 2020 09:59:02 Dominik Psenner wrote:
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> Davyd, I added you as a collaborator. This should grant you the
>>>>> privilege
>>>>> 
>>>>>>>> to manage packages. You can now submit new and update or unlist
>>>>> existing
>>>>> 
>>>>>>>> packages.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> It woul

Re: [VOTE] [log4net] Release log4net 2.0.10

[Apache]

My +1

Dominic, if you are going to vote you need to do it formally.

Ralph

> On Sep 10, 2020, at 12:57 AM, Dominik Psenner  wrote:
> 
> Knowing that those changes are intentional I am confident that the next
> release is better than the last. This is reason enough to move on. If
> something breaks we can still address those issues with another future
> release.
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
> 
>> On Thu, Sep 10, 2020, 09:20 Davyd McColl  wrote:
>> 
>> Hi Dominik
>> 
>> I have had a long look over the changes (both via the PR and locally, as I
>> contributed to help with some infra changes) and I'm happy -- there's been
>> a lot of clean-up and simplification and in addition, tests are now run
>> against all targets -- so that's a good thing. Some of these changes are
>> required to resolve issues for netstandard2.0 users who have upgraded to
>> 2.0.9. Community member NicholasNoise put in a lot of work on this.
>> 
>> If it helps, the original PR is here:
>> https://github.com/apache/logging-log4net/pull/63 -- it makes viewing
>> changes a lot simpler. Changes to a lot of the #ifdefs are updates from
>> NETSTANDARD1_3 to simply NETSTANDARD as many of the changes required for
>> netstandard2.0 are compatible. I contributed on that PR too, mainly around
>> getting build to work as expected.
>> 
>> You're welcome to use the npm-based build / test pipeline to verify: I've
>> just updated master to automatically test across all platforms when running
>> `npm test`, so it should be easy to verify that all things are functional:
>> - install node if you don't have it yet (I suggest via nvm)
>> - `npm ci`
>> - `npm test`
>> 
>> (assuming that you have all the required build targets -- there are helper
>> .ps1 scripts to get the older targets -- netcore 1.1 and netfx35)
>> 
>> -d
>> 
>> 
>> On 2020/09/10 09:03:45, Dominik Psenner  wrote:
>> Hi
>> 
>> Sorry to not have responded earlier. Time is short and the days are busy. I
>> looked at the diff and found several suspicious changes. Several hundred
>> ifdefs have been removed/replaced along with tests. Therefore I have a bad
>> feeling about those changes without further careful checking. I propose to
>> release the cve fix alone and follow up a second release as soon as someone
>> had the time to verify that the netstandard2 changes are ok.
>> 
>> Best regards
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>> them.
>> 
>>> On Thu, Sep 10, 2020, 08:48 Davyd McColl wrote:
>>> 
>>> Hi
>>> 
>>> Sorry to be a bother, but I haven't heard anything back on this apart
>> from
>>> Dominik's inquiry into netstandard 1.3 support. I'd really like to get
>> this
>>> out as:
>>> a) it contains the CVE fix that has been asked about so much
>>> b) it solves some issues affecting netstandard users
>>> 
>>> Thanks
>>> -d
>>> 
>>>> On 2020/09/06 20:51:38, Davyd McColl wrote:
>>> Hi all
>>> 
>>> I'd like to propose a vote to release 2.0.10 of log4net, with:
>>> - updated netstandard 2.0 support from community member NicholasNoise
>>> - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
>>> mechanism used there is outdated for netstandard 2.0, but the principle
>>> stands
>>> 
>>> I've created an RC release at GitHub:
>>> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and
>>> pushed updated site material to the `asf-staging` branch of the
>>> logging-log4net-site repo.
>>> 
>>> Thanks
>>> -d
>> 

Re: [log4net] cleaning up JIRA

[Apache]

It is good that you are letting others know your plans. As the only formal 
Log4Net committer you are free to do whatever works for you. Hopefully that 
won’t remain the case forever. 

Ralph

> On Sep 10, 2020, at 2:17 AM, Davyd McColl  wrote:
> 
> Hi all
> 
> I'd like to start (at some point) clearing up JIRA a bit and getting on top 
> of associated pull requests (for example, the one for a REST appender, 
> https://issues.apache.org/jira/projects/LOG4NET/issues/LOG4NET-644) and I'd 
> appreciate any guidance on the accepted methods. To clarify, if it were 
> solely up to me I'd:
> 
> 1. close out anything referring to really old versions of log4net or raised 
> over 2 years ago (eg 
> https://issues.apache.org/jira/projects/LOG4NET/issues/LOG4NET-514) with a 
> polite message to please re-submit if the problem persists
> 2. close out any wishlist items without a corresponding pull request with a 
> polite message to the effect that pull requests are welcome.
> 
> This is really simply a part of how I normally work -- reduce the noise so 
> that I can get stuff done.
> 
> -d

Re: JsonTemplateLayout is ready to be shipped!

[Apache]

It is no problem. I have been heads down trying to get something done for work. 
Should be soon though.

Ralph

> On Sep 11, 2020, at 4:40 AM, Volkan Yazıcı  wrote:
> 
> Hey Ralph! This is your friendly reminder for the pending 2.x release.
> (Apologies for the inconvenience.)
> 
>> On Thu, Aug 27, 2020 at 3:55 PM Apache  wrote:
>> 
>> No, you are not expected to do anything else. While anyone can be the
>> release manager, typically I have been doing them. They take a fair amount
>> of time so I typically start them on a weekend when I have enough time.
>> 
>> Ralph
>> 
>>> On Aug 27, 2020, at 6:14 AM, Volkan Yazıcı 
>> wrote:
>>> 
>>> Would anybody mind giving some indication on an ETA, please?
>>> Or am I expected to do anything else further?
>>> 
>>>> On Tue, Aug 25, 2020 at 1:59 PM Volkan Yazıcı 
>>>> wrote:
>>>> 
>>>> Yes, you read the subject right! I will appreciate it if people can
>> spare
>>>> some time on skimming through the change set one last time regarding
>> JTL.
>>>> 
>>>> So... When are we gonna cut the ribbon for the upcoming 2.x release?
>>>> 
>> 
>> 
>> 

Re: [log4cxx] Site / Documentation thoughts

[Apache]

Changes made to subversion will have no effect. Logging services no longer uses 
the ASF CMS.

Ralph

> On Sep 19, 2020, at 12:53 AM, Thorsten Schöning  wrote:
> 
> Guten Tag Ralph Goers,
> am Samstag, 19. September 2020 um 04:16 schrieben Sie:
> 
>> The main web site is built using JBake. Although it is Java based and still 
>> uses Maven the command to build the site is just mvn install (although it 
>> doesn’t actually do an install).  All the web pages are either Markdown or 
>> AsciiDoctor. I should also add that you don’t have to use Maven. You can 
>> always just run it from the command line although that requires installing 
>> JBake on your computer. 
> 
>> The documentation for log4cxx is already maintained in its own repo. I moved 
>> it a couple of weeks ago. It is now at 
>> https://github.com/apache/logging-log4cxx-site 
>> <https://github.com/apache/logging-log4cxx-site>.[...]
> 
> How does that interact with the still available SVN-repo? Where does one need 
> to commit changes now to update "the site"? Which is "the site" anyway, that 
> in GIT or SVN cor ...?
> 
> https://svn.apache.org/repos/infra/websites/production/logging/content/log4cxx
> 
> My current setup still builds into the SVN-repo and that's where I committed 
> last changes.
> 
> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
> 
> -- 
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
> 
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
> 
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> 
> 

Re: [VOTE] [log4net] Release 2.0.11

[Apache]

You need to close the vote thread with the results first before performing the 
final release steps.

Ralph

> On Oct 25, 2020, at 11:24 PM, Davyd McColl  wrote:
> 
> Thanks Ralph
> 
> Could you assist with getting artifacts up to downloads.apache.org? I'm going 
> to push the nupkg because people are waiting on it, and will have to set the 
> new documentation live because people will expect it, but right now, the 
> download links are broken.
> 
> Thanks
> -d
> 
> On 2020/10/25 01:21:15, Ralph Goers  wrote:
> My +1
> 
> Ralph
> 
>> On Sep 22, 2020, at 11:21 PM, Davyd McColl wrote:
>> 
>> Thanks all; I've completed the release as far as I can (Ralph, please push 
>> the relevant artifacts from 
>> https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.11 the last 
>> mile) and pushed the nuget package.
>> 
>> -d
>> 
>> On 2020/09/22 17:34:34, Matt Sicker wrote:
>> +1
>> 
>>> On Tue, Sep 22, 2020 at 04:23 Dominik Psenner wrote:
>>> 
>>> +1
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>>> 
>>> them.
>>> 
>>> 
>>> 
>>>> On Tue, Sep 22, 2020, 08:37 Davyd McColl wrote:
>>> 
>>> 
>>> 
>>>> Hi all
>>> 
>>>> 
>>> 
>>>> I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out
>>> 
>>>> the door because it fixes confusing versioning on the released binaries
>>> (in
>>> 
>>>> particular, nuget consumers)
>>> 
>>>> 
>>> 
>>>> Thanks
>>> 
>>>> -d
>>> 
>>>>> On 2020/09/20 22:33:49, Matt Sicker wrote:
>>> 
>>>> I can use whatever.
>>> 
>>>> 
>>> 
>>>>> On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
>>> 
>>>>> 
>>> 
>>>>> I don’t have google meet and I can’t use Skype since Microsoft hosed my
>>> 
>>>> authentication. I have zoom. My company uses Amazon Chime, which is
>>> fairly
>>> 
>>>> new, as part of our product offering. I’ve sent you both emails for a
>>> 
>>>> meeting using that.
>>> 
>>>>> 
>>> 
>>>>> Ralph
>>> 
>>>>> 
>>> 
>>>>>>> On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:
>>> 
>>>>>> 
>>> 
>>>>>> I sent a Google Meet invite to you.
>>> 
>>>>>> 
>>> 
>>>>>>> On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:
>>> 
>>>>>>> 
>>> 
>>>>>>> I'm happy to be available at 8am my side, if that works for everyone
>>> 
>>>> else.
>>> 
>>>>>>> It sounds like earlier would be better, but I'm doing the morning
>>> 
>>>> school
>>> 
>>>>>>> run from 7am and can't guarantee I'll be back significantly before
>>> 
>>>> 8am.
>>> 
>>>>>>> 
>>> 
>>>>>>> How to do this? I have zoom and slack on my work machine, can
>>> install
>>> 
>>>>>>> Skype if that's more convenient, can do google meet, I assume,
>>> though
>>> 
>>>>>>> haven't ever tried, so may need a bit of a crash intro.
>>> 
>>>>>>> 
>>> 
>>>>>>> If posting meeting details to the mailing list is not on, feel free
>>> to
>>> 
>>>>>>> email me directly (:
>>> 
>>>>>>> 
>>> 
>>>>>>> -d
>>> 
>>>>>>> 
>>> 
>>>>>>> 
>>> 
>>>>>>>> On September 20, 2020 20:58:29 Ralph Goers wrote:
>>> 
>>>>>>> 
>>> 
>>>>>>>> 8am in Durban South Africa is 11pm the night before in Phoenix AZ.
>>> 
>>>>>>>> However, I frequently am up until midnight so that could work.
>>> 
>>>> 5-5:30 pm is
>>> 
>>>>>>>> 7:30-8 am in Phoenix. I usually am not in front of my computer on a
>>> 
>>>> weekday
>>> 
>>>>>>>> until 8 am but on occasion I ca

Re: Log4j 2.14.0 release status

[Apache]

The public repo is most likely a group repo configured with both the release 
repo and the snapshot repo.that way by configuring Maven to use the public repo 
builds can access both releases and snapshots.  But all the snapshots only 
exist in the snapshot repo.

Ralph

> On Nov 1, 2020, at 6:08 AM, Gary Gregory  wrote:
> 
> Very odd indeed, the public (non-snapshot) repository is full of snapshots:
> 
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-core/
> 
> Gary
> 
>> On Sun, Nov 1, 2020, 00:51 Ralph Goers  wrote:
>> 
>> I started the process of preparing for the release today. The Maven site
>> build is failing because somehow a version named 2.14.0—SNAPSHOT was
>> uploaded to the Nexus Snapshot repository.  While investigating I noticed
>> that there is at least one snapshot for every past release so Nexus
>> apparently is not configured to delete snapshots after a release is
>> performed.
>> 
>> I’ve asked in Slack to have all the snapshots under logging be deleted but
>> I suspect I will need to create a Jira issue. In my experience Jira isn’t
>> especially quick about acting on these so I don’t know when I will be able
>> to proceed. Matt or Gary, if you have more karma then me for some reason
>> please see what you can do.
>> 
>> Ralph
>> 

Re: Tidying up JIRA after 2.14.0 release

[Apache]

I will take care of 1 & 2 and will check your Jira permissions. The next 
release will be 2.14.1 unless new enhancements are added.

Our general policy has been to mark issues resolved and ask users to close them 
when they verify the fix. It would be nice if Jira would automatically close 
them after some amount of time if users don’t.

Ralph

> On Nov 13, 2020, at 1:02 AM, Volkan Yazıcı  wrote:
> 
> Hello,
> 
> I have a couple of questions and requests regarding the JIRA board:
> 
>   1. 2.14.0 appears to be not released yet, would anybody mind marking it
>   as released, please? (I couldn't pull it out myself. I am not sure if it is
>   due to my insufficient JIRA experience or privileges.)
>   2. Would you also create the 2.15.0 release, please?
>   3. Some issues are marked as RESOLVED and some as CLOSED. Do we have a
>   certain preference? Shall I close all resolved issues?
> 
> Kind regards.

Re: unable to build from source

[Apache]

I was just about to ask what platform you were building on. I can run other 
operating systems in a VM to try to duplicate the problem. Aloso, in this case 
knowing what your default locale is would probably help.

Ralph

> On Dec 9, 2020, at 12:17 AM, Joseph Tsai  wrote:
> 
> 
> I have been trying to figure out why I'm failing the assertion test
> 
> 
> So far from looking at LocalizedMessage.java
> 
> I think $locale is always null and therefore $bundle is always null, and this 
> sets $msgPattern to $myKey which $myKey is just "hello_world". And eventually 
> the getFormattedMessage() would just chain return $formattedMessage.
> 
> But in ParameterizedMessage.java, $formattedMessage is set to be $buffer's 
> content
> 
> 
> And $buffer would get its content from $messagePattern in 
> ParameterFormatter.java, which is just "hello_world"
> 
> 
> So I'm getting the fix would be to have $locale != null with some default 
> value when passed in to getResourceBundle()? I don't know, I could be way 
> wrong on my whole analysis and the problem is not actually related to what I 
> think it is at all.
> 
> 
>> On Wed, 9 Dec 2020 at 03:37, Ralph Goers  wrote:
>> You are making progress! I saw those same errors in one of our automated 
>> builds the other day. I am not sure what the problem is but haven’t looked 
>> into it yet.
>> 
>> Ralph
>> 
>> > On Dec 8, 2020, at 9:23 AM, Joseph Tsai  wrote:
>> > 
>> > I kinda inferred that from reading the mvnw script when Volkan directed me 
>> > to run command. So I exported JAVA_HOME=[path/to/my/Java8] into my .bashrc 
>> > and I'm not failing the same thing anymore.
>> > 
>> > But I'm still getting errors, this time it is failing some unit tests from 
>> > the surefire plugin. I tried to fix it but I couldn't.
>> > 
>> > 
>> > 
>> > From reading some 
>> > <https://stackoverflow.com/questions/36427868/failed-to-execute-goal-org-apache-maven-pluginsmaven-surefire-plugin2-12test/55835974>
>> >  StackOverflow 
>> > <https://stackoverflow.com/questions/46831762/maven-build-and-maven-failsafe-plugin-the-forked-vm-terminated-without-properl>
>> >  posts, it seems to have something to do with the surefire plugin version 
>> > number? I tried to downgrade it to some lower versions but it didn't work.
>> > 
>> > I have also attached a zip of the surefire reports.
>> > 
>> > Thanks,
>> > 
>> > 
>> > On Wed, 9 Dec 2020 at 02:37, Matt Sicker > > <mailto:boa...@gmail.com>> wrote:
>> > The full build isn't compatible with Java 11 yet, so you need both 8 and 11
>> > configured in a toolchains.xml config. Then you need to use Java 8 as the
>> > default JVM (or at least the contents of JAVA_HOME), and the build will
>> > switch to higher version compilers for the modules that require it.
>> > Ideally, the build would be updated to simplify this, but it's a fairly
>> > difficult problem as it's still a relatively new area in Maven with
>> > multiple alternatives to how to support it.
>> > 
>> > On Tue, 8 Dec 2020 at 08:13, Volkan Yazıcı > > <mailto:volkan.yaz...@gmail.com>> wrote:
>> > 
>> > > Would you mind changing the default JDK you start *mvnw* to version 8 and
>> > > retrying via *./mvnw clean package -DskipTests*, please? (Here *clean*
>> > > goal is necessary for removing the class files compiled earlier with the
>> > > wrong JDK.)
>> > > [Sorry for the short answer, struggling with my day-job in the meantime.]
>> > >
>> > > On Tue, Dec 8, 2020 at 3:02 PM Joseph Tsai > > > <mailto:jtsa0...@gmail.com>> wrote:
>> > >
>> > >> Hi Volkan,
>> > >>
>> > >> I just installed both JDK8 and 11 and tried to do mvn clean install. The
>> > >> same error persists, and I think it's looking at my default Java
>> > >> installation?
>> > >> Running "sudo update-alternatives --config java" shows the following:
>> > >> [image: image.png]
>> > >> Currently it is defaulted to Java15, and everytime I change the default
>> > >> Java the wrong version circled in blue changes.
>> > >> [image: image.png]
>> > >> I also looked up what version 53 is, it is apparently Java9?
>> > >>
>> > >> My questions are:
>> > >>
>> > >> 

Re: Another JsonTemplateLayout question on StackOverflow....

[Apache]

I just go periodically and search for “Log4j2” newest.


Ralph

> On Mar 31, 2021, at 4:32 AM, Volkan Yazıcı  wrote:
> 
> Thanks! Replied.
> 
> Ralph, how do you track SO questions? I am watching log4j and log4j2 tags,
> though I don't see any notifications. In particular, I was expecting to get
> notified by e-mail.
> 
>> On Wed, Mar 31, 2021 at 7:27 AM Ralph Goers 
>> wrote:
>> 
>> 
>> https://stackoverflow.com/questions/66832654/how-to-set-jsontemplatelayout-eventtemplateuri-outside-of-classpath-in-log4j2
>> 
>> Ralph
>> 

Re: Please do not commit to log4j2 master - but review this PR.

[Apache]

Actually, they don’t disappear. They just move to closed status. I believe you 
can still comment but it is far less noticeable after it is merged. Really, I 
suggest you check out the branch and build it. I really didn’t change much 
code. I mostly moved it around and changed whatever was needed to make 
log4j-api and Log4J-plugins real JPMS modules in Java 11.

Ralph

> On Mar 31, 2021, at 11:57 PM, Volkan Yazıcı  wrote:
> 
> I am still reviewing it.
> As Matt noted, you can merge it.
> This said, I'd appreciate an extra week.
> It is easier to discuss changes over GitHub PR.
> Once committed, PR will disappear.
> 
>> On Thu, Apr 1, 2021 at 5:58 AM Ralph Goers 
>> wrote:
>> 
>> FYI - I plan on merging this code Friday morning MST unless my schedule
>> changes between now and then.
>> 
>> Ralph
>> 
>>> On Mar 29, 2021, at 3:58 PM, Ralph Goers 
>> wrote:
>>> 
>>> I should have added that you may need a recent version of the JDK. I
>> forget what error I was encountering but upgrading the JDK to a later
>> version fixed it. But then I noticed that the Google java allocation
>> instrumenter wasn’t working and it had to be upgraded too.
>>> 
>>> Ralph
>>> 
>>>> On Mar 29, 2021, at 3:51 PM, Matt Sicker  wrote:
>>>> 
>>>> I’ll make sure to look more closely at it this week. Nice work on
>>>> simplifying the modules a bit!
>>>> 
>>>> On Sun, Mar 28, 2021 at 18:24 Ralph Goers 
>>>> wrote:
>>>> 
>>>>> I have created https://github.com/apache/logging-log4j2/pull/480 for
>> you
>>>>> to review. It has many changes and merge conflicts will be painful to
>> fix
>>>>> so please do not commit to master until this PR is merged.
>>>>> 
>>>>> Although I could merge this now I would prefer if you could checkout
>> the
>>>>> branch on your local machines, build, and test it. I haven’t tested it
>> with
>>>>> anything real yet but all the unit tests - except for the osgi module -
>>>>> pass.
>>>>> 
>>>>> If you open this in your IDE you might have some issues with some test
>>>>> classes being flagged as having compile issues. This is because of the
>>>>> weird extra directory I had to include in log4j-api and log4j-plugins
>> to
>>>>> create test jars.
>>>>> 
>>>>> Please provide feedback so I can make any changes and get this merged.
>>>>> 
>>>>> Ralph
>>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 

Re: Review request: LOG4J2-3004 JsonTemplateLayout plugin support

[Apache]

Yeah, sorry for not getting to that. I will still look at it though.

Ralph

> On Apr 3, 2021, at 3:19 AM, Volkan Yazıcı  wrote:
> 
> Ralph, I know you are pretty busy with the Java 11 migration on master.
> I will merge this branch onto release-2.x and then cherry-pick into master.
> I need to get this in, so that I can continue working on other JTL tickets.
> 
>> On Mon, Mar 22, 2021 at 9:54 PM Ralph Goers 
>> wrote:
>> 
>> I will try to get to it this evening.
>> 
>> Ralph
>> 
>>> On Mar 22, 2021, at 1:26 PM, Volkan Yazıcı 
>> wrote:
>>> 
>>> Hello,
>>> 
>>> I have created a GitHub PR (#476)
>>> <https://github.com/apache/logging-log4j2/pull/476> addressing
>> LOG4J2-3004
>>> JsonTemplateLayout plugin support
>>> <https://issues.apache.org/jira/browse/LOG4J2-3004>. I needed to make a
>>> small (backward-compatible) change to TypeConverterRegistry and I have
>> some
>>> troubles with AsciiDoc. These and more are mentioned in the description
>> of
>>> the PR. I will appreciate it a lot if somebody could review the changes.
>>> 
>>> Cheers!
>> 
>> 
>> 

Re: Switching Spring Boot from Logback to Log4j

[Apache]

Yes, I saw the update when I woke up in the middle of the night. We use Spring 
a lot at Nextiva so making the two interoperate nicely is important to me.

Ralph

> On Apr 6, 2021, at 6:23 AM, Volkan Yazıcı  wrote:
> 
> For those who don't know yet, Spring Boot considers switching from Logback
> to Log4j .
> Ralph is performing a great lobbying example there. Recently the ticket has
> been updated with the following feature checks I have attached below.
> Spring Boot will make a great customer for many perspectives of the Log4j
> project; visibility, improvements, stability, etc. I am personally really
> excited about this development and watching it closely. I wanted to share
> these news with the rest of you.
> 
> -- Forwarded message -
> From: Andy Wilkinson 
> Date: Tue, Apr 6, 2021 at 10:42 AM
> Subject: Re: [spring-projects/spring-boot] Investigate impact of switching
> default logging system to log4j2 (#22149)
> To: spring-projects/spring-boot 
> Cc: Volkan Yazıcı , Manual <
> man...@noreply.github.com>
> 
> 
> @rgoers  Thank you.
> 
> One area that's just come up is providing log4j2-based support for the
> 
> 
> and the 
> 
> elements that we currently support with Logback.
> 
>  is rather like a lookup and is quite similar to the
> existing Spring Boot lookup.  doesn't have a dependency on
> Spring Cloud whereas it appears the Log4j2's Spring Boot lookup does?
> 
>  provides some basic conditional configuration support,
> allowing configuration to be applied based on the Spring profiles that are
> active. From what I've seen, there isn't something similar in Log4j2 at the
> moment.
> 
> Spring Boot 3 is by no means imminent (it won't be in 2021) so there's no
> urgency here at the moment, but it would be interesting to explore what
> plugging  and  support into Log4j2 might
> look like.
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .

Re: [logging-pipelines] branch master updated: Use Java 11 for master branch

[Apache]

Can we not require a Jenkinsfile in each project that sets properties to 
control the behavior?

Ralph

> On Apr 6, 2021, at 6:45 AM, Matt Sicker  wrote:
> 
> Oops, good point. I need to make the version selection a little more
> sophisticated. Probably a branch or something for the shared lib.
> 
>> On Tue, Apr 6, 2021 at 01:56 Ralph Goers  wrote:
>> 
>> I took care of the failure on verify. I added a clean to log4j-api so it
>> will clean every time.
>> 
>> Ralph
>> 
>>> On Apr 5, 2021, at 10:55 PM, Ralph Goers 
>> wrote:
>>> 
>>> Matt,
>>> 
>>> A couple of comments
>>> This doesn’t seem right. Log4j-audit, Kotlin, and Chainsaw all use the
>> mvn command. This will modify them to use Java 11 instead of Java 8. Did we
>> really want to do that?
>>> The Jenkins build is still failing. The first phase that compiles works
>> but the second phase that runs the unit test bails because it tries to
>> recompile everything without doing a clean first. That means it will find
>> the module-info class when it tries to compile Activator and that will fail
>> because org.osgi.core is not in the module-info. It can’t be since OSGi
>> isn’t JPMS compatible - which is another reason why the code had to be
>> compiled separately from the module-info.java file. I’m really curious -
>> why do you run mvn twice and just not skip tests the first time?
>>> 
>>> Ralph
>>> 
 On Apr 5, 2021, at 2:18 PM, mattsic...@apache.org wrote:
 
 This is an automated email from the ASF dual-hosted git repository.
 
 mattsicker pushed a commit to branch master
 in repository https://gitbox.apache.org/repos/asf/logging-pipelines.git
 
 
 The following commit(s) were added to refs/heads/master by this push:
   new 10333f7  Use Java 11 for master branch
 10333f7 is described below
 
 commit 10333f76c589fa45e80db878895ad19cfcaba11c
 Author: Matt Sicker 
 AuthorDate: Mon Apr 5 16:18:13 2021 -0500
 
  Use Java 11 for master branch
 ---
 vars/mvn.groovy | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)
 
 diff --git a/vars/mvn.groovy b/vars/mvn.groovy
 index bf15449..647a15f 100644
 --- a/vars/mvn.groovy
 +++ b/vars/mvn.groovy
 @@ -17,10 +17,11 @@
 
 def call(String args) {
   if (isUnix()) {
 +String javaHome =
>> "/home/jenkins/tools/java/latest${BRANCH_NAME == 'master' ? '11' : '1.8'}"
   configFileProvider([configFile(fileId: 'ubuntu', variable:
>> 'TOOLCHAINS')]) {
   withEnv([
 -'JAVA_HOME=/home/jenkins/tools/java/latest1.8',
 -
>> 'PATH+MAVEN=/home/jenkins/tools/maven/latest3/bin:/home/jenkins/tools/java/latest1.8/bin'
 +"JAVA_HOME=${javaHome}",
 +
>> "PATH+MAVEN=/home/jenkins/tools/maven/latest3/bin:${javaHome}/bin"
   ]) {
   // note that the jenkins system property is set here to
>> activate certain pom properties in
   // some log4j modules that compile against system jars
>> (e.g., log4j-jmx-gui)
 @@ -28,10 +29,11 @@ def call(String args) {
   }
   }
   } else {
 +String javaHome =
>> "f:\\jenkins\\tools\\java\\latest${BRANCH_NAME == 'master' ? '11' : '1.8'}"
   configFileProvider([configFile(fileId: 'windows', variable:
>> 'TOOLCHAINS')]) {
   withEnv([
 -'JAVA_HOME=f:\\jenkins\\tools\\java\\latest1.8',
 -
>> 'PATH+MAVEN=f:\\jenkins\\tools\\maven\\latest3\\bin;f:\\jenkins\\tools\\java\\latest1.8\\bin'
 +"JAVA_HOME=${javaHome}",
 +
>> "PATH+MAVEN=f:\\jenkins\\tools\\maven\\latest3\\bin;${javaHome}\\bin"
   ]) {
   bat "mvn --toolchains \"%TOOLCHAINS%\" ${args}"
   }
 
>>> 
>> 
>> 
>> 

Re: Running "master" tests in IntelliJ IDEA after Java 11 upgrade

[Apache]

I will be honest. I have never tun any log4j tests in IntelliJ. I rarely do it 
for any projects I work on. I use JVM remote debug all the time. I don’t want 
to force others to have to do that, but I just never think about it. 

I use various versions of Maven from time to time. 3.6.1 is the default on my 
Mac but I just installed 3.8.1 to validate what I needed to change in my setup 
to make it still work with my employers Nexus repository which still uses http.

When I am working on Log4J stuff I do a full mvn clean install several times a 
day. That takes a huge amount of time so I have learned to multitask and work 
on other stuff while builds are running.

Ralph.

> On Apr 7, 2021, at 12:15 AM, Volkan Yazıcı  wrote:
> 
> Ralph, when you delete the IDEA-specific configuration (i.e., *.iml files
> and .idea directory), compile the sources via Maven, and open the folder in
> IDEA, can you run *any* tests? If so, do you have any custom IDEA
> configurations? Which IDEA version are you using? If you are not using the
> wrapper, which Maven version are you using?
> 
> I use Maven Wrapper to make sure Maven behaves the same in all
> environments, independent of my local setup. It also saves you from a local
> Maven dependency.
> 
>> On Wed, Apr 7, 2021 at 1:17 AM Ralph Goers 
>> wrote:
>> 
>> I deleted the files from my local repo and restarted the build. It is
>> running along just fine - at least until it hits json template layout.
>> 
>> Is there a reason you use the maven wrapper instead of Maven itself? I
>> have never used the wrapper. I am wondering if there is something going on
>> there.
>> 
>> Ralph
>> 
>>> On Apr 6, 2021, at 4:10 PM, Ralph Goers 
>> wrote:
>>> 
>>> I’ve never seen that. What is maven-annotations-production:log4j-api?
>>> 
>>> Let me try removing the files from my maven local repo as you did.
>>> 
>>> Ralph
>>> 
>>>> On Apr 6, 2021, at 1:14 PM, Volkan Yazıcı 
>> wrote:
>>>> 
>>>> As subject hints, I am not able to run tests in IDEA anymore after Java
>> 11
>>>> upgrade. I have deleted all IDEA related files and issued a clean Maven
>>>> build:
>>>> 
>>>> $ rm -rf ./.idea ./**/*.iml
>>>> $ rm -rf ~/.m2/repository/org/apache/logging/log4j/*/3*-SNAPSHOT
>>>> $ ./mvnw clean install -DskipTests=true
>>>> 
>>>> Opened the directory using IDEA (2021.1 RC), but couldn't get it to have
>>>> successful build:
>>>> 
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-core/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-plugins/target/generated-test-sources/test-annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-layout-template-json/target/generated-test-sources/test-annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-plugins/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-layout-template-json/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-layout-jackson-json/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-core/target/generated-test-sources/test-annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> 
>>>> *E: Cannot build maven-annotations-production:log4j-api because it is
>>>> included into a circular dependency (module 'log4j-api' production,
>>>> maven-annotations-production:log4j-api, module 'log4j-plugins'
>> production,
>>>> maven-annotations-production:log4j-plugins)E: Cannot build
>>>> maven-annotations-test:log4j-plugins because it is included into a
>> circular
>>>> dependency (maven-annotations-test:log4j-plugins, module 'log4j-api'
>> tests,
>>>> maven-annotations-test:log4j-api, module 'log4j-plugins' tests)*
>>>> 
>>>> Did you get it working? What shall I do to make it work?
>>> 
>>> 
>>> 
>> 
>> 
>> 

Re: Log levels on a schedule

[Apache]

That would be exactly right. I would create a TimeFilter that is very much like 
the DynamicThresholdFilter but instead of using an MDC key it woul use a time 
frame. 

This would be interesting as it could be implemented to either check the time 
in the event for every request or it could create a background thread that 
changes the log level to filter on based on the times. I’d probably opt for the 
second approach.

Ralph

> On May 3, 2021, at 5:33 AM, Gary Gregory  wrote:
> 
> I just had an interesting request: Debug logging produces a ton of output
> and what is being debugged only happens in a specific time window. How can
> we configure debug logging to enable in a time window...?
> 
> Any thoughts on this? Can a TimeFilter be configured to only filter debug
> events?
> 
> Gary

Re: Log4Go

[Apache]

Sorry Christopher. I am traveling on vacation and finding it difficult to do 
anything really useful this week.

Ralph

> On Jul 9, 2021, at 3:29 AM, Christofer Dutz  wrote:
> 
> Ok ...
> 
> so I'm signing off ... guess I'll go the route of adding a sub-project 
> in PLC4X to provide the things I need.
> 
> Chris
> 
> 
>> On 08.07.21 11:46, Christofer Dutz wrote:
>> (Re sending as I noticed my first message went to only Davyd and not the
>> list)
>> 
>> Hi Davyd,
>> 
>> I was talking about a document in Confluence ... not a git repo.
>> And I guess I can help with all the getting started, once we've decided
>> on a plan.
>> 
>> Chris
>> 
>>> On 07.07.21 09:52, Davyd McColl wrote:
>>> Hi Ralph
>>> 
>>> I can't create a repo under the apache org on GitHub. I'm also perhaps not 
>>> the best person to start off the project - I'm still very new to Go, having 
>>> only worked a bit in it - learned enough to have had two PRs accepted to 
>>> lazygit (https://github.com/jesseduffield/lazygit) and I'm not sure of the 
>>> generally-accepted defaults / layout / structures for go projects. When I 
>>> raised my paw, it was largely because I'd like to learn from people who do 
>>> have this kind of experience (: I've found that working on lazygit has made 
>>> me learn more than following a course, not in the least because there's 
>>> existing code and structure there and people to tell me when I Do It Wrong 
>>> :D
>>> 
>>> I'm still very happy to be involved in log4go (assuming it's called that).
>>> 
>>> -d
>>>> On 2021/07/01 17:23:40, Ralph Goers  wrote:
>>> Davyd,
>>> 
>>> You have commit rights but I am not sure if that gives you the ability to 
>>> create a new repo. But before doing that I would create a confluence page 
>>> to lay out the initial requirements and design.
>>> 
>>> If you can’t create a repo and would like one I can certainly help with 
>>> that.
>>> 
>>> Ralph
>>> 
>>>> On Jun 30, 2021, at 12:44 PM, Davyd McColl wrote:
>>>> 
>>>> I'm rather new to go, but looking for ways to improve by writing code 
>>>> alongside people who actually know what they're doing. If I can help, 
>>>> please ping me.
>>>> 
>>>> -d
>>>> 
>>>> 
>>>> On June 30, 2021 18:12:46 Christofer Dutz wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> and sorry for being late to the party ;-)
>>>>> 
>>>>> I am currently working hard on PLC4X' Go support and am also using what I 
>>>>> create in the Open-Source project in some larger corporate applications.
>>>>> 
>>>>> One thing that has always bugged me with go, was the inavailability of 
>>>>> loggers that allow me to set different log levels for different parts of 
>>>>> the application. In go with every half-efficient logging framework, it's 
>>>>> an all or nothing thing. So if I want to track down a problem in my 
>>>>> driver for protocol X and I switch logging to TRACE it's like trying to 
>>>>> drink out of an open fire-hose.
>>>>> 
>>>>> What I would love to do as a first step, and I don't think it should be 
>>>>> too complicated, would be to create a Go API that allows us to define 
>>>>> hierarchies of log levels, just like we know them in the Java world. This 
>>>>> API would be used in the application to log, but it wouldn't actually do 
>>>>> any logging but internally sort of use an underlying framework (possibly 
>>>>> auto configured to TRACE or the most talkative log level) and forward log 
>>>>> requests to that if it passes the filter criteria.
>>>>> 
>>>>> So in PLC4Go for example we could use this Go Logging API. If my company 
>>>>> now uses logrus or zerolog, then all we have to do in that application is 
>>>>> initialize the log4go system (I know there's a project using that name 
>>>>> pattern ... I'm referring to something we built) with the corresponding 
>>>>> adapter.
>>>>> 
>>>>> What do you think? I'm not one of these "I whish someone would build X 
>>>>> for me" folks ... I am willing to put quite some e

Re: Json Template Layout event delimiter

[Apache]

I don’t think anyone passing an escape sequence expects it to show up as a 
string. So I would be good with your proposed solution. That method should be 
part of core so we can modify all Layouts to use it.

Ralph

> On Sep 13, 2021, at 12:29 AM, Volkan Yazıcı  wrote:
> 
> I had addressed this issue in 2020 July in a post titled "String parameter
> with escapes (Was: Testing Json Template Layout)"
> .
> For one, *the issue is not specific to JTL*, but applies to almost every
> layout accepting a parameter to be emitted along with the normal output.
> Back then, the discussion focused on the null (\0) character needed by
> SocketAppender for GELF layout in JTL. In the post, I suggested adding
> something similar to `translateEscapes()` of Java 13. This would allow
> users to pass escape characters with any string literal in any
> configuration format; XML, YAML, properties, etc. Contrasting this with
> your proposal for treating certain special inputs (e.g., "null", "Form
> Feed") differently, for me, is not different than implementing a
> `translateEscapes()`. I personally think this is even worse, since we
> introduce a new syntax, whereas the former sticks to the standard Java
> string syntax.
> 
> In conclusion, I propose adding a `translateEscapes()` clone and using that
> to read `eventDelimiter` and deprecating `nullEventDelimiterEnabled`, since
> `nullEventDelimiterEnabled` will simply translate to setting
> `eventDelimiter` to `\0`. This breaks the backward compatibility of
> `eventDelimiter`, since there might be users out there who set their
> `eventDelimiter` to `\t\r\n` and was expecting to get that string literal
> as is. Yet, given the relatively recent introduction of the plugin, I think
> we can take this risk.
> 
>> On Mon, Sep 13, 2021 at 6:14 AM Ralph Goers 
>> wrote:
>> 
>> I have been working on getting a configuration that works with filebeat
>> going again and have been
>> trying to change the line delimiter so I could avoid doing the multiline
>> crap. I first configured
>> eventDelimiter=“\f” since filebeat supports that as a replacement for
>> newline. Except no matter
>> how hard I tried I couldn’t get filebeat to log anything to stdout.
>> 
>> I spent hours looking at it before I finally realized that the logs being
>> written actually had “\f” in
>> the string instead of a form feed character. It seems that XML must be
>> passing in the value
>> treating the “\” as if it is escaped.  To remedy this the only solution I
>> could come up with was
>> 
>> > locationInfoEnabled="true">
>>  …
>> 
>> It seems that XML doesn’t allow a form feed character specified that way.
>> This caused filebeat
>> to start recognizing the log events.  I would suggest that we may want to
>> change eventDelimiter
>> to accept enum names instead of or in addition to characters, which is
>> what filebeat does. So
>> one could specify eventDelimiter=“Form Feed”.
>> 
>> Ralph

Re: broken Log4j2Plugins.dat in the shaded benchmarks.jar of log4j-perf

[Apache]

We could include it in Log4J. Does master work out of the box?

Ralph

> On Oct 13, 2021, at 12:23 AM, Volkan Yazıcı  wrote:
> 
> 
> I have done something really nasty in the release-2.x branch to fix 
> benchmarks.jar generated by log4j-perf. Since a picture is worth a thousand 
> words, I am sharing two:
> 
> 
> 
> (In case images get truncated, see commit 4049240c.)
> 
> In a nutshell, Log4j2Plugins.dat of the shaded benchmarks.jar doesn't contain 
> log4j-layout-template-json plugins due to overrides taking place during 
> shading. This problem rendered the JsonTemplateLayout benchmarks broken after 
> JTLs migration to plugins. Using a 3rd party Maven plugin circumventing a 
> Log4j bug in the Log4j project itself felt pretty unpleasant to me. Is there 
> any other way I could have solved this?

Re: maven-shaded-log4j-transformer

[Apache]

Question: Do we want it as a sub-module or as a new git repo with its own 
release?

Ralph

> On Oct 15, 2021, at 6:50 AM, Eduard Gizatullin  wrote:
> 
> Hello dear log4j team
> 
> Volkan Yazıcı asked me to make  maven-shaded-log4j-transformer
> <https://github.com/edwgiz/maven-shaded-log4j-transformer> a part of
> log4j2  and I tend to accomplish the proposal.
> 
> Can you please confirm that
> new sub-module name  log4j-maven-shade-plugin is ok
> 
> Any preliminary advice will be appreciated
> 
> 
> --
> Best regards,
> Ed
> 
> 
>> On Fri, Oct 15, 2021 at 1:39 PM Volkan Yazıcı  wrote:
>> 
>> Thanks for the prompt (and positive!) reply Eduard!
>> I think it is best to first lay out the details of the plan in a post to the
>> dev mailing list <https://logging.apache.org/log4j/2.x/mail-lists.html>.
>> For instance, the module name, transformer name, documentation changes,
>> etc.
>> This will give others an opportunity to share their feedback and remarks.
>> Then simply create a JIRA <https://issues.apache.org/jira/projects/LOG4J2>
>> ticket and submit a GitHub <https://github.com/apache/logging-log4j2> PR.
>> 
>> `master` branch targets Log4j 3, which is not released yet.
>> It uses a different plugin loading mechanism than the one used in Log4j 2.
>> Log4j 3 doesn't suffer from this "override of plugins after shading"
>> problem.
>> Hence, the PR needs to target the `release-2.x` branch.
>> 
>> Also note that since this is a non-trivial contribution, you need to sign the
>> ICLA document <https://www.apache.org/licenses/icla.pdf> and email it to
>> the ASF .
>> Once you have done this, it is good to mention this in the dev mailing
>> list.
>> 
>> On Fri, Oct 15, 2021 at 12:26 PM Eduard Gizatullin 
>> wrote:
>> 
>>> Hello Volkan,
>>> 
>>> Thank you for letting me know, I'm all for it.
>>> 
>>> Couldn't you please confirm that target branch is master
>>> and log4j-maven-plugins is ok as new name of submodule
>>> 
>>> Any other advices will be appreciated,
>>> 
>>> --
>>> Best regards,
>>> Ed
>>> 
>>> 
>>>> On Fri, Oct 15, 2021 at 10:10 AM Volkan Yazıcı  wrote:
>>> 
>>>> Hello,
>>>> 
>>>> My name is Volkan Yazici and I am a PMC committee member of the ASF
>>>> Logging Services, which develops Log4j too.
>>>> maven-shaded-log4j-transformer
>>>> <https://github.com/edwgiz/maven-shaded-log4j-transformer> plugin
>>>> addresses an important shortcoming of the Log4j 2.x plugin design surfacing
>>>> when users want to shade it. We have recently had a chat about it in
>>>> the mailing list
>>>> <https://lists.apache.org/thread.html/rcfa4fc8678642a51e3a69dd2b14848fe4e1e5b71de7c99a7b55ff182%40%3Cdev.logging.apache.org%3E>,
>>>> and the maintainers (incl. me) are inclined to ship it as a part of the
>>>> Log4j project. Would you like to contribute it yourself in the form of a
>>>> GitHub PR? Note that this route is subject to update-push-review cycles,
>>>> yet they are pretty rewarding for both parties, IMHO. What do you think?
>>>> 
>>>> Kind regards.
>>>> 
>>> 

Re: Setting up gh-pages (Was: Continuous performance test bed using GitHub Actions)

[Apache]

What new plug-in?

Ralph

> On Oct 18, 2021, at 12:32 PM, Matt Sicker  wrote:
> 
> Testing the website publishing from the new plugin. It’s probably easier to 
> keep it under the ASF pages thing than it is to combine it with GH pages. 
> Since it’s storing generated markup in a git repo, it doesn’t matter much 
> which system it’s using besides whatever integration we already have set up.
> 
> Matt Sicker
> 
>> On Oct 18, 2021, at 14:16, Ralph Goers  wrote:
>> 
>> I feel like I am going in circles.
>> 
>> Testing of what? I still don’t understand what the use case is for GitHub 
>> Pages. What problem is it solving?
>> 
>> Ralph
>> 
>>>> On Oct 18, 2021, at 12:05 PM, Matt Sicker  wrote:
>>> 
>>> I’d imagine it’s for testing purposes initially. We should integrate it 
>>> into the main domain when it’s ready for release. This should all be 
>>> controllable via the .asf.yaml file.
>>> 
>>> Matt Sicker
>>> 
>>>>> On Oct 18, 2021, at 12:32, Ralph Goers  wrote:
>>>> 
>>>> Why?
>>>> 
>>>> Ralph
>>>> 
>>>>> On Oct 18, 2021, at 8:40 AM, Volkan Yazıcı  wrote:
>>>>> 
>>>>> For the moment, I just want the `gh-pages` branch of the logging-log4j2
>>>>> GitHub project to be accessible at "a" URL – just like any other non-ASF
>>>>> GitHub project.
>>>>> 
>>>>>> On Mon, Oct 18, 2021 at 5:38 PM Ralph Goers 
>>>>>> wrote:
>>>>>> 
>>>>>> OK. That page didn’t exist when I migrated the site from the CMS. That
>>>>>> still leaves
>>>>>> the second question. What are you proposing? I don’t really see the point
>>>>>> of moving
>>>>>> the existing site to GitHub Pages.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Oct 18, 2021, at 8:31 AM, Volkan Yazıcı  wrote:
>>>>>>> 
>>>>>>> GitHub Pages look pretty doable to me:
>>>>>>> https://cwiki.apache.org/confluence/display/INFRA/GitHub+Pages
>>>>>>> 
>>>>>>> On Fri, Oct 15, 2021 at 6:35 PM Ralph Goers 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I don’t really understand this. When I was migrating the web site from
>>>>>> the
>>>>>>>> ASF CMS to GitHub
>>>>>>>> it was made clear that web site hosting using GitHub Pages wasn’t
>>>>>>>> supported. I am not sure
>>>>>>>> what the proposal here is.
>>>>>>>> 
>>>>>>>> Ralph
>>>>>>>> 
>>>>>>>>> On Oct 15, 2021, at 8:27 AM, Matt Sicker  wrote:
>>>>>>>>> 
>>>>>>>>> I’m not exactly sure how we can get a beta subdomain, though the
>>>>>> staging
>>>>>>>> one is built in. And while it would be great to automate as much as
>>>>>>>> possible about the release process in GHA, the code signing aspect is
>>>>>> still
>>>>>>>> not possible (though we might be able to integrate with another service
>>>>>> at
>>>>>>>> Apache for that, but it doesn’t cover the GPG signature). There’s also
>>>>>> some
>>>>>>>> ASF rule I think about releases needing to be done by a human, but that
>>>>>>>> might be more about reproducible builds.
>>>>>>>>> 
>>>>>>>>> Matt Sicker
>>>>>>>>> 
>>>>>>>>>> On Oct 15, 2021, at 05:57, Volkan Yazıcı  wrote:
>>>>>>>>>> 
>>>>>>>>>> I long had the ambition to move the entire site & manual to 
>>>>>>>>>> gh-pages.
>>>>>>>>>> In an ideal world, I would even move the release process to GitHub
>>>>>>>> Actions
>>>>>>>>>> too.
>>>>>>>>>> But these are, for now, pretty ambitious goals.
>>>>>>>>>> What I would really appreciate is to access gh-pages content via, 
>>>>>>>>>> say,
>>>>>>>>>> https://beta.logging.apache.org/log4j URL.
>>>>>>>>>> Matt, mind helping me with setting this up please?
>>>>>>>>>> 
>>>>>>>>>>> On Wed, Oct 13, 2021 at 7:12 PM Matt Sicker 
>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> That's really cool! Do note that we can publish to the ASF-specific
>>>>>>>>>>> branches, too, for hosting a site.
>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Oct 13, 2021 at 10:37 AM Volkan Yazıcı 
>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Do this:
>>>>>>>>>>>> 
>>>>>>>>>>>> git fetch -p
>>>>>>>>>>>> git checkout -B gh-pages origin/gh-pages
>>>>>>>>>>>> python -m http.server
>>>>>>>>>>>> open http://localhost:8000/benchmark/results/index.html
>>>>>>>>>>>> 
>>>>>>>>>>>> *The magic:*
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>> https://github.com/apache/logging-log4j2/blob/release-2.x/.github/workflows/benchmark.yml
>>>>>>>>>>>> 
>>>>>>>>>>>> *Disadvantages:* Runner specs are on the flux, though mostly pretty
>>>>>>>>>>> stable.
>>>>>>>>>>>> 
>>>>>>>>>>>> *Future work:*
>>>>>>>>>>>> 
>>>>>>>>>>>> - Enable GitHub pages for the project?
>>>>>>>>>>>> - Incorporate more from log4j-perf to here.
>>>>>>>>>>>> - Put the workflow onto a cron schedule.
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 

Re: Setting up gh-pages (Was: Continuous performance test bed using GitHub Actions)

[Apache]

Volkan,

I am not in front of my computer at the moment, but I am 100% sure you are 
incorrect. Every logging project has its own GitHub repo for its own web site. 
The thought of having log4cxx and Log4Net use a repo with Log4J in the name 
doesn’t make any sense.

Publishing a web site involves committing the changes to the asf-staging 
branch, reviewing those changes, and then merging the staging branch to the 
live branch. 

I just don’t see what advantages using GitHub pages provides over this as your 
points below seem like they are already covered.

Ralph

> On Oct 19, 2021, at 1:14 AM, Volkan Yazıcı  wrote:
> 
> In its current state, all Logging Services projects (log4j, log4jcxx,
> log4net, etc.) dump their websites to a single repository:
> https://github.com/apache/logging-log4j-site If I need to publish
> continuous benchmark results of logging-log4j2 repository, I need to push
> my changes to two other branches of another repository. What I was asking
> for is if we can publish a website to a logging-log4j2 repository branch
> such that it will be displayed under a logging.apache.org subdomain. This
> approach would provide the following advantages:
> 
>   - Every repository will contain its own website. (I guess, we can all
>   agree this is a good thing to have.)
>   - CI (in particular, benchmark) scripts won't need to hack their way
>   around multi-repo setups.
>   - No disruption to the current logging.apache.org flow.
> 
> 
>> On Mon, Oct 18, 2021 at 9:16 PM Ralph Goers 
>> wrote:
>> 
>> I feel like I am going in circles.
>> 
>> Testing of what? I still don’t understand what the use case is for GitHub
>> Pages. What problem is it solving?
>> 
>> Ralph
>> 
>>>> On Oct 18, 2021, at 12:05 PM, Matt Sicker  wrote:
>>> 
>>> I’d imagine it’s for testing purposes initially. We should integrate it
>> into the main domain when it’s ready for release. This should all be
>> controllable via the .asf.yaml file.
>>> 
>>> Matt Sicker
>>> 
>>>> On Oct 18, 2021, at 12:32, Ralph Goers 
>> wrote:
>>>> 
>>>> Why?
>>>> 
>>>> Ralph
>>>> 
>>>>> On Oct 18, 2021, at 8:40 AM, Volkan Yazıcı  wrote:
>>>>> 
>>>>> For the moment, I just want the `gh-pages` branch of the logging-log4j2
>>>>> GitHub project to be accessible at "a" URL – just like any other
>> non-ASF
>>>>> GitHub project.
>>>>> 
>>>>>> On Mon, Oct 18, 2021 at 5:38 PM Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>>>> wrote:
>>>>>> 
>>>>>> OK. That page didn’t exist when I migrated the site from the CMS. That
>>>>>> still leaves
>>>>>> the second question. What are you proposing? I don’t really see the
>> point
>>>>>> of moving
>>>>>> the existing site to GitHub Pages.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Oct 18, 2021, at 8:31 AM, Volkan Yazıcı  wrote:
>>>>>>> 
>>>>>>> GitHub Pages look pretty doable to me:
>>>>>>> https://cwiki.apache.org/confluence/display/INFRA/GitHub+Pages
>>>>>>> 
>>>>>>> On Fri, Oct 15, 2021 at 6:35 PM Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I don’t really understand this. When I was migrating the web site
>> from
>>>>>> the
>>>>>>>> ASF CMS to GitHub
>>>>>>>> it was made clear that web site hosting using GitHub Pages wasn’t
>>>>>>>> supported. I am not sure
>>>>>>>> what the proposal here is.
>>>>>>>> 
>>>>>>>> Ralph
>>>>>>>> 
>>>>>>>>> On Oct 15, 2021, at 8:27 AM, Matt Sicker  wrote:
>>>>>>>>> 
>>>>>>>>> I’m not exactly sure how we can get a beta subdomain, though the
>>>>>> staging
>>>>>>>> one is built in. And while it would be great to automate as much as
>>>>>>>> possible about the release process in GHA, the code signing aspect
>> is
>>>>>> still
>>>>>>>> not possible (though we might be able to integrate with another
>> service
>>>>>> at
>>>>>>>> Apache for

Re: How to inject a dependency into a custom filter.

[Apache]

It sounds to me like you want to create a new type of plugin similar to 
PatternConerters. I am curious as to what your filter does. Is it something 
that would be useful to others so that we would be interested in including it?

Ralph

> On Oct 21, 2021, at 6:07 AM, Adwait Kumar Singh 
>  wrote:
> 
> I am creating a filter which requires the user to give a Supplier to
> fetch some custom rules. I am wondering how to go about getting this
> Supplier from the configuration xml.
> 
> One way I have thought of is using some sort of Registry and then just
> asking the user to provide a key to lookup into the Registry to fetch the
> Supplier. The user then registers his Supplier to this Registry in Java
> code.
> What are your thoughts on this and do you guys know of a better way to do
> this?
> 
> Thanks,
> Adwait.

Re: How to inject a dependency into a custom filter.

[Apache]

After thinking about this more I can’t quite figure out what the user would be 
specifying in the configuration. A Java lambda expression? I.e what is the rule 
syntax? Or are they expected to just configure predefined rules with perhaps 
some variables. But if that is the case how is this really any different than 
just creating new filters? The only real difference I see is that the Supplier 
presumably returns a Boolean instead of a filter result.

Ralph

> On Oct 21, 2021, at 4:51 PM, Ralph Goers  wrote:
> 
> This sounds interesting. I might give it a whirl but  firstI am trying to 
> finish up some work on 
> Apache Flume so it can get a new release and I need to do some other work 
> here as we 
> are overdue for a release.
> 
> Ralph
> 
>> On Oct 21, 2021, at 11:28 AM, Adwait Kumar Singh 
>>  wrote:
>> 
>> The problem I am stuck on is the best way to get the user to provide the
>> ruleSupplier via configuration.
>> 
>>> On Thu, Oct 21, 2021 at 11:55 PM Adwait Kumar Singh <
>>> theadvaitkumarsi...@gmail.com> wrote:
>>> 
>>> Yes I mean filtering on those loggers.
>>> 
>>> I don't expect the Supplier to be dynamically changed, only the rules they
>>> are fetching. Something roughly like this
>>> 
>>> public class RuleBaseFilter extends AbstractFilter {
>>> 
>>>   //This will be initialized only once
>>>   Supplier> rulesSupplier;
>>> 
>>> 
>>> @Override
>>>  public Result filter(final Logger logger, final Level level, final
>>> Marker marker, final Message msg,
>>>  final Throwable t) {
>>>   List rules = rulesSupplier.get();
>>>   //evaluate rules and filter
>>> }
>>> 
>>> }
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Oct 21, 2021 at 11:19 PM Ralph Goers 
>>> wrote:
>>> 
>>>> Sorry, you have lost me a little bit.
>>>> 
>>>> When you say dynamically turn on/off loggers I am assuming you really
>>>> mean
>>>> enable/disable filtering on those Loggers?
>>>> 
>>>> Are you thinking that the rules can be added or removed dynamically? Or
>>>> just the
>>>> parameters to the rules? I ask because you can’t really add a Supplier
>>>> dynamically
>>>> if it is part of the configuration. Log4j will process the configuration
>>>> only when it is
>>>> changed. However, the data they rely on can come from anywhere - more or
>>>> less
>>>> how we use Lookups to evaluate conditions on every log event.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Oct 21, 2021, at 8:44 AM, Adwait Kumar Singh <
>>>> theadvaitkumarsi...@gmail.com> wrote:
>>>>> 
>>>>> This is still in the proof of concept phase, but what I am trying to do
>>>> is
>>>>> create a filter which allows developers to dynamically turn on/off
>>>> loggers
>>>>> based on some parameters without restarting their system. The parameters
>>>>> can be varied, like:
>>>>> 1. Turn on WARN log levels of a particular class.
>>>>> 2. Turn on TRACE logging only on a particular host.
>>>>> 3. Turn on DEBUG logs only for requests by a particular client for a
>>>> short
>>>>> duration,
>>>>> ... and any combination of such parameters.
>>>>> 
>>>>> The way I was thinking of doing this was creating a filter which takes
>>>> in a
>>>>> Supplier and then evaluates a log event against that rule.
>>>>> 
>>>>> On Thu, Oct 21, 2021 at 7:37 PM Apache 
>>>> wrote:
>>>>> 
>>>>>> It sounds to me like you want to create a new type of plugin similar to
>>>>>> PatternConerters. I am curious as to what your filter does. Is it
>>>> something
>>>>>> that would be useful to others so that we would be interested in
>>>> including
>>>>>> it?
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Oct 21, 2021, at 6:07 AM, Adwait Kumar Singh <
>>>>>> theadvaitkumarsi...@gmail.com> wrote:
>>>>>>> 
>>>>>>> I am creating a filter which requires the user to give a
>>>> Supplier
>>>>>> to
>>>>>>> fetch some custom rules. I am wondering how to go about getting this
>>>>>>> Supplier from the configuration xml.
>>>>>>> 
>>>>>>> One way I have thought of is using some sort of Registry and then just
>>>>>>> asking the user to provide a key to lookup into the Registry to fetch
>>>> the
>>>>>>> Supplier. The user then registers his Supplier to this Registry in
>>>> Java
>>>>>>> code.
>>>>>>> What are your thoughts on this and do you guys know of a better way
>>>> to do
>>>>>>> this?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Adwait.
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
> 

Re: changes.xml

[Apache]

I tried that. Somehow the whole description got removed. Even if that worked 
the release notes would look terrible.

Ralph.

> On Dec 8, 2021, at 5:23 AM, Gary Gregory  wrote:
> 
> If you refer to
> https://logging.staged.apache.org/log4j/2.x/changes-report.html#a2.15.0 I'm
> not sure what we can do unless there is special sauce to use in
> changes.xml. Are we supposed to use HTML in a changes.xml entry? That would
> be simple enough.
> 
> Gary
> 
>> On Tue, Dec 7, 2021 at 5:05 PM Ralph Goers 
>> wrote:
>> 
>> Gary,
>> 
>> Please review the manual changes for 2.15.0 on the staging web site. The
>> last item is yours from
>> upgrading a bunch of dependency versions.
>> 
>> I spent a bunch of time yesterday trying to figure out how to make that
>> pretty and finally gave up.
>> It requires knowing now the changes plugin passes data to Doxia and what
>> Doxia is going to do to
>> render it. If you look at
>> https://github.com/apache/maven-changes-plugin/blob/master/src/main/java/org/apache/maven/plugins/changes/ChangesReportGenerator.java
>> in the constructAction methodyou will see that it calls sink.text() for
>> the description. I can only guess
>> it is using Doxia’s XHTML Sink which just appends the data to a
>> StringBuffer.
>> 
>> Interestingly, it doesn’t look to bad when the announcement goal is run,
>> but that is only because the
>> target is a Markdown file so it sort of looks ok, although Markdown seems
>> to treat it as one large code block.
>> 
>> Bottom line - Unless you can figure out how to get these to properly
>> format entries like this will
>> continue to be a mess in the future. I know we have had at least one like
>> it in the past.
>> 
>> Ralph
>> 

Re: New Log4j 1 repo

[Apache]

https://github.com/apache/log4j was read-only. The new repo is not.

Ralph

> On Dec 22, 2021, at 11:34 PM, Ralph Goers  wrote:
> 
> I have cloned the read-only log4j repo to 
> https://github.com/apache/logging-log4j1.
> 
> I have followed the build instructions and had to modify the javadoc plugin 
> to not fail on errors. Now it fails in the site plugin.
> 
> If someone else wants to take this on I would suggest the first PR should 
> just to the pom.xml file to get the build working as is.
> 
> Ralph
> 
> 

Re: New Log4j 1 repo

[Apache]

From what I can tell that repo could only be “owned” by a TLP named 
log4j.apache.org. It doesn’t show up on the list of gitbox repos owned by any 
ASF projects. I believe it is a read-only mirror tied to the sun repo. I asked 
infra about it in slack and they weren’t quite sure what it is. So rather than 
hunt that down and make everyone wait I created the new repo. All logging 
services Git repos start with logging-.

Of course you are free to screw around and try to make something happen with 
the old repo rather than just getting started.

Ralph

> On Dec 23, 2021, at 4:56 AM, Vladimir Sitnikov  
> wrote:
> 
> Leo>Instead of or in addition to some of those fixes
> 
> I would suggest the following (in case you wonder, I might volunteer to do
> ALL of that, so don't assume I just sit and tell others how things should
> be done):
> 1. Use the existing repo https://github.com/apache/log4j instead of a newly
> created one.
> The existing repo is well-known in the community (108 watch, 537 forks, 849
> stars), and it is very strange to drop all that.
> 2. Add GitHub CI so the code at least compiles. I think we should not fix
> everything like javadoc/site/whatever if it takes too much time.
> Having any CI would be way better than nothing.
> 3. Consider existing known CVE fixes (e.g. somewhere there was a mention of
> RedHat fixes for log4j 1.x CVEs).
> It might be easier to apply the fixes before the code is split.
> 4. Consider splitting the code into modules. In practice, there's already a
> branch that does exactly that:
> https://github.com/apache/log4j/tree/log4j12modules/modules
> 5. Release 1.2.18.
> 6. Treat CVEs. For instance, implement hardening in log4j-net or whatever.
> 7. Release 1.2.19
> 8 see what happens, maybe new PR would appear.
> 
> Vladimir

Re: New Log4j 1 repo

[Apache]

Thanks Leo. I was using Java 8 with maven 3 in a Linux VM. I don’t think maven 
3 runs on Java 6.

Ralph

> On Dec 23, 2021, at 5:11 AM, Leo Simons  wrote:
> 
> On Thu, 23 Dec 2021 at 12:39, Ralph Goers 
> wrote:
> 
>> It is still the middle of the night for me so I won’t do anything for
>> several hours.
> 
> 
> Whoa, best get some rest! :)
> 
> I will create the branch but I am curious about the rest. When I ran the
>> build last night it ran through a bunch of unit tests without any problems.
> 
> 
> The 1.2.17 build as-is has only a short whitelist of tests being run from
> maven. There are many more tests only set up to run with ant, without maven
> invoking ant.
> 
> I changed the maven build to run all tests. Then set up a matrix build.
> Some of the other tests worked out of the box, not all. So then fixed the
> tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled
> a couple really flaky ones.
> 
> It then failed due to javadoc errors.
> 
> 
> Probably you used JDK9+ where some warnings become errors. I fixed that too
> in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6
> or 7).
> 
> I just told the plugin not to fail and then it started executing the site
>> plugin. I tried updating the version but that just caused it to have an
>> error in the site.xml.
> 
> 
> Yup, fixing the site was a lot of work!
> 
> My question is, you said that the build has test failures. Did I not see
>> them because of the changes after 1.2.17 or is something else going on?
> 
> 
> I think the summary answer here is “lots is going on”!
> 1.2.17 partially migrated the build from ant to maven 2, back in 2012.
> Frankly it wasn’t in so clean a state at time of release.
> That makes sense since all the plug-in stability in maven really only came
> after maven 3. Back then it was pretty normal to work around plugin
> regressions every point release…you can see TODO comments in the 1.2.17 pom
> about it…
> ….you may have forgotten the extent of such pain :-). Cleaning it all up
> was a bunch of explorative surgery!
> 
> Cheers,
> 
> Leo

Re: New Log4j 1 repo

[Apache]

I was already asked to create a branch off of 1.2.17. It will become the main 
branch so trunk can be left alone.

Ralph

> On Dec 23, 2021, at 6:41 AM, Gary Gregory  wrote:
> 
> If we use this repo, is everyone OK renaming "trunk" to "master" in order
> to match the branch name of our other repos?
> 
> Gary
> 
>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers 
>> wrote:
>> 
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>> 
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>> 
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>> 
>> Ralph
>> 
>> 
>> 

Re: New Log4j 1 repo

[Apache]

I have VMWare on my Mac with both Ubuntu and Windows 10. So I should be able to 
run a build.

Ralph

> On Dec 23, 2021, at 5:59 AM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> 
> On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote:
>>> using maven toolchain feature
>> 
>> Are toolchains really needed, especially, 1.6 and 1.7?
>> I believe Java "target=1.4" + Java 1.8 would be good enough.
>> If there are javadoc "warnings or errors", we could just suppress it.
>> At the end of the day, making the build 100 times harder by requesting Java
>> 1.6
>> looks like an overkill.
>> 
>> I think there's no way to install Java 1.6 on modern macOS.
> 
> Correct. I would suggest Docker, if there is a way to install it there.
> 
> Here is some more installation instructions:
> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> 
> For a complete build for a release, one needs to run tests using some DLLs 
> which made it very hard back then.
> 
> Christian
> 
> 
>> 
>> Vladimir
> 

Re: Log4J 1.x progress, pull request(s), plans

[Apache]

Fwiw, this sounds like a god plan to me.

Ralph

> On Dec 23, 2021, at 6:51 AM, Leo Simons  wrote:
> 
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
> 
> What I did for the PRs I made is to
> 
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done for 64 bit,
> * have the maven build not auto-attempt to build it,
> * make its single unit test not even attempt to run except on windows,
> * add a matrix build that includes running on windows so that the
> windows-only test gets run frequently
> * did a little test on a windows machine with one of the DLLs
> 
> Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
> 
> I think it’s good enough like that.
> 
> Additional todo could be
> * add better INSTALL instructions for how to rebuild the dlls with ant
> * add another CI / GitHub action build that rebuilds the DLLs
> 
> I think it is best to produce the DLLs on windows and the official release
> on linux, and to not attempt to have build orchestration to glue those
> together. It’s an exceptionally messy thing to rebuild from source without
> manual step, while the manual step is easy.
> 
> Cheers,
> 
> Leo
> 
> 
>> On Thu, 23 Dec 2021 at 14:34, Gary Gregory  wrote:
>> 
>> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 
>> wrote:
>> 
>>> 
>>> On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
>>>> One of the difficulties was likely related to building the Windows DLLs
>>>> for
>>>> using the Windows Event Log Appender (
>>>> 
>>> 
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
>>> ).
>>>> I remember that being challenging. I can't recall if we signed the DLLs
>>>> like we might do for Apache Commons Daemons Windows binaries. Another
>>>> hurdle.
>>> 
>>> Correct, the DLL is even in the codebase.
>>> 
>>> 
>> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>>> 
>>> If we would remove that Appender, it would be much easier to build, when
>> I
>>> remember correctly.
>>> Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>>> 
>> 
>> Sadly, no. We cannot break binary compatibility, that would create a bigger
>> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
>> me.
>> 
>> I feel like the projects I've worked on like Apache Commons and
>> HttpComponents have benefitted *massively* from providing binary
>> compatibility. Giving users drop-in replacements is a huge help.
>> 
>> Recall that Apache officially *only releases source code*, and that source
>> code must be buildable, no matter how complex the instructions. Any
>> binaries are only provided as a convenience, that includes jar files and
>> DLLs.
>> 
>> Gary
>> 
>> 
>>>> 
>>>> FWIW, my opinion has been to NOT resurrect 1.x and put our energies
>> into
>>>> improving the 1.2 bridge and configuration file support we already have
>>> in
>>>> 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>>>> 
>>>> No matter what, it needs to be a decision made carefully and not in
>>> haste.
>>>> 
>>> 
>>> +1
>>> 
>>>> Gary
>>>> 
>>>> On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
>>> grobme...@apache.org>
>>>> wrote:
>>>> 
>>>>> Hello
>>>>> 
>>>>> I have been the person cutting the 1.2.17 release and what I remember
>>> was
>>>>> it was a super hard build. I had to install some VMs because there
>> were
>>>>> weird dependencies to this build. Building it fully will not be easy,
>>> but I
>>>>> can also look into some mails whatever I found from that time.
>>>>> Here is some build info.:
>>>>> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>>>>> Some unit tests only run with a Windows VM
>>>>> 
>>>>> It would be easier to remove some components, but BC is broken then.
>>>>> 
>>>>> We told people in August 2015 this is EOL. I am honestly surprised
>> that
>>> we
>>>>> discuss a new release after 7 years. To my understanding the
>> JMSAppender
>>>>> iss

Re: RELEASE-NOTES.md

[Apache]

The release notes file is generated for every release.

Ralph

> On Dec 24, 2021, at 6:20 AM, Volkan Yazıcı  wrote:
> 
> Is this file still relevant? If not, may I simply delete it? If it is, mind
> somebody explaining what to do with it? How shall we use it in the presence
> of `changes.xml`?
> 
> -- Forwarded message -
> From: Kristjan Esperanto 
> Date: Sun, Dec 19, 2021 at 12:08 PM
> Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
> To: apache/logging-log4j2 
> Cc: Subscribed 
> 
> 
> It's a minor detail, but I didn't find any reference to the release history
> in the repository.
> --
> You can view, comment on, or merge this pull request online at:
> 
>  https://github.com/apache/logging-log4j2/pull/642
> Commit Summary
> 
>   - 89ff650
>   
> <https://github.com/apache/logging-log4j2/pull/642/commits/89ff6508f735e3e422abbf5b221a5ff0980c22c9>
>   Add Link to Release History
> 
> File Changes
> 
> (1 file <https://github.com/apache/logging-log4j2/pull/642/files>)
> 
>   - *M* RELEASE-NOTES.md
>   
> <https://github.com/apache/logging-log4j2/pull/642/files#diff-7d8a453165f16d910a0937bf01782607cafc77fd7f42b443aff0cd02725848d7>
>   (4)
> 
> Patch Links:
> 
>   - https://github.com/apache/logging-log4j2/pull/642.patch
>   - https://github.com/apache/logging-log4j2/pull/642.diff
> 
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/642>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAARTSKH4JEGNONQTMPORJ3URW4KPANCNFSM5KLYIE2Q>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: 

Re: RELEASE-NOTES.md

[Apache]

I should have added that you should not delete it.

Ralph

> On Dec 24, 2021, at 7:00 AM, Apache  wrote:
> 
> The release notes file is generated for every release.
> 
> Ralph
> 
>> On Dec 24, 2021, at 6:20 AM, Volkan Yazıcı  wrote:
>> 
>> Is this file still relevant? If not, may I simply delete it? If it is, mind
>> somebody explaining what to do with it? How shall we use it in the presence
>> of `changes.xml`?
>> 
>> -- Forwarded message -
>> From: Kristjan Esperanto 
>> Date: Sun, Dec 19, 2021 at 12:08 PM
>> Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
>> To: apache/logging-log4j2 
>> Cc: Subscribed 
>> 
>> 
>> It's a minor detail, but I didn't find any reference to the release history
>> in the repository.
>> --
>> You can view, comment on, or merge this pull request online at:
>> 
>> https://github.com/apache/logging-log4j2/pull/642
>> Commit Summary
>> 
>>  - 89ff650
>>  
>> <https://github.com/apache/logging-log4j2/pull/642/commits/89ff6508f735e3e422abbf5b221a5ff0980c22c9>
>>  Add Link to Release History
>> 
>> File Changes
>> 
>> (1 file <https://github.com/apache/logging-log4j2/pull/642/files>)
>> 
>>  - *M* RELEASE-NOTES.md
>>  
>> <https://github.com/apache/logging-log4j2/pull/642/files#diff-7d8a453165f16d910a0937bf01782607cafc77fd7f42b443aff0cd02725848d7>
>>  (4)
>> 
>> Patch Links:
>> 
>>  - https://github.com/apache/logging-log4j2/pull/642.patch
>>  - https://github.com/apache/logging-log4j2/pull/642.diff
>> 
>> —
>> Reply to this email directly, view it on GitHub
>> <https://github.com/apache/logging-log4j2/pull/642>, or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AAARTSKH4JEGNONQTMPORJ3URW4KPANCNFSM5KLYIE2Q>
>> .
>> You are receiving this because you are subscribed to this thread.Message
>> ID: 

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

[Apache]

Infra has a mailing list and a slack channel.

Ralph

> On Dec 26, 2021, at 6:00 AM, Carter Kozak  wrote:
> 
> I filed an infra ticket for this, but it hasn’t been picked up yet: 
> https://issues.apache.org/jira/browse/INFRA-22641
> Might be worth emailing someone? Otherwise they may be busy with the holidays.
> 
> -ck
> 
>> On Dec 26, 2021, at 06:16, Volkan Yazıcı  wrote:
>> 
>> 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?

Re: [logging-log4j2] branch release-2.x updated: LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of formatted message data

[Apache]

Please don’t forget to apply this to the master branch

Ralph

> On Dec 25, 2021, at 12:20 PM, cko...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> ckozak 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 push:
> new 487588b  LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of 
> formatted message data
> 487588b is described below
> 
> commit 487588b7c34bc0b540e769d98c42d018fa1bc1b8
> Author: Carter Kozak 
> AuthorDate: Sat Dec 25 11:48:20 2021 -0500
> 
>LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of formatted message data
> ---
> .../java/org/apache/logging/slf4j/SLF4JLogger.java | 28 ++
> .../java/org/apache/logging/slf4j/LoggerTest.java  | 33 ++
> src/changes/changes.xml|  3 ++
> 3 files changed, 52 insertions(+), 12 deletions(-)
> 
> diff --git 
> a/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java 
> b/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java
> index 5ea8b7b..be1a15a 100644
> --- a/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java
> +++ b/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java
> @@ -86,10 +86,13 @@ public class SLF4JLogger extends AbstractLogger {
> return locationAwareLogger != null ? locationAwareLogger : logger;
> }
> 
> -private org.slf4j.Marker getMarker(final Marker marker) {
> -if (marker == null) {
> -return null;
> -}
> +private static org.slf4j.Marker getMarker(final Marker marker) {
> +// No marker is provided in the common case, small methods
> +// are optimized more effectively.
> +return marker == null ? null : convertMarker(marker);
> +}
> +
> +private static org.slf4j.Marker convertMarker(final Marker marker) {
> final org.slf4j.Marker slf4jMarker = 
> MarkerFactory.getMarker(marker.getName());
> final Marker[] parents = marker.getParents();
> if (parents != null) {
> @@ -222,31 +225,32 @@ public class SLF4JLogger extends AbstractLogger {
> 
> @Override
> public void logMessage(final String fqcn, final Level level, final Marker 
> marker, final Message message, final Throwable t) {
> +org.slf4j.Marker slf4jMarker = getMarker(marker);
> +String formattedMessage = message.getFormattedMessage();
> if (locationAwareLogger != null) {
> if (message instanceof LoggerNameAwareMessage) {
> ((LoggerNameAwareMessage) message).setLoggerName(getName());
> }
> -locationAwareLogger.log(getMarker(marker), fqcn, 
> convertLevel(level), message.getFormattedMessage(),
> -message.getParameters(), t);
> +locationAwareLogger.log(slf4jMarker, fqcn, convertLevel(level), 
> formattedMessage, null, t);
> } else {
> switch (level.getStandardLevel()) {
> case DEBUG :
> -logger.debug(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.debug(slf4jMarker, formattedMessage, t);
> break;
> case TRACE :
> -logger.trace(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.trace(slf4jMarker, formattedMessage, t);
> break;
> case INFO :
> -logger.info(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.info(slf4jMarker, formattedMessage, t);
> break;
> case WARN :
> -logger.warn(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.warn(slf4jMarker, formattedMessage, t);
> break;
> case ERROR :
> -logger.error(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.error(slf4jMarker, formattedMessage, t);
> break;
> default :
> -    logger.error(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.error(slf4jMarker, formattedMessage, t);
>     break;
> }
> }
> diff --git 
> a/log4j-to-slf4j/src/test/java/org/apache/logging/slf4j/LoggerTest

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-3256] Reduce ignored package scope of KafkaAppender #640.

[Apache]

Please don’t forget to apply this to the master branch.

Ralph

> On Dec 26, 2021, at 6:31 AM, ggreg...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> 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 push:
> new aba0358  [LOG4J2-3256] Reduce ignored package scope of KafkaAppender 
> #640.
> aba0358 is described below
> 
> commit aba0358db59b0657dba370271768351cf97b4b5c
> Author: Gary Gregory 
> AuthorDate: Sun Dec 26 08:30:53 2021 -0500
> 
>[LOG4J2-3256] Reduce ignored package scope of KafkaAppender #640.
> 
>Modified GitHub patch #640 from Lee
>Dongjin/dongjinleekr/dong...@apache.org.
> ---
> src/changes/changes.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 4c96396..7f2b6ee 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -55,7 +55,7 @@
>   
> Lookups with no prefix only read values from the configuration 
> properties as expected.
>   
> -  
> +  
> Reduce ignored package scope of KafkaAppender.
>   
> 
> 

Re: Should lookups be split out or otherwise disabled by default?

[Apache]

The answer is - it depends. Although we might consider using the properties 
proposal I made in master many of the lookups should default to being enabled 
or enabled under a condition. For example, the spring lookup only works when 
spring boot is present. It would be stupid for it not to be enabled when it is 
a spring boot app.

Ralph

> On Jan 13, 2022, at 8:19 PM, Matt Sicker  wrote:
> 
> For the extra paranoid users and users who already use some other method of 
> generating config files (e.g., using the ConfigurationBuilder DSL which 
> already supports arbitrary Java code), it seems like a useful feature to make 
> lookups an opt-in feature. What do you all think? Any splitting from core 
> would need to be done for 3.x, though we can add @RequiredProperty 
> annotations to StrLookup plugins in 2.x to make a similar change.
> --
> Matt Sicker
> 

Re: [ANNOUNCEMENT] Apache Commons Release Plugin Version 1.8.0

[Apache]

Wrong list

Ralph

> On Apr 2, 2022, at 5:08 AM, Gary Gregory  wrote:
> 
>  We just released our release tool, Apache Commons Release Plugin Version
> 1.8.0:
> An Apache Maven Mojo for Apache Commons Release tasks.
> 
> Historical list of changes:
> https://commons.apache.org/proper/commons-release-plugin//changes-report.html
> 
> For complete information on Apache Commons Release Plugin, including
> instructions on how to submit bug reports, patches, or suggestions for
> improvement, see the Apache Apache Commons Release Plugin website:
> 
> https://commons.apache.org/proper/commons-release-plugin/
> 
> Download page:
> https://commons.apache.org/proper/commons-release-plugin//download_text.cgi
> 
> Have fun!
> 
> Gary Gregory,
> -Apache Commons Team

Re: Considering porting DI to 2.x

[Apache]

Lol. Ok An app running in Java 11. That changes nothing. We can certainly make 
some incompatible changes but as we have previously discussed some of the 
things you removed will have to be reverted.

Making Log4J 3 not backward compatible would be a disaster.

Ralph

> On Apr 18, 2022, at 5:07 PM, Gary Gregory  wrote:
> 
> "an app
> will certainly be able to replace their 2.x jars with 3.x jars and continue
> to work"
> 
> Certainly not since 3.x requires Java 11.
> 
> Gary
> 
>> On Mon, Apr 18, 2022, 18:19 Ralph Goers  wrote:
>> 
>> I have no idea what you are referring to.
>> 
>> You are talking about having log4j 2 and log4j 3 jars present in the
>> application
>> at the same time? You can no more do that than you can have a
>> log4j-core.2.17.1
>> jar and a log4j-core-2.17.2 jar on the classpath at the same time. But an
>> app
>> will certainly be able to replace their 2.x jars with 3.x jars and
>> continue to work.
>> 
>> Why would you think you need both versions to be present at the same time?
>> 
>> Ralph
>> 
>>> On Apr 19, 2022, at 12:05 AM, Gary Gregory 
>> wrote:
>>> 
>>> How can they coexist when they use the same package names? This is why I
>>> want to use a different package name root for 3.x, like org.apache.log4j3
>>> or something like that.
>>> 
>>> On Mon, Apr 18, 2022, 17:07 Ralph Goers 
>> wrote:
>>> 
 Gary, that really doesn’t say anything. 2.x and 3.x are already designed
 to be able to coexist.
 
 Ralph
 
> On Apr 18, 2022, at 10:50 PM, Gary Gregory 
 wrote:
> 
> For my 2c, the better internals are not going to motivate the majority
>> of
> users to update to 3.0, features are. It might be different for plugin
> authors, but how many of those are there? My guess is a minuscule
 amount. I
> agree that 2.x should live for a long long time, and should be able to
> coexist with 1.x and 3.x.
> 
> Gary
> 
> Gary
> 
> On Mon, Apr 18, 2022, 14:56 Piotr P. Karwasz 
> wrote:
> 
>> Hi Volcan,
>> 
>> On Sun, 17 Apr 2022 at 22:42, Volkan Yazıcı  wrote:
>> 
>>> 1. I was working on LOG4J2-3082 (support external serializers, e.g.,
>>> Jackson, in JTL) and there I needed `@RequiredClass`. Ralph already
>>> implemented this in `master`, I just need to copy it to
 `release-2.x`,
>>> after all it is just a `@ConstraintValidator`, right? Right... But
>> it
>>> simply won't work. Because JTL, as `PatternLayout`, uses
>>> `PluginManager` to
>>> load plugins and that doesn't support `@ConstraintValidator` et
>> al.?!
>>> I've
>>> discussed this with Matt and we came to the conclusion that porting
>> the
>>> new
>>> plugin infra from 3.x to 2.x is easier compared to fixing the
>> problem
>> in
>>> 2.x.
>>> 
>> 
>> Maybe this can be solved in other ways. For example we could have a:
>> 1. `SerializerFactory` with multiple implementations each one in a
 separate
>> module,
>> 2. You use the `ServiceLoaderUtil` to find an implementation or you
>> use
 the
>> internal one if there are none.
>> 
>> I think that the dependency injector is a feature that should stay in
 3.0
>> to motivate people to move from 2.x.
>> 
>> Piotr
>> 
 
 
>> 
>> 
>> 

Re: Consuming our own BOM

[Apache]

It is implemented on master.

Ralph

> On May 30, 2022, at 2:27 AM, Volkan Yazıcı  wrote:
> 
> Mind somebody sharing the last state? Is it implemented, if so how and on
> which branch(es)? Is it reverted? If so, totally or partially?
> 
>> On Sun, May 29, 2022 at 9:53 AM Ralph Goers 
>> wrote:
>> 
>> That is OK. I have reverted your commit and am testing the build for a
>> second time doing it the correct way.
>> 
>> Ralph
>> 
 On May 28, 2022, at 9:14 PM, Matt Sicker  wrote:
>>> 
>>> It worked, but I had to specify where the parent pom was in the
>> submodules. Are you saying I could get the same effect by importing the bom
>> in the parent pom? If so, that certainly seems easier.
>>> 
>>> —
>>> Matt Sicker
>>> 
 On May 28, 2022, at 18:15, Ralph Goers 
>> wrote:
 
 Why is this necessary? I would think having the parent import the
>> bom/pom.xml should be enough.
 
 Ralph
 
> On May 27, 2022, at 6:18 PM, Matt Sicker  wrote:
> 
> To avoid rearranging all the directories, I'm moving the parent pom to
> its own directory, moving the bom pom to the root, and updating the
> rest of the poms to know where the old parent pom now is.
> 
>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker  wrote:
>> 
>> Agreed. I added the BOM POM later on and didn’t know of any
>> established patterns for modules as BOMs weren’t used extensively quite yet
>> at the time (and it was a Maven specific feature then, too; Spring ported
>> the concept to Gradle later on, and now Gradle has a native concept of the
>> same thing).
>> 
>> —
>> Matt Sicker
>> 
>>> On May 19, 2022, at 10:33, Ralph Goers 
>> wrote:
>> 
>> Yes, that would make sense. I am sure this happened simply because
>> the bom pom.xml was introduced way after the first releases.
>> 
>> Ralph
>> 
>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı  wrote:
>> 
>> 
>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>> 
>> ourselves. Hence occasionally we end up publishing artifacts not
>> included
>> 
>> in the BOM. Consuming our own BOM decreases the chances of missing out
>> 
>> artifacts in BOM, though doesn't totally eliminate the chances of that
>> 
>> happening.
>> 
>> 
>> When I read how Maven advises to structure the BOM module
>> 
>> <
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>>> ,
>> 
>> I understand what needs to be in the case of Log4j is the following:
>> 
>> 
>> /pom.xml (`log4j-bom` module)
>> 
>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>> 
>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
>> `log4j`)
>> 
>> 
>> Though what we have in reality is the following:
>> 
>> 
>> /log4j-bom/pom.xml (`log4j-bom` module)
>> 
>> /pom.xml (`log4j` module parented by `logging-parent`)
>> 
>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>> 
>> 
>> Ideally we should follow the Maven-advised approach and consume from
>> our
>> 
>> BOM parented by `logging-parent`.
>> 
>> 
>> What do you think? Is my interpretation of the Maven-advised approach
>> 
>> correct?
>> 
>> 
 
>> 
>> 

Re: [logging-log4j2] branch master updated: [LOG4J2-3459] - Add LoggingSystemProvider SPI

[Apache]

See below

> On Oct 31, 2022, at 6:49 PM, Matt Sicker  wrote:
> 
> The util3 package is a collection of all the private classes we have. We 
> discussed the general idea on a recent conference call. These are pseudo 
> private classes. They’re meant for internal use only and are guarded by the 
> module info. JUnit does the same thing

If they are private then they should be under a package named internal. It 
won’t be obvious to devs not using JPMS that they are private.

> The point of Lazy is ensuring thread safe publication of initialized 
> variables that may be initialized by multiple threads. There are two main 
> variants: one that guarantees the supplier function is executed only once and 
> one that may run the supplier more than once but has a single return value.

But why is it necessary? When getInstance is called that operation should only 
be performed once. GetInstance is already lazy so why do we need lazy 
initialization of the stuff in it?

Ralph

> 
> —
> Matt Sicker
> 
>> On Oct 31, 2022, at 17:53, Ralph Goers  wrote:
>> 
>> Also, in LoggingSystem.java
>> 
>> private static final String[] COMPATIBLE_API_VERSIONS = {"2.6.0"};
>> 
>> absolutely needs to be changed to version “3.0.0”.
>> 
>> Ralph
>> 
>>>> On Oct 31, 2022, at 3:49 PM, Ralph Goers  
>>>> wrote:
>>> 
>>> Matt,
>>> 
>>> I absolutely would have preferred that you had created a PR for this and 
>>> asked for a review before committing it as I have a few concerns:
>>> 
>>> 1. It is a massive commit. It is going to take time to digest exactly what 
>>> you have done.
>>> 2. You have created a util3 package in API with no discussion of this on 
>>> the dev list. I assume that it contains artifacts that were cleaned up from 
>>> util and are now no longer compatible? Or does it only contain classes that 
>>> are exportable to other Log4j artifacts (I do see that in 
>>> module-info.java). If these classes are meant to be private then I would 
>>> have preferred that it be moved to internal/util. 
>>> 3. I no longer understand the point of Lazy<>. LogManager now performs no 
>>> static initialization that I can see. Instead, it calls 
>>> LoggingSystem.getInstance(). What is the point of making initialization of 
>>> INSTANCE lazy? You accomplished what you wanted to by moving the static 
>>> initialization to another class.
>>> 4-10. I have no idea as it will take me a week to muddle through the rest 
>>> of all these changes to figure out what happened.
>>> 
>>> Ralph
>>> 
>>>>> On Oct 30, 2022, at 6:24 PM, mattsic...@apache.org wrote:
>>>> 
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>> 
>>>> mattsicker pushed a commit to branch master
>>>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>>>> 
>>>> 
>>>> The following commit(s) were added to refs/heads/master by this push:
>>>>  new aab23d5c05 [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>> aab23d5c05 is described below
>>>> 
>>>> commit aab23d5c05bff2915c290dff3e73a0ae03caf43a
>>>> Author: Matt Sicker 
>>>> AuthorDate: Sun Oct 30 20:24:17 2022 -0500
>>>> 
>>>> [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>> 
>>>> This helps clean up a lot of static state in Log4j API along with enabling 
>>>> further extensibility by exposing LoggingSystemProvider::getInstance which 
>>>> can be implemented using Injector in Log4j Core. The general utility class 
>>>> for working with this provider is available as an internal (util3) class 
>>>> in LoggingSystem. Test fixture helper classes have also been updated to 
>>>> use LoggingSystem directly.
>>>> 
>>>> Signed-off-by: Matt Sicker 
>>>> ---
>>>> .../junit/LogManagerLoggerContextFactoryRule.java  |  11 +-
>>>> .../test/junit/LoggerContextFactoryExtension.java  |  12 +-
>>>> .../{TestProvider.java => TestSystemProvider.java} |  23 +-
>>>> .../log4j/spi/DefaultThreadContextMapTest.java |  10 +-
>>>> apache.logging.log4j.spi.LoggingSystemProvider |  17 ++
>>>> .../services/org.apache.logging.log4j.spi.Provider |   1 -
>>>> log4j-api/src/main/java/module-info.java   |   5 +-
>>>> .../java/org/apache/logging/log4j/LogManager.java  |  76 +--
>>>> .../org/apache/l

Re: [logging-log4j2] branch master updated: [LOG4J2-3459] - Add LoggingSystemProvider SPI

[Apache]

Are you using your old email address? I keep having to moderate them through.

Yes they should be in an appropriately named package under the internal package.

Ralph

> On Oct 31, 2022, at 7:36 PM, Matt Sicker  wrote:
> 
> We could consolidate the Log4j-private classes into the internal package and 
> export it to other Log4j modules. That makes sense.
> 
> And LoggingSystem probably doesn’t need a Lazy instance of itself, right.
> 
> —
> Matt Sicker
> 
>> On Oct 31, 2022, at 20:58, Apache  wrote:
>> 
>> 
>> 
>> See below
>> 
>>>> On Oct 31, 2022, at 6:49 PM, Matt Sicker  wrote:
>>> 
>>> The util3 package is a collection of all the private classes we have. We 
>>> discussed the general idea on a recent conference call. These are pseudo 
>>> private classes. They’re meant for internal use only and are guarded by the 
>>> module info. JUnit does the same thing
>> 
>> If they are private then they should be under a package named internal. It 
>> won’t be obvious to devs not using JPMS that they are private.
>> 
>>> The point of Lazy is ensuring thread safe publication of initialized 
>>> variables that may be initialized by multiple threads. There are two main 
>>> variants: one that guarantees the supplier function is executed only once 
>>> and one that may run the supplier more than once but has a single return 
>>> value.
>> 
>> But why is it necessary? When getInstance is called that operation should 
>> only be performed once. GetInstance is already lazy so why do we need lazy 
>> initialization of the stuff in it?
>> 
>> Ralph
>> 
>>> 
>>> —
>>> Matt Sicker
>>> 
>>>>> On Oct 31, 2022, at 17:53, Ralph Goers  wrote:
>>>> 
>>>> Also, in LoggingSystem.java
>>>> 
>>>> private static final String[] COMPATIBLE_API_VERSIONS = {"2.6.0"};
>>>> 
>>>> absolutely needs to be changed to version “3.0.0”.
>>>> 
>>>> Ralph
>>>> 
>>>>>> On Oct 31, 2022, at 3:49 PM, Ralph Goers  
>>>>>> wrote:
>>>>> 
>>>>> Matt,
>>>>> 
>>>>> I absolutely would have preferred that you had created a PR for this and 
>>>>> asked for a review before committing it as I have a few concerns:
>>>>> 
>>>>> 1. It is a massive commit. It is going to take time to digest exactly 
>>>>> what you have done.
>>>>> 2. You have created a util3 package in API with no discussion of this on 
>>>>> the dev list. I assume that it contains artifacts that were cleaned up 
>>>>> from util and are now no longer compatible? Or does it only contain 
>>>>> classes that are exportable to other Log4j artifacts (I do see that in 
>>>>> module-info.java). If these classes are meant to be private then I would 
>>>>> have preferred that it be moved to internal/util. 
>>>>> 3. I no longer understand the point of Lazy<>. LogManager now performs no 
>>>>> static initialization that I can see. Instead, it calls 
>>>>> LoggingSystem.getInstance(). What is the point of making initialization 
>>>>> of INSTANCE lazy? You accomplished what you wanted to by moving the 
>>>>> static initialization to another class.
>>>>> 4-10. I have no idea as it will take me a week to muddle through the rest 
>>>>> of all these changes to figure out what happened.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>>> On Oct 30, 2022, at 6:24 PM, mattsic...@apache.org wrote:
>>>>>> 
>>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>>> 
>>>>>> mattsicker pushed a commit to branch master
>>>>>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>>>>>> 
>>>>>> 
>>>>>> The following commit(s) were added to refs/heads/master by this push:
>>>>>> new aab23d5c05 [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>>>> aab23d5c05 is described below
>>>>>> 
>>>>>> commit aab23d5c05bff2915c290dff3e73a0ae03caf43a
>>>>>> Author: Matt Sicker 
>>>>>> AuthorDate: Sun Oct 30 20:24:17 2022 -0500
>>>>>> 
>>>>>> [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>>>> 
>>>

Re: Broken build

[Apache]

Consistent

Ralph

> On Nov 16, 2022, at 5:23 PM, Matt Sicker  wrote:
> 
> Is this a consistent failure or random?
> 
>> On Nov 16, 2022, at 3:42 PM, Ralph Goers  wrote:
>> 
>> I haven’t run a build in a while and looking at the recent commits I am not 
>> sure what is causing this, but some change since 2.19.0 is now causing the 
>> following build failures in log4j-core.
>> 
>> Ralph
>> 
>> [ERROR] Failures: 
>> [ERROR]   LoggerTest.basicFlow:90 expected: <2> but was: <4>
>> [ERROR]   LoggerTest.builder:77 Incorrect message 1
>> Expected: " DEBUG 
>> org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello"
>>but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)"
>> [ERROR]   LoggerTest.debug:209 expected: <1> but was: <0>
>> [ERROR]   LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but was: 
>> <2>
>> [ERROR]   LoggerTest.flowTracingMessage:104 Incorrect Entry
>> Expected: a string starting with "ENTER[ FLOW ] TRACE Enter"
>>but: was "THROWING[ EXCEPTION ] ERROR Throwing 
>> java.lang.IllegalArgumentException: Test Exception
>> at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at 
>> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>> at 
>> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>> at 
>> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
>> at 
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
>> at 
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
>> at 
>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
>> at 
>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
>> at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
>> at 
>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
>> at 
>> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
>> at java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189)
>> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>> at 
>> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.ja

Re: Maven site failure

[Apache]

False is the default so I left it alone. It also means it is specified in less 
places.

Ralph

> On Dec 30, 2022, at 5:26 AM, Gary Gregory  wrote:
> 
> Should that setting be flipped such that a Maven module ask to be Javadoc'd?
> 
> Gary
> 
>> On Fri, Dec 30, 2022, 07:23 Volkan Yazıcı  wrote:
>> 
>> Agreed.
>> 
>> Ralph, I see that you have only added `true` to
>> `log4j-layout-template-json-test` module, why don't we add it to all
>> `*-test` and `*-its` modules? That is, `log4j-api-test`, `log4j-core-its`,
>> `log4j-core-test`, etc.
>> 
>> On Fri, Dec 30, 2022 at 1:45 AM Ralph Goers 
>> wrote:
>> 
>>> 
>>> 
 On Dec 29, 2022, at 5:44 PM, Ralph Goers 
>>> wrote:
 
 I am trying to build the web site and it is failing in the javadoc
>>> plugin in log4j-layout-template-json-test because there are public or
>>> protected classes to document. Either the javadoc plugin needs to be
>>> disabled for the module or some classes need to be made public.
>>> 
>>> Personally, I don’t think any of the test modules need javadoc generated.
>>> 
>>> Ralph
>> 

Re: Jira emails

[Apache]

Nevermind. I think Gavin fixed it.

I imagine Jenkins has to be modified as well.

> On Apr 11, 2017, at 11:50 PM, Ralph Goers  wrote:
> 
> Matt,
> 
> It seems Jira is still configured to send to the individual lists. I don’t 
> seem to have rights to change that. I have asked Gavin to fix that in the 
> Jira issue but now that it is in “Waiting for User” I am not sure he will see 
> it. Can you please change the status back?
> 
> Ralph
> 

Re: [Log4j] Plans for modularization

[Apache]

We have to do something. I am about 3/4 of the way creating java9 modules and I 
am not happy with core at all.  Far too many classes have to be exported as you 
can only name packages, not classes.

I think all the configuration stuff will need to stay in core, which means the 
optional dependency on Jackson will remain, but I could be convinced otherwise.

Ralph

> On Apr 23, 2017, at 10:45 AM, Matt Sicker  wrote:
> 
> I think I brought this topic up like 3 years ago when I was working on
> initial OSGi support, but now that we have 3 more years worth of code
> additions and optional features, I think this might be a more appropriate
> time to discuss it again in light of experience.
> 
> Building log4j-core itself already takes a long time, and many plugins
> aren't updated very often at all. In the past, requiring users to simply
> add log4j-core plus any transitive dependencies to use optional features
> seemed to work well enough, but I still think that's a confusing
> distribution mechanism as demonstrated by the numerous bug reports and
> Stack Overflow posts regarding missing transitive dependencies for various
> features. I spent some time experimenting with Log4j Boot a little while
> ago to help alleviate this problem, but this may be unnecessary if we can
> agree to modularize log4j-core itself.
> 
> I have two different proposals, both of which can be used at the same time.
> 
> 1. Split out everything from log4j-core that requires 3rd party
> dependencies (except for AsyncLogger, though perhaps we could consider
> shading and renaming those classes like some other low level libraries do
> with JCTools). Ideally, I'd like to see each module have required
> dependencies instead of optional ones, so that if, for instance, I include
> a "log4j-config-yaml" dependency, I know that Log4j will support YAML
> configuration without having to specify the individual Jackson dependencies.
> 
> 2. Split out from log4j-core a sort of log4j-spi module which defines
> interfaces, abstract classes, and annotations for plugins that would be
> promoted to the same level of backwards compatibility guarantees as
> log4j-api. This would aid in cementing what we really wish to maintain
> compatibility with in the backend while allowing other modules to have less
> strict guarantees.
> 
> With proposal #1, I'd think that we could more easily start moving modules
> into separate repositories and release trains. Without #2, though, this
> makes version support more annoying to handle, but that's what we'll face
> regardless as we separate more repositories. If we go this route, then
> there will be no need for a Log4j Boot subproject.
> 
> What do you all think?
> 
> -- 
> Matt Sicker 

Re: Roadmap

[Apache]

Gary, you are missing the point. We are not "going" to java 9. We will be 
providing support for it. There was nothing we had to do to support java 8, but 
there are changes that must be made, like using StackWalker and being 
modularized, for Log4J to be usable by everyone who moves to java 9. If we 
don't make these changes now we are basically saying Log4J cannot be used in 
java 9. But we don't have to stop supporting java 7 and 8 to do that.

Ralph

> On Apr 23, 2017, at 3:47 PM, Gary Gregory  wrote:
> 
> Howdy,
> 
> While this is all possible, I do not like the idea of jumping from Java 7
> to 9. I would rather we go to Java 8 soon and take advantage of the whole
> platform cleanly, even if in the case of Instant is a convenience as you
> call it. That makes it then less of a difference when we do go to Java 9
> eventually.
> 
> Gary
> 
>> On Apr 21, 2017 8:51 PM, "Matt Sicker"  wrote:
>> 
>> Using java.time is just a convenience compared to our FastDateTime commons
>> classes anyways. Lambdas are supportable through regular single-method
>> interfaces. As Mikael pointed out, though, default interface methods would
>> be tremendously useful for log4j-api. Alternatively, we could create some
>> abstract base classes where missing and mark the interfaces as changeable.
>> With that pattern, interfaces are for users of the the class, while the
>> abstract classes are for implementers of the class.
>> 
>>> On 21 April 2017 at 11:58, Ralph Goers  wrote:
>>> 
>>> How does that benefit a user of Log4j in Java 8. In Java 9 it is
>> certainly
>>> a benefit if it can provide microsecond granularity.
>>> 
>>> Ralph
>>> 
 On Apr 21, 2017, at 9:21 AM, Gary Gregory 
>>> wrote:
 
 On Apr 21, 2017 7:06 AM, "Ralph Goers" 
>>> wrote:
 
 What features in Java 8 do we need to take advantage of that we haven't
 already?
 
 
 How about java.time? Using an Instant instead of a long to timestamp an
 event?
 
 Gary
 
 
 Sent from my iPhone
 
> On Apr 21, 2017, at 12:44 AM, Mikael Ståldal <
>> mikael.stal...@magine.com
 
 wrote:
> 
> I also have a feeling that we focus too much on Java 9 and not enough
>> on
> Java 8.
> 
>> On Thu, Apr 20, 2017 at 5:08 AM, Remko Popma 
 wrote:
>> 
>> I agree with Ralph that there are many environments that can't
>> upgrade
>> their Java version but still want to use the nice features Log4j2
>>> offers.
>> I've also worked in such environments. I would prefer to support
>> older
>> versions as long as possible. (What that means concretely is open for
>> discussion.) :-)
>> 
>> Remko
>> 
>> Sent from my iPhone
>> 
>>> On Apr 20, 2017, at 11:32, Matt Sicker  wrote:
>>> 
>>> I just want a plan for when we upgrade. Log4j is such low level code
 that
>>> it's not a big deal to me for using Java 8 syntax. I'm mostly
>>> interested
>> in
>>> supporting the v8 APIs, and Spring has an interesting way of doing
>>> that.
>>> 
>>> On Wed, Apr 19, 2017 at 18:01, Ralph Goers <
>>> ralph.go...@dslextreme.com>
>>> wrote:
>>> 
 I can’t agree to that. See
 https://spring.io/blog/2015/04/01/ongoing-support-for-
>> java-7-and-even-java-6
 <
 https://spring.io/blog/2015/04/01/ongoing-support-for-
>> java-7-and-even-java-6>
 for Spring’s perspective on this. Log4j is such a fundamental
>>> framework
 that, while we need to support new features in the latest JDK, we
>>> also
>> need
 to continue to support older Java releases for as long as is
>> reasonable. I
 know a few of you would always like to be on more current JDKs,
>> but I
>> have
 worked in environments that are very slow to upgrade. In fact, we
>>> just
>> got
 a question from someone who is still on 2.2 because they are stuck
>> on
>> Java
 6.
 
 That said, I am all for discussing what a reasonable timeframe is.
>> I
>> don’t
 think 2022 makes any more sense than dropping support in July.
>>> Whatever
>> we
 decide we should give users at least 6 months notice.
 
 Ralph
 
> On Apr 19, 2017, at 5:18 PM, Matt Sicker 
>> wrote:
> 
> Roadmap wise, I think dropping support for Java 7 when Java 9
>> comes
 out
> might make sense, though that also depends on where we are
 release-wise
 at
> the time. In the meantime, modularizing the core more and breaking
 into
> more subprojects may help find any desires for a semantically
>>> breaking
> change for version 3. I don't really see that happening with the
>>> API,
>> and
> I'm not so sure how important it'd be in Core, though they could
>> be
> versioned separately in theory.
> 
>> On 19 April 2017 at 12:59, Gary Gregory 
>> wrote:
>

Re: [log4j] Log4j Java 9 support has been added

[Apache]

You could try using java 9

Sent from my iPad

> On Apr 26, 2017, at 2:20 AM, Mikael Ståldal  wrote:
> 
> Now I cannot build the project in IntelliJ IDEA anymore. It complains that
> lambda expressions are not supported in Java 7 in StackWalkerStackLocator.
> 
> Any suggestions?
> 
> On Fri, Apr 21, 2017 at 10:59 AM, Mikael Ståldal 
> wrote:
> 
>> Should the vendor of the Java 7, 8 and 9 toolchains be "sun"? Shouldn't it
>> be "oracle"?
>> 
>>> On Fri, Apr 21, 2017 at 9:26 AM, Matt Sicker  wrote:
>>> 
>>> 🎉🎉🎉
>>> 
>>> On 21 April 2017 at 01:41, Ralph Goers 
>>> wrote:
>>> 
 I’ve pushed the support for Java 9 and Stackwalker. Java 9 is now
>>> required
 to build Log4j in addition to Java 7.
 
 Ralph
 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
>> 
>> 
>> --
>> [image: MagineTV]
>> 
>> *Mikael Ståldal*
>> Senior software developer
>> 
>> *Magine TV*
>> mikael.stal...@magine.com
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>> 
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not
>> copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>> 
> 
> 
> 
> -- 
> [image: MagineTV]
> 
> *Mikael Ståldal*
> Senior software developer
> 
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
> 
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.

Re: [log4net] git repository is online

[Apache]

I recommend that the git mirror of the sun repo be deleted. It will just 
confuse people.

Ralph

> On Apr 27, 2017, at 12:41 AM, Dominik Psenner  wrote:
> 
> I've just filed a ticket to INFRA to make the svn repository read-only:
> 
> https://issues.apache.org/jira/browse/INFRA-14022
> 
> 
>> On 2017-04-27 09:28, Dominik Psenner wrote:
>> Hi,
>> 
>> I'm pleased to announce that the new git repository for the log4net 
>> subproject is up! It can be found here:
>> 
>> https://git-wip-us.apache.org/repos/asf/logging-log4net.git
>> 
>> github integration is enabled for this repository and therefore it is 
>> mirrored to github here:
>> 
>> https://github.com/apache/logging-log4net
>> 
>> Please do not commit to the svn repository anymore! That repository is about 
>> to go read-only soon.
>> 
>> Here a few things to note and discuss:
>> 
>> 1) Note that the repository at https://github.com/apache/log4net is not a 
>> mirror of the new git repository, but rather a mirror of the svn repository. 
>> We will have to decide now what we want to do with that mirror and all the 
>> open pull requests on that mirror. Please discuss!
>> 
>> 2) Note further that I've not pushed the following heads:
>> 
>> * refs/heads/origin/1.2.12
>> * refs/heads/origin/log4net-1.2.x
>> * refs/heads/origin/log4net-1.3.x
>> 
>> which were originally svn branches. Please discuss what should happen with 
>> those heads!
>> 
>> 3) While converting, I made an error and pushed the head origin/trunk to the 
>> git repository, which was then mirrored to github. It looks like this branch 
>> refuses to go away and I'll need to find a way to remove that head. Please 
>> ignore the branch for now.
>> 
>> Cheers,
>> Dominik
>> 
> 
> 

Re: Java 9 modules

[Apache]

I read that previously but if Log4J implements modules I don't see how the 
nodal appenders or flume appender can work.

I also got a reply to my query about referencing dependencies that are not yet 
modularized and the recommendation is to only use the manifest entry and not 
have a module-info.java until all dependencies are modularized.

> On May 9, 2017, at 12:18 AM, Remko Popma  wrote:
> 
> 
> 
> 
> 
> (Shameless plug) Every java main() method deserves http://picocli.info
>> On May 9, 2017, at 15:35, Gary Gregory  wrote:
>> 
>> Hi All,
>> 
>> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers 
>> wrote:
>> 
>>> So I keep reading up on Java modules and the more I do the more confused I
>>> get about how this can ever work properly.
>>> 
>>> 1. I am confused about how we are supposed to create a module and
>>> reference something that is not yet a module. As I understand it, it will
>>> either be an automatic module on the module path or just be in the
>>> “unnamed” module on the class path. Well, a jar that has made no attempt to
>>> be modularized will be known by the wrong name - essentially the jar file
>>> name without the version so I don’t see how that can just be dropped on the
>>> module path. Also, as I understand it in order for it to be accessed on the
>>> class path we can’t declare a requirement on it (which makes sense I guess
>>> since it isn’t a module), but it means our module declaration is incomplete.
>>> 
>> 
>> For this one, this could be a case where module users will have to wrap
>> jars in a module like some people do in OSGi: wrapping a jar to create a
>> bundle. Eclipse ended up with a whole repository of these. Yikes.
>> 
>> 
>>> 
>>> 2. This one scares me. The module system doesn’t allow circularities. So
>>> picture a case where HttpClient is a module and it uses the Log4j 2 or
>>> SLF4J API (it doesn’t really matter which). Then Log4j has an Appender that
>>> uses HttpClient. Now you have Log4j that has an Appender that uses
>>> HttpClient (so an optional dependency is declared) and then HttpClient uses
>>> Log4j (and so declares that as a dependency) you now have a system that
>>> won’t run. Even if HttpClient uses SLF4J instead you will still have a
>>> problem if that then gets routed to Log4j.
>>> 
>> 
>> Nothing to do about that which is what one of the items the JBoss folks
>> where dismayed about... :-(
> 
> Mark Reinhold's reasoning in his response 
> (http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000695.html)
>  makes sense to me. 
> 
> Also not sure if there really is a problem:
> "Cycles are not allowed when modules are resolved but it is possible to 
> create them post-resolution via the API, if needed [4][5]. Cycles are also 
> set up amongst all automatic modules, after resolution, to make it easier to 
> treat existing JAR files as modules without change [6]."
> 
> 
>> 
>> It's good that we are finding this out early but it sure seems worse and
>> worse :-(
>> 
>> Gary
>> 
>> 
>>> I’ve written to a couple of folks off list but at the moment I’m not clear
>>> on how this can work for libraries like Log4j.
>>> 
>>> Ralph
>>> 
 On Apr 24, 2017, at 7:58 AM, Matt Sicker  wrote:
 
 Support Java 9 modules sounds a lot stricter than OSGi modules.
>>> Essentially
 what is best practices in OSGi is required in JPMS.
 
 Anyways, the ServiceLoader for log4j-api sounds reasonable. The current
 solution is basically a custom version of that with additional metadata
 (the required API version), but we can probably support that differently.
 From what I recall, it's basically two service loaders combined into one.
 
 On 24 April 2017 at 09:22, Mikael Ståldal 
>>> wrote:
 
> Doing things for Java 9 modules that are beneficial also in Java 7/8 is
> good.
> 
> Using Java ServiceLoader seems like a good idea, and we should
>>> definitely
> do it if required to support latest SLF4J.
> 
> I am not so sure about refactoring package the structure though.
>>> Especially
> not if doing so will break BC.
> 
> On Mon, Apr 24, 2017 at 4:00 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
> wrote:
> 
>> It is and it isn’t.  I’ve been working on module support all weekend.
>> There are a couple of changes that must be made before modules can be
>> effectively implemented and IMO it is worth doing them whether we
>>> support
>> modules or not. Note that none of these changes require Java 9.
>> 
>> 1. Modify the API provider mechanism to use Java ServiceLoader. Modules
>> require that the kind of mechanism we are using be implemented with
>> ServiceLoader. However, our current implementation makes this easy and
>> creating a binding for for an implementation is dirt simple.  I will be
>> checking something in for this in the next few days.
>> 2. Refactor our existing package structures. Modules essentially make
>> everything in a pac

Re: Java 9 modules

[Apache]

Technically you are considered modularized just by adding a manifest entry 
providing the module name. But all the packages are exported. You cannot do 
more than that until all your dependencies do at least that much.

Ralph

> On May 9, 2017, at 12:27 AM, Gary Gregory  wrote:
> 
>> On Tue, May 9, 2017 at 12:24 AM, Apache  wrote:
>> 
>> I read that previously but if Log4J implements modules I don't see how the
>> nodal appenders or flume appender can work.
>> 
>> I also got a reply to my query about referencing dependencies that are not
>> yet modularized and the recommendation is to only use the manifest entry
>> and not have a module-info.java until all dependencies are modularized.
>> 
> 
> Am I reading that we should not modularize Log4j 2 until all of its
> dependencies are themselves modularized?
> 
> Gary
> 
>> 
>>> On May 9, 2017, at 12:18 AM, Remko Popma  wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>> On May 9, 2017, at 15:35, Gary Gregory  wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>> wrote:
>>>> 
>>>>> So I keep reading up on Java modules and the more I do the more
>> confused I
>>>>> get about how this can ever work properly.
>>>>> 
>>>>> 1. I am confused about how we are supposed to create a module and
>>>>> reference something that is not yet a module. As I understand it, it
>> will
>>>>> either be an automatic module on the module path or just be in the
>>>>> “unnamed” module on the class path. Well, a jar that has made no
>> attempt to
>>>>> be modularized will be known by the wrong name - essentially the jar
>> file
>>>>> name without the version so I don’t see how that can just be dropped
>> on the
>>>>> module path. Also, as I understand it in order for it to be accessed
>> on the
>>>>> class path we can’t declare a requirement on it (which makes sense I
>> guess
>>>>> since it isn’t a module), but it means our module declaration is
>> incomplete.
>>>>> 
>>>> 
>>>> For this one, this could be a case where module users will have to wrap
>>>> jars in a module like some people do in OSGi: wrapping a jar to create a
>>>> bundle. Eclipse ended up with a whole repository of these. Yikes.
>>>> 
>>>> 
>>>>> 
>>>>> 2. This one scares me. The module system doesn’t allow circularities.
>> So
>>>>> picture a case where HttpClient is a module and it uses the Log4j 2 or
>>>>> SLF4J API (it doesn’t really matter which). Then Log4j has an Appender
>> that
>>>>> uses HttpClient. Now you have Log4j that has an Appender that uses
>>>>> HttpClient (so an optional dependency is declared) and then HttpClient
>> uses
>>>>> Log4j (and so declares that as a dependency) you now have a system that
>>>>> won’t run. Even if HttpClient uses SLF4J instead you will still have a
>>>>> problem if that then gets routed to Log4j.
>>>>> 
>>>> 
>>>> Nothing to do about that which is what one of the items the JBoss folks
>>>> where dismayed about... :-(
>>> 
>>> Mark Reinhold's reasoning in his response (http://mail.openjdk.java.net/
>> pipermail/jpms-spec-experts/2017-May/000695.html) makes sense to me.
>>> 
>>> Also not sure if there really is a problem:
>>> "Cycles are not allowed when modules are resolved but it is possible to
>> create them post-resolution via the API, if needed [4][5]. Cycles are also
>> set up amongst all automatic modules, after resolution, to make it easier
>> to treat existing JAR files as modules without change [6]."
>>> 
>>> 
>>>> 
>>>> It's good that we are finding this out early but it sure seems worse and
>>>> worse :-(
>>>> 
>>>> Gary
>>>> 
>>>> 
>>>>> I’ve written to a couple of folks off list but at the moment I’m not
>> clear
>>>>> on how this can work for libraries like Log4j.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On Apr 24, 2017, at 7:58 AM, Matt Sicker  wrote:
>>>>>> 
>>>>>> Suppor

Re: Java 9 modules

[Apache]

Yes, although we could fully modularize the API right away.

Ralph

> On May 9, 2017, at 12:51 AM, Gary Gregory  wrote:
> 
>> On Tue, May 9, 2017 at 12:34 AM, Apache  wrote:
>> 
>> Technically you are considered modularized just by adding a manifest entry
>> providing the module name. But all the packages are exported. You cannot do
>> more than that until all your dependencies do at least that much.
>> 
> 
> So it's a two-step. First the module name, only when all the deps do it.
> Then some other second step, only when the deps do that too.
> 
> Sounds like it will be a long wait.
> 
> Gary
> 
> 
>> 
>> Ralph
>> 
>>> On May 9, 2017, at 12:27 AM, Gary Gregory 
>> wrote:
>>> 
>>>> On Tue, May 9, 2017 at 12:24 AM, Apache 
>> wrote:
>>>> 
>>>> I read that previously but if Log4J implements modules I don't see how
>> the
>>>> nodal appenders or flume appender can work.
>>>> 
>>>> I also got a reply to my query about referencing dependencies that are
>> not
>>>> yet modularized and the recommendation is to only use the manifest entry
>>>> and not have a module-info.java until all dependencies are modularized.
>>>> 
>>> 
>>> Am I reading that we should not modularize Log4j 2 until all of its
>>> dependencies are themselves modularized?
>>> 
>>> Gary
>>> 
>>>> 
>>>>> On May 9, 2017, at 12:18 AM, Remko Popma 
>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>>>> On May 9, 2017, at 15:35, Gary Gregory 
>> wrote:
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <
>>>> ralph.go...@dslextreme.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> So I keep reading up on Java modules and the more I do the more
>>>> confused I
>>>>>>> get about how this can ever work properly.
>>>>>>> 
>>>>>>> 1. I am confused about how we are supposed to create a module and
>>>>>>> reference something that is not yet a module. As I understand it, it
>>>> will
>>>>>>> either be an automatic module on the module path or just be in the
>>>>>>> “unnamed” module on the class path. Well, a jar that has made no
>>>> attempt to
>>>>>>> be modularized will be known by the wrong name - essentially the jar
>>>> file
>>>>>>> name without the version so I don’t see how that can just be dropped
>>>> on the
>>>>>>> module path. Also, as I understand it in order for it to be accessed
>>>> on the
>>>>>>> class path we can’t declare a requirement on it (which makes sense I
>>>> guess
>>>>>>> since it isn’t a module), but it means our module declaration is
>>>> incomplete.
>>>>>>> 
>>>>>> 
>>>>>> For this one, this could be a case where module users will have to
>> wrap
>>>>>> jars in a module like some people do in OSGi: wrapping a jar to
>> create a
>>>>>> bundle. Eclipse ended up with a whole repository of these. Yikes.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 2. This one scares me. The module system doesn’t allow circularities.
>>>> So
>>>>>>> picture a case where HttpClient is a module and it uses the Log4j 2
>> or
>>>>>>> SLF4J API (it doesn’t really matter which). Then Log4j has an
>> Appender
>>>> that
>>>>>>> uses HttpClient. Now you have Log4j that has an Appender that uses
>>>>>>> HttpClient (so an optional dependency is declared) and then
>> HttpClient
>>>> uses
>>>>>>> Log4j (and so declares that as a dependency) you now have a system
>> that
>>>>>>> won’t run. Even if HttpClient uses SLF4J instead you will still have
>> a
>>>>>>> problem if that then gets routed to Log4j.
>>>>>>> 
>>>>>> 
>>>>>> Nothing to do about that which is what one of the items the JBoss
>> folks
>>>>>> whe

Re: Java 9 modules

[Apache]

It will require that modules that have Log4J plugins declare the package 
containing the plugins as "open" to Log4J.  Apparently we will also have to 
call Module.addReads() to be able to access the module.

Ralph



Sent from my iPad
> On May 10, 2017, at 2:40 AM, Mikael Ståldal  wrote:
> 
> As far as I can see, we use setAccessible in our plugin loader? Can that be
> a problem?
> 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012571.html
> 
> On Wed, May 10, 2017 at 6:34 AM, Ralph Goers 
> wrote:
> 
>> I got further clarification on the jigsaw dev list.
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html <
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html>.
>> I am still waiting for an answer about the impact to our plugin system, but
>> I am pretty sure it will continue to work as is.
>> 
>> It seems that we should be able to make most of the modules be “proper”
>> modules with a few simple changes. The biggest impact will be that we can’t
>> properly modularize log4j-core until Disruptor and Jackson are modules,
>> since we can’t remove those as optional dependencies from core. We should
>> move everything else that has a dependency to other modules. Those will
>> also have to wait to be “proper” modules until their dependencies are, but
>> they can all use the manifest entry to declare their module names.
>> 
>> As for the circularity, there is none because log4j-api will not specify
>> that it requires log4j-core. It will bind to its implementation through a
>> ServiceProvider. I’ve already written that and will commit that portion in
>> a few days. That change doesn’t require Java 9 and will be backward
>> compatible.
>> 
>> As for the actual modularization, I still think we should wait to declare
>> them, at least until the dust settles and we are closer to an actual
>> release. But I think we should continue looking at breaking stuff out of
>> core to make it easier to create the modules when the time comes.
>> 
>> Ralph
>> 
>> 
 On May 9, 2017, at 8:43 AM, Ralph Goers 
>>> wrote:
>>> 
>>> While it may sound reasonable, it is not. Matt’s point about
>> LoggerFinder and our support of NoSQL appenders and the like is proof that
>> there are valid reasons for circularities. We are just lucky that Jackson
>> and Disruptor don’t seem to do logging or we would have circularities there
>> too.
>>> 
>>> BTW - I got a private answer to my question on this. It was that I
>> should post my question to the jigsaw dev list but that I should expect
>> that Log4j - or at least pieces of it - can’t be modularized.
>>> 
>>> Ralph
>>> 
 On May 9, 2017, at 8:24 AM, Gary Gregory 
>> wrote:
 
 On May 9, 2017 12:18 AM, "Remko Popma" > remko.po...@gmail.com>> wrote:
 
 
 Mark Reinhold's reasoning in his response (
>> http://mail.openjdk.java.net/
 pipermail/jpms-spec-experts/2017-May/000695.html) makes sense to me.
 
 
 Sounds reasonable indeed. Reading this latest sounds like JBoss has a
>> lot
 of work to do in order to fit in Java 9 modules from its own module
>> system
 and they'd rather not do more work than less, which is understandable.
>> MR's
 view on a conservative first cut makes sense. It is so late in the Java
>> 9
 timeframe that these change requests seem doomed anyway.
 
 Gary
> 
> 
> -- 
> [image: MagineTV]
> 
> *Mikael Ståldal*
> Senior software developer
> 
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
> 
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.

Re: [Log4j] Recursive logging when an appender's dependency logs itself

[Apache]

How does AppenderControl not prevent recursive logging? If the appender gets 
called a second time on the thread then it will ignore the event.  If the 
appender or Kafka are creating new threads that are logging then you could get 
the behavior you mention, but I don't see how that could be handled 
generically. I think the FlumeAppender may do something to prevent this as well.

Ralph

> On May 11, 2017, at 5:39 AM, Mikael Ståldal  wrote:
> 
> The Kafka appender uses the Kafka client library, and that client library
> does it's own logging through SLF4J, it always emits a few log messages at
> DEBUG level on each message sent.
> 
> If you have log4j-slf4j-impl in classpath and enable DEBUG logging through
> KafkaAppender, you will get recursive logging, and the application gets
> stuck.
> 
> The recursive logging prevention in AppenderControl does not protect
> against this as far as I can see. I have put in some protection in
> KafkaAppender:
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/kafka/KafkaAppender.java#L133
> 
> Without this, you get recursive logging.
> 
> -- 
> [image: MagineTV]
> 
> *Mikael Ståldal*
> Senior software developer
> 
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
> 
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.

Re: [log4j2] org.apache.logging.log4j.message.MapMessage String vs. Object values.

[Apache]

The reason managers were split from the appender sis because appender are 
recreated during reconfiguration while managers are reused.

Ralph

> On Jun 7, 2017, at 1:11 AM, Gary Gregory  wrote:
> 
> Hi All:
> 
> I've completed all the clean ups I think were needed in the
> GenericMapMessageSimple branch (the no-new-class branch).
> 
> I will merge to master tomorrow unless I hear otherwise.
> 
> Then I can look at painful it would be to fix
> https://issues.apache.org/jira/browse/LOG4J2-1934
> 
> Any advice there is appreciated. I thought the whole point of splitting
> code into a manager from its appender was so that it could be reloaded from
> first principles (from the builder data) but I do not see a simple way to
> do that. Do we have an appender/manager pair that does that?
> 
> My thought was that if the appender catches an Exception or detects that
> the manager is stale, it throws it away and re-creates it based on the
> builder data.
> 
> Thank you,
> Gary
> 
>> On Sun, Jun 4, 2017 at 3:34 PM, Matt Sicker  wrote:
>> 
>> Raw type warnings? In my experience, barely anyone even notices them let
>> alone fixes them. :/
>> 
>>> On 4 June 2017 at 16:57, Ralph Goers  wrote:
>>> 
>>> It is reasonable but I really dislike having to tell users they need to
>>> change their code to get rid of the new warnings.
>>> 
>>> Ralph
>>> 
 On Jun 4, 2017, at 9:48 AM, Gary Gregory 
>> wrote:
 
 Hi,
 
 I was about to merger the branch GenericMapMessageSimple when I
>> realized
 something... Right now, all the code compiles and runs cleanly and the
 Clirr check passes.
 
 But...
 
 Because of the new implementation declares MapMessage with generics, we
>>> do
 get compiler warnings about MapMessage not being used with generics.
 
 What I propose is that we declare a subclass called StringMapMessage
>>> which
 allows all call sites to be changed from MapMessage to StringMapMessage
>>> and
 eliminate compiler warnings. For more advanced use cases (like mine), I
>>> can
 use MapMessage with generics or declare my own subclass.
 
 I like MapMessage and a new StringMapMessage subclass better than the
 initial proposal of a new GenericMapMessage and MapMessage subclass.
 
 What do you guys think?
 
 Gary
 
 
 On Sat, Jun 3, 2017 at 9:21 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
 wrote:
 
> It seems OK to me.
> 
> Ralph
> 
>> On Jun 3, 2017, at 6:45 PM, Matt Sicker  wrote:
>> 
>> I like the type erasure allowing for easier BC idea for sure.
>> 
>> On 3 June 2017 at 14:08, Gary Gregory 
>> wrote:
>> 
>>> On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com
>> 
>>> wrote:
>>> 
 From a backward compatibility point of view changing that would be
>> a
 problem. Also, StructuredDataMessage extends MapMessage and
>> expects a
 String. That said, there must be a way to make it generic but have
>>> the
 default be a String.  For example, you could create a
>>> GenericMapMessage
 that expects  and has most or all of the logic from
> MapMessage
 and then have MapMessage extend it as GenericMapMessage.
 
>>> 
>>> Hi,
>>> 
>>> I created two branches:
>>> 
>>> GenericMapMessage adds a class called GenericMapMessage with
>>> MapMessage
> as
>>> the subclass. Clirr check passes
>>> 
>>> GenericMapMessageSimple modifies MapMessage with the same new code
>>> that
> is
>>> in GenericMapMessage. Clirr check passes
>>> 
>>> Since generics are erased, BC should not be an issue i neither case.
>>> The
>>> branch GenericMapMessageSimple is my preference since it does not
>> add
>>> a
> new
>>> class.
>>> 
>>> I opted to add "with" method instead of "put" methods since we
>> already
> have
>>> a "with" method. No need to have both "put" and "with" methods IMO.
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>>> 
 Ralph
 
> On Jun 2, 2017, at 2:04 PM, Gary Gregory 
>>> wrote:
> 
> Hi All:
> 
> We make a big deal that our logger APIs take Object messages
>> instead
> of
> Strings, but over in org.apache.logging.log4j.message.MapMessage
>>> the
 values
> are Strings, not Objects.
> 
> Is that deliberate?
> 
> That's proving to be a restriction for me...
> 
> Any thoughts on allowing for the same kind of typing as in
> javax.jms.MapMessage?
> 
> Thank you,
> 
> Gary
 
 
 
>>> 
>> 
>> 
>> 
>> --
>> Matt Sicker 
> 
> 
> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 

Re: Classes found in the wrong directory: {META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class=org.apache.logging.log4j.util.StackLocator}

[Apache]

If you don't run clean then the OSGi plugin will barf over those classes as it 
does not ignore classes in the "wrong" place, it doesn't support java 9, and it 
doesn't support multi-release jars. I have opened an issue on the Felix maven 
bundle plugin that is being ignored.

Short answer. You have to use clean.

Ralph

> On Jul 6, 2017, at 12:33 AM, Gary Gregory  wrote:
> 
> Hi All,
> 
> When I run certain mvn commands, I get:
> 
> [INFO] --- maven-bundle-plugin:3.3.0:manifest (default) @ log4j-api ---
> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.9-SNAPSHOT :
> Classes found in the wrong directory:
> {META-INF/versions/9/org/apache/logging/log4j/util/
> StackLocator.class=org.apache.logging.log4j.util.StackLocator}
> [ERROR] Error(s) found in manifest configuration
> [INFO]
> 
> 
> The simplest way to reproduce:
> 
> mvn install -DskipTests
> 
> Gary

Re: Classes found in the wrong directory: {META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class=org.apache.logging.log4j.util.StackLocator}

[Apache]

Fwiw, this could be fixed by adding the clean plugin to delete that directory 
on every build

Sent from my iPad

> On Jul 6, 2017, at 12:33 AM, Gary Gregory  wrote:
> 
> Hi All,
> 
> When I run certain mvn commands, I get:
> 
> [INFO] --- maven-bundle-plugin:3.3.0:manifest (default) @ log4j-api ---
> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.9-SNAPSHOT :
> Classes found in the wrong directory:
> {META-INF/versions/9/org/apache/logging/log4j/util/
> StackLocator.class=org.apache.logging.log4j.util.StackLocator}
> [ERROR] Error(s) found in manifest configuration
> [INFO]
> 
> 
> The simplest way to reproduce:
> 
> mvn install -DskipTests
> 
> Gary

Re: Playing with Android...

[Apache]

It already is.

Sent from my iPad

> On Jul 8, 2017, at 5:58 PM, Gary Gregory  wrote:
> 
> We are worst off with our 2.9-SNAPSHOT, I can't even build an app using
> only log4j-api:
> 
> AGPBI: {"kind":"error","text":"Error converting bytecode to dex:\nCause:
> Dex cannot parse version 53 byte code.\nThis is caused by library
> dependencies that have been compiled using Java 8 or above.\nIf you are
> using the \u0027java\u0027 gradle plugin in a library submodule add
> \ntargetCompatibility \u003d \u00271.7\u0027\nsourceCompatibility \u003d
> \u00271.7\u0027\nto that submodule\u0027s build.gradle
> file.","sources":[{}],"original":"UNEXPECTED TOP-LEVEL
> EXCEPTION:\njava.lang.RuntimeException: Exception parsing classes\n\tat
> com.android.dx.command.dexer.Main.processClass(Main.java:781)\n\tat
> com.android.dx.command.dexer.Main.processFileBytes(Main.java:747)\n\tat
> com.android.dx.command.dexer.Main.access$1200(Main.java:88)\n\tat
> com.android.dx.command.dexer.Main$FileBytesConsumer.processFileBytes(Main.java:1689)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)\n\tat
> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)\n\tat
> com.android.dx.command.dexer.Main.processOne(Main.java:695)\n\tat
> com.android.dx.command.dexer.Main.processAllFiles(Main.java:592)\n\tat
> com.android.dx.command.dexer.Main.runMultiDex(Main.java:376)\n\tat
> com.android.dx.command.dexer.Main.run(Main.java:290)\n\tat
> com.android.builder.internal.compiler.DexWrapper.run(DexWrapper.java:54)\n\tat
> com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(DexByteCodeConverter.java:174)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by:
> com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or
> version (0035.)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:476)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)\n\tat
> com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)\n\tat
> com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)\n\tat
> com.android.dx.command.dexer.Main.parseClass(Main.java:793)\n\tat
> com.android.dx.command.dexer.Main.access$1600(Main.java:88)\n\tat
> com.android.dx.command.dexer.Main$ClassParserTask.call(Main.java:1728)\n\tat
> com.android.dx.command.dexer.Main.processClass(Main.java:779)\n\t... 16
> more\n","tool":"Dex"}
> AGPBI: {"kind":"error","text":"1 error; aborting","sources":[{}]}
> 
> Can we split off this Java 9 stuff in a separate module?
> 
> Gary
> 
>> On Sat, Jul 8, 2017 at 4:01 PM, Matt Sicker  wrote:
>> 
>> If you've got some instructions on how to even get an Android project up
>> and running, getting some test code to play with would certainly help. Long
>> ago when I tried debugging some Android issues with Log4j, I couldn't even
>> get that far. :/
>> 
>>> On 8 July 2017 at 17:31, Gary Gregory  wrote:
>>> 
>>> A quick follow up to note that with 2.8.2, using log4j-api does not cause
>>> problems but then adding log4j-core causes the app to fail to start. So I
>>> definitively see an Android epic for 2.10. Maybe this is when we want to
>>> split up log4j-core.
>>> 
>>> Gary
>>> 
>>> On Sat, Jul 8, 2017 at 3:20 PM, Gary Gregory 
>>> wrote:
>>> 
 So here I am with my family our of town on a weekend, and I thought I'd
 give Log4j on Android a try.
 
 The first thing I run into is:
 
 FAILURE: Build failed with an exception.
 
 * What went wrong:
 Execution failed for task ':Application:transformResourcesWithMergeJav
 aResForDebug'.
> com.android.build.api.transform.TransformException:
 com.android.builder.packaging.DuplicateFileException: Duplicate files
 copied in APK META-INF/LICENSE
 File1: C:\Users\ggregory\.gradle\caches\modules-2\files-2.1\
 org.apache.logging.log4j\log4j-core\2.8.2\
>> 979fc0cf8460302e4ffbfe38c1b66a
 99450b0bb7\log4j-core-2.8.2.jar
 File2: C:\Users\ggregory\.gradle\caches\modules-2\files-2.1\
 org.apache.logging.log4j\log4j-api\2.8.2\
>> e590eeb783348ce8ddef205b82127f
 9084d82bf3\log4j-api-2.8.2.jar
 
 
 * Try:
 Run with --stacktrace option to get the stack trace. Run with --info or
 --debug option to get more log output.
 
 BUILD FAILED
 
 Total time: 1.995 secs
 
 which is solved by:
 
 https://stackoverflow.com/questions/37586800/android-
 gradle-duplicate-files-copied-in-apk-meta-inf-license-txt
 
 Which means I have to add this to my build:
 
 packagingOptions {