Re: Logger names for nested classes

[Ralph Goers]

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: Logger names for nested classes

[Ralph Goers]

Yes, that is the way I would envision it. The default would be how it works now.

Ralph

> On Aug 13, 2017, at 12:37 PM, Gary Gregory  wrote:
> 
> Well we can make an exception for trailing $?
> 
> Do we want to add an attribute in the Configuration XML element? For
> example hierarchySeparators=".$/"
> 
> What should the default be?
> 
> Gary
> 
> On Aug 13, 2017 12:17, "Matt Sicker"  wrote:
> 
>> Having the dollar sign interpreted differently also makes a difference in
>> Scala classes and potentially other languages. For example, in Scala, an
>> "object" class is a singleton instance of the class (vaguely similar to a
>> class with all static methods and fields), and it's translated to a Java
>> class name with a dollar sign appended. The Scala code "object Foo { ... }"
>> translates to the equivalent of "public class Foo$ { public static Foo$
>> MODULE$ = new Foo$(); ... }" or something like that.
>> 
>> On 13 August 2017 at 11:08, Apache  wrote:
>> 
>>> 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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 

Log4j 2.9

[Ralph Goers]

I’d like to start the release process next weekend for Log4j 2.9. I believe 
there is some web site work that has to take place for that to happen to 
integrate with the new Scala release. Has Scala been published to the web site? 
I can’t find it in SVN.

Ralph

Re: Log4j 2.9

[Ralph Goers]

If you can get the scala site checked in I can figure out how to do link them.

Ralph

> On Aug 14, 2017, at 7:00 AM, Matt Sicker  wrote:
> 
> The Scala site hasn't been committed to SVN as I wasn't exactly sure how to
> go about integrating it properly. I do think we should get that integrated
> first. I'm not exactly sure where the links should go in the 2.9 version of
> the site as they're no longer components of the release.
> 
> On 14 August 2017 at 00:39, Ralph Goers  wrote:
> 
>> I’d like to start the release process next weekend for Log4j 2.9. I
>> believe there is some web site work that has to take place for that to
>> happen to integrate with the new Scala release. Has Scala been published to
>> the web site? I can’t find it in SVN.
>> 
>> Ralph
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Logger names for nested classes

[Ralph Goers]

> On Aug 14, 2017, at 11:49 AM, Gary Gregory  wrote:
> 
> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 
> wrote:
> 
>> Probably for Ralph:
>> 
>> Right now, it's the LogManager in log4j-api that converts Class names into
>> Logger names.
>> 
>> There is no getLogger(Class) API in the Core LoggerContext.
>> 
>> Should we push down this conversion into Core's LoggerContext?
>> 
>> It seems the sane thing to do to:
>> - Avoid making something pluggable in log4j-api
>> - Avoid making Core parse logger names looking for separators.
>> 
> 
> But that would mean adding two methods to:
> 
> org.apache.logging.log4j.spi.LoggerContext:
> 
> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class)
> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class,
> MessageFactory)
> 
> Thoughts?
> 

Why does it mean that?

Ralph

Re: Logger names for nested classes

[Ralph Goers]

> On Aug 14, 2017, at 1:38 PM, Gary Gregory  wrote:
> 
> On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers  <mailto:ralph.go...@dslextreme.com>>
> wrote:
> 
>> 
>>> On Aug 14, 2017, at 11:49 AM, Gary Gregory 
>> wrote:
>>> 
>>> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 
>>> wrote:
>>> 
>>>> Probably for Ralph:
>>>> 
>>>> Right now, it's the LogManager in log4j-api that converts Class names
>> into
>>>> Logger names.
>>>> 
>>>> There is no getLogger(Class) API in the Core LoggerContext.
>>>> 
>>>> Should we push down this conversion into Core's LoggerContext?
>>>> 
>>>> It seems the sane thing to do to:
>>>> - Avoid making something pluggable in log4j-api
>>>> - Avoid making Core parse logger names looking for separators.
>>>> 
>>> 
>>> But that would mean adding two methods to:
>>> 
>>> org.apache.logging.log4j.spi.LoggerContext:
>>> 
>>> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class)
>>> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class,
>>> MessageFactory)
>>> 
>>> Thoughts?
>>> 
>> 
>> Why does it mean that?
>> 
> 
> If we want the core to implement converting Class names to Logger names,
> the Class must be passed down to the Core. Right now the LogManager does
> that by calling org.apache.logging.log4j.spi.LoggerContext methods. These
> methods take only String for the logger name.

And that is a problem because….?  I am trying to understand why LoggerContext 
will be required to accept a class name.

Ralph

Re: Jenkins build became unstable: Log4j 2.x #2980

[Ralph Goers]

I don’t recall having seen this error before. Did the latest commit break 
something?

Ralph

> On Aug 14, 2017, at 1:12 PM, Apache Jenkins Server 
>  wrote:
> 
> See 
> 
> 
> 

Re: Logger names for nested classes

[Ralph Goers]

I agree.

Ralph

> On Aug 19, 2017, at 11:43 AM, Matt Sicker  wrote:
> 
> Canonical name sounds like it makes sense. I wonder what that evaluates to
> in other JVM languages like Scala, Kotlin, Clojure, etc., but it seems to
> make sense.
> 
> On 19 August 2017 at 13:23, Dominik Psenner  wrote:
> 
>> To me it is a simple and good solution to the problem. The first outlined
>> solution has the pro that it would give a user more sophisticated ways to
>> build logger hierarchies from class names, but it is also something that
>> only a very small subset of users would use. We can keep that as a wish for
>> later.
>> 
>> 2017-08-19 20:13 GMT+02:00 Gary Gregory :
>> 
>>> Any opposition to using the canonical name?
>>> 
>>> Gary
>>> 
>>> On Aug 14, 2017 15:28, "Gary Gregory"  wrote:
>>> 
>>>> In LogManager, if we call getCanonicalName() instead of getName(), we
>>> only
>>>> get "."s, no "$"s...
>>>> 
>>>> How about that?
>>>> 
>>>> Gary
>>>> 
>>>> On Mon, Aug 14, 2017 at 3:24 PM, Gary Gregory 
>>>> wrote:
>>>> 
>>>>> Another way to look at this is that instead of calling class.getName()
>>> we
>>>>> would call our own toLoggerName(Class) which would NOT use $ but only
>>> use
>>>>> "."s.
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Mon, Aug 14, 2017 at 3:07 PM, Matt Sicker 
>> wrote:
>>>>> 
>>>>>> The logger name hierarchy interpretation is handled at the string
>>> level,
>>>>>> not the class level. I don't think the class needs to be passed along
>>> as
>>>>>> there isn't much useful info we can get from the Class instance that
>> we
>>>>>> can't already figure out from its FQCN.
>>>>>> 
>>>>>> On 14 August 2017 at 15:56, Ralph Goers 
>>>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>>> On Aug 14, 2017, at 1:38 PM, Gary Gregory <
>> garydgreg...@gmail.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers <
>>>>>> ralph.go...@dslextreme.com
>>>>>>> <mailto:ralph.go...@dslextreme.com>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Aug 14, 2017, at 11:49 AM, Gary Gregory <
>>> garydgreg...@gmail.com
>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory <
>>>>>> garydgreg...@gmail.com
>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Probably for Ralph:
>>>>>>>>>>> 
>>>>>>>>>>> Right now, it's the LogManager in log4j-api that converts
>> Class
>>>>>> names
>>>>>>>>> into
>>>>>>>>>>> Logger names.
>>>>>>>>>>> 
>>>>>>>>>>> There is no getLogger(Class) API in the Core LoggerContext.
>>>>>>>>>>> 
>>>>>>>>>>> Should we push down this conversion into Core's LoggerContext?
>>>>>>>>>>> 
>>>>>>>>>>> It seems the sane thing to do to:
>>>>>>>>>>> - Avoid making something pluggable in log4j-api
>>>>>>>>>>> - Avoid making Core parse logger names looking for separators.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> But that would mean adding two methods to:
>>>>>>>>>> 
>>>>>>>>>> org.apache.logging.log4j.spi.LoggerContext:
>>>>>>>>>> 
>>>>>>>>>> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class)
>>>>>>>>>> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class,
>>>>>>>>>> MessageFactory)
>>>>>>>>>> 
>>>>>>>>>> Thoughts?
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Why does it mean that?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> If we want the core to implement converting Class names to Logger
>>>>>> names,
>>>>>>>> the Class must be passed down to the Core. Right now the
>> LogManager
>>>>>> does
>>>>>>>> that by calling org.apache.logging.log4j.spi.LoggerContext
>>> methods.
>>>>>>> These
>>>>>>>> methods take only String for the logger name.
>>>>>>> 
>>>>>>> And that is a problem because….?  I am trying to understand why
>>>>>>> LoggerContext will be required to accept a class name.
>>>>>>> 
>>>>>>> Ralph
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Matt Sicker 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Dominik Psenner
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Logger names for nested classes

[Ralph Goers]

And I doubt there are many use cases where doing that will be an issue.

Ralph

> On Aug 19, 2017, at 5:35 PM, Gary Gregory  wrote:
> 
> The only change I am now talking about is replacing getName() with
> getCannonicalName().
> 
> Gary
> 
> On Aug 19, 2017 18:00, "Remko Popma"  wrote:
> 
>> No objection to creating logger names from Class.getCanonicalName() instead
>> of Class.getName(). I assume that this means we don't need a custom
>> toLoggerName(Class)
>> method.
>> 
>> Question for our Scala experts: does Class.getCanonicalName() preserve the
>> trailing $ in Scala classes?
>> 
>> At some point there was talk of API changes. Is that still needed?
>> Finally, I guess in order to keep supporting the current behaviour as well,
>> we still need to build configuration support for this > hierarchySeparators="./$" ... Is my understanding correct?
>> 
>> 
>> On Sun, Aug 20, 2017 at 3:47 AM, Ralph Goers 
>> wrote:
>> 
>>> I agree.
>>> 
>>> Ralph
>>> 
>>>> On Aug 19, 2017, at 11:43 AM, Matt Sicker  wrote:
>>>> 
>>>> Canonical name sounds like it makes sense. I wonder what that evaluates
>>> to
>>>> in other JVM languages like Scala, Kotlin, Clojure, etc., but it seems
>> to
>>>> make sense.
>>>> 
>>>> On 19 August 2017 at 13:23, Dominik Psenner 
>> wrote:
>>>> 
>>>>> To me it is a simple and good solution to the problem. The first
>>> outlined
>>>>> solution has the pro that it would give a user more sophisticated ways
>>> to
>>>>> build logger hierarchies from class names, but it is also something
>> that
>>>>> only a very small subset of users would use. We can keep that as a
>> wish
>>> for
>>>>> later.
>>>>> 
>>>>> 2017-08-19 20:13 GMT+02:00 Gary Gregory :
>>>>> 
>>>>>> Any opposition to using the canonical name?
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Aug 14, 2017 15:28, "Gary Gregory" 
>> wrote:
>>>>>> 
>>>>>>> In LogManager, if we call getCanonicalName() instead of getName(),
>> we
>>>>>> only
>>>>>>> get "."s, no "$"s...
>>>>>>> 
>>>>>>> How about that?
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Mon, Aug 14, 2017 at 3:24 PM, Gary Gregory <
>> garydgreg...@gmail.com
>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Another way to look at this is that instead of calling
>>> class.getName()
>>>>>> we
>>>>>>>> would call our own toLoggerName(Class) which would NOT use $ but
>> only
>>>>>> use
>>>>>>>> "."s.
>>>>>>>> 
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> On Mon, Aug 14, 2017 at 3:07 PM, Matt Sicker 
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> The logger name hierarchy interpretation is handled at the string
>>>>>> level,
>>>>>>>>> not the class level. I don't think the class needs to be passed
>>> along
>>>>>> as
>>>>>>>>> there isn't much useful info we can get from the Class instance
>> that
>>>>> we
>>>>>>>>> can't already figure out from its FQCN.
>>>>>>>>> 
>>>>>>>>> On 14 August 2017 at 15:56, Ralph Goers <
>> ralph.go...@dslextreme.com
>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Aug 14, 2017, at 1:38 PM, Gary Gregory <
>>>>> garydgreg...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers <
>>>>>>>>> ralph.go...@dslextreme.com
>>>>>>>>>> <mailto:ralph.go...@dslextreme.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>

Scala web site

[Ralph Goers]

The Scala web site is now published at 
http://logging.apache.org/log4j/scala/index.html 
. I have modified it to use 
the generic Log4j 2 logo instead of the one for Log4j 2 2.7.  I see 3 options 
for linking to the site:
1. Add a link to the Log4j web site.
2. Add it to the logging home page.
3. Do both.

Personally, I am in favor of number 3 but I don’t want to make that change 
without consensus. I would also like to remove log4j 1 extras from the logging 
home page since it is EOL along with Log4j 1.

Thoughts?

Ralph

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

[Ralph Goers]

I don’t understand why this is failing. My local machine is running build 174. 
Was ProcessHandle.pid() really added that late?

Ralph

> On Aug 20, 2017, at 7:51 PM, Apache Jenkins Server 
>  wrote:
> 
> See 
> 
> 
> 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 
> 
>> 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 
>  
> -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],
>  
> 
>  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],
>  
> 
>  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 
> ( points at 
> org.apache.logging.log4j:log4j instead of org.apache.logging:logging-parent, 
> please verify your project structure @ line 19, column 11
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO] 
> [INFO] Apach

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

[Ralph Goers]

I have posted to infra to try to find out how to determine what the Java home 
path needs to be.  However, my experience is that questions posted to the infra 
list never get answered so I may have to create a Jira issue.

Ralph

> On Aug 21, 2017, at 8:33 AM, Apache Jenkins Server 
>  wrote:
> 
> See 
> 
> 
> Changes:
> 
> [rgoers] Update java build number
> 
> --
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on H22 (couchdbtest ubuntu xenial) in workspace 
> 
>> 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 303e4489ffd9e602b64c2c7a1386a1fec5b520c3 
> (refs/remotes/origin/master)
> Commit message: "Update java build number"
>> git config core.sparsecheckout # timeout=10
>> git checkout -f 303e4489ffd9e602b64c2c7a1386a1fec5b520c3
>> git rev-list bc59293a72ea5c2102e3ef2877041d47b0990cc8 # 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 35131
> 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 35131
> 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 
>  
> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -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],
>  
> 
>  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],
>  
> 
>  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 
> ( points at 
> org.apache.logging.log4j:log4j instead of org.apache.logging:logging-parent, 
> please verify your project structure @ line 19, column 11
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO] 
> [INFO] Apache Log4j 2

Jenkins JDKs

[Ralph Goers]

For future reference - 
https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix 


Ralph

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Ralph Goers]

Did you ask this question last week?  Why is it needed? Why can’t this be 
handled in LogManager?

Ralph

> On Aug 21, 2017, at 2:10 PM, Gary Gregory  wrote:
> 
> Hi All:
> 
> I have a need for the shortcut method
> org.apache.logging.log4j.core.LoggerContext getLogger(Class) which would
> use getCannonicalName().
> 
> Any objection to adding that?
> 
> Gary

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Ralph Goers]

So you are saying that your application is getting Loggers by doing 
LoggerContext.getLogger()?  I guess I don’t really understand why that is a 
good idea. Are you saying you have your own custom LoggerContext and that you 
want to modify Log4j’s LoggerContext simply so you can modify yours?

Ralph

> On Aug 21, 2017, at 3:01 PM, Gary Gregory  wrote:
> 
> My use case is that deep in the guts and call stack of my server/app, I
> have a specific Core LoggerContext that I should/must use. Log4j and other
> components must co-exist in a long-lived server that have modules that are
> constantly re-initialized/re-configured during development and testing
> phases. During acceptance and production, the are fewer reconfigurations,
> but they do happen. The bottom line is that most logging code dishes out
> Loggers out of specific LoggerContext instances and not out of the
> LogManager classes (only in a few rare places.)
> 
> Gary
> 
> On Mon, Aug 21, 2017 at 3:47 PM, Ralph Goers 
> wrote:
> 
>> Did you ask this question last week?  Why is it needed? Why can’t this be
>> handled in LogManager?
>> 
>> Ralph
>> 
>>> On Aug 21, 2017, at 2:10 PM, Gary Gregory 
>> wrote:
>>> 
>>> Hi All:
>>> 
>>> I have a need for the shortcut method
>>> org.apache.logging.log4j.core.LoggerContext getLogger(Class) which would
>>> use getCannonicalName().
>>> 
>>> Any objection to adding that?
>>> 
>>> Gary
>> 
>> 
>> 

Re: [log4j2] sys props driving me nuts

[Ralph Goers]

I plan on starting the 2.9 release any day…

Ralph

> On Aug 21, 2017, at 3:25 PM, Gary Gregory  wrote:
> 
> On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory 
> wrote:
> 
>> On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker  wrote:
>> 
>>> I haven't been able to get to this so far this week. Been finishing up a
>>> project for work. I should hopefully have enough time to merge this
>>> tomorrow though.
>>> 
>> 
>> Thank you for the update Matt.
>> 
> 
> Hi Matt,
> 
> Any chance of this getting in this week?
> 
> Thank you,
> Gary
> 
> 
>> 
>> Gary
>> 
>> 
>>> 
>>> On 16 July 2017 at 14:36, Gary Gregory  wrote:
>>> 
 On Sun, Jul 16, 2017 at 12:29 PM, Matt Sicker  wrote:
 
> I don't think I'll have time to manage the merge conflicts today,
>>> though
 I
> can shoot for tomorrow.
> 
 
 That's great. I just wanted to check that it was still on your near term
 to-do list.
 
 Gary
 
 
> 
> On 16 July 2017 at 14:14, Gary Gregory 
>>> wrote:
> 
>> HI Matt,
>> 
>> Do you still plan to do this over this weekend?
>> 
>> Thank you,
>> Gary
>> 
>> On Sun, Jul 16, 2017 at 10:02 AM, Matt Sicker 
 wrote:
>> 
>>> I found the issues:
>>> 
>>> https://issues.apache.org/jira/browse/LOG4J2-1431 (for the system
>>> properties normalization)
>>> https://issues.apache.org/jira/browse/LOG4J2-1809 (for the
 supporting
>> API
>>> addition to log4j-api)
>>> 
>>> On 14 July 2017 at 15:52, Gary Gregory 
 wrote:
>>> 
 On Fri, Jul 14, 2017 at 1:49 PM, Matt Sicker 
> wrote:
 
> The old names are all translated to normalized names via some
> magical
> regular expressions from what I recall. I should have some
>>> time
 to
>> work
 on
> Log4j stuff this weekend, so I'll try to get that merged as
>>> well.
> 
 
 Thank you sir.
 
 Gary
 
 
> 
> On 14 July 2017 at 15:48, Gary Gregory <
>>> garydgreg...@gmail.com>
>> wrote:
> 
>> Merge it! :-)
>> 
>> Did you bother to keep the old names for compat?
>> 
>> G
>> 
>> On Fri, Jul 14, 2017 at 1:47 PM, Matt Sicker <
>>> boa...@gmail.com
> 
>>> wrote:
>> 
>>> I have an open branch that fixes all this. The only
>>> remaining
>> work
> there
>> is
>>> to clean up merge conflicts and update the documentation
>>> to
 use
> log4j2.*
>>> everywhere.
>>> 
>>> On 14 July 2017 at 15:46, Gary Gregory <
 garydgreg...@gmail.com
>> 
 wrote:
>>> 
 Hi All,
 
 Our sys prop naming is driving me nuts!
 
 Sometimes it's "log4j.foo", sometimes it's
>>> "log4j*2*.bar",
 sometimes
>> its
 "bar". WTF!
 
 Can we just PLEASE bite the bullet and make it all
 "log4j2."
> or
>>> _something_
 
 We could keep the existing names for compat (TDB).
 
 ?
 
 Gary
 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
> 
> 
> 
> --
> Matt Sicker 
> 
 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
> 
> 
> 
> --
> Matt Sicker 
> 
 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
>> 

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Ralph Goers]

It is actually funny that you say that. The API we provide for performing 
logging is log4j-api, not log4j-core. We provide access in log4j-core for users 
to customize how they configure their logging - not perform it.

Ralph

> On Aug 21, 2017, at 3:42 PM, Gary Gregory  wrote:
> 
> Hi,
> 
> When someone calls any of the init methods like
> org.apache.logging.log4j.core.config.Configurator.initialize(String,
> ClassLoader, String), you get a Core LoggerContext, and that's what you've
> got to work with... Why is that a bad idea? That's the API we provide.
> 
> Gary
> 
> On Mon, Aug 21, 2017 at 4:30 PM, Ralph Goers 
> wrote:
> 
>> So you are saying that your application is getting Loggers by doing
>> LoggerContext.getLogger()?  I guess I don’t really understand why that is a
>> good idea. Are you saying you have your own custom LoggerContext and that
>> you want to modify Log4j’s LoggerContext simply so you can modify yours?
>> 
>> Ralph
>> 
>>> On Aug 21, 2017, at 3:01 PM, Gary Gregory 
>> wrote:
>>> 
>>> My use case is that deep in the guts and call stack of my server/app, I
>>> have a specific Core LoggerContext that I should/must use. Log4j and
>> other
>>> components must co-exist in a long-lived server that have modules that
>> are
>>> constantly re-initialized/re-configured during development and testing
>>> phases. During acceptance and production, the are fewer reconfigurations,
>>> but they do happen. The bottom line is that most logging code dishes out
>>> Loggers out of specific LoggerContext instances and not out of the
>>> LogManager classes (only in a few rare places.)
>>> 
>>> Gary
>>> 
>>> On Mon, Aug 21, 2017 at 3:47 PM, Ralph Goers >> 
>>> wrote:
>>> 
>>>> Did you ask this question last week?  Why is it needed? Why can’t this
>> be
>>>> handled in LogManager?
>>>> 
>>>> Ralph
>>>> 
>>>>> On Aug 21, 2017, at 2:10 PM, Gary Gregory 
>>>> wrote:
>>>>> 
>>>>> Hi All:
>>>>> 
>>>>> I have a need for the shortcut method
>>>>> org.apache.logging.log4j.core.LoggerContext getLogger(Class) which
>> would
>>>>> use getCannonicalName().
>>>>> 
>>>>> Any objection to adding that?
>>>>> 
>>>>> Gary
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Ralph Goers]

I am against encouraging users to directly acquire a Logger.

Ralph


> On Aug 21, 2017, at 5:24 PM, Gary Gregory  wrote:
> 
> On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers 
> wrote:
> 
>> It is actually funny that you say that. The API we provide for performing
>> logging is log4j-api, not log4j-core. We provide access in log4j-core for
>> users to customize how they configure their logging - not perform it.
>> 
> 
> I'm all about humoring the ML :-)
> 
> Any further thoughts on adding these APIs? For or against?
> 
> Gary
> 
>> 
>> Ralph
>> 
>>> On Aug 21, 2017, at 3:42 PM, Gary Gregory 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> When someone calls any of the init methods like
>>> org.apache.logging.log4j.core.config.Configurator.initialize(String,
>>> ClassLoader, String), you get a Core LoggerContext, and that's what
>> you've
>>> got to work with... Why is that a bad idea? That's the API we provide.
>>> 
>>> Gary
>>> 
>>> On Mon, Aug 21, 2017 at 4:30 PM, Ralph Goers >> 
>>> wrote:
>>> 
>>>> So you are saying that your application is getting Loggers by doing
>>>> LoggerContext.getLogger()?  I guess I don’t really understand why that
>> is a
>>>> good idea. Are you saying you have your own custom LoggerContext and
>> that
>>>> you want to modify Log4j’s LoggerContext simply so you can modify yours?
>>>> 
>>>> Ralph
>>>> 
>>>>> On Aug 21, 2017, at 3:01 PM, Gary Gregory 
>>>> wrote:
>>>>> 
>>>>> My use case is that deep in the guts and call stack of my server/app, I
>>>>> have a specific Core LoggerContext that I should/must use. Log4j and
>>>> other
>>>>> components must co-exist in a long-lived server that have modules that
>>>> are
>>>>> constantly re-initialized/re-configured during development and testing
>>>>> phases. During acceptance and production, the are fewer
>> reconfigurations,
>>>>> but they do happen. The bottom line is that most logging code dishes
>> out
>>>>> Loggers out of specific LoggerContext instances and not out of the
>>>>> LogManager classes (only in a few rare places.)
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Mon, Aug 21, 2017 at 3:47 PM, Ralph Goers <
>> ralph.go...@dslextreme.com
>>>>> 
>>>>> wrote:
>>>>> 
>>>>>> Did you ask this question last week?  Why is it needed? Why can’t this
>>>> be
>>>>>> handled in LogManager?
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Aug 21, 2017, at 2:10 PM, Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi All:
>>>>>>> 
>>>>>>> I have a need for the shortcut method
>>>>>>> org.apache.logging.log4j.core.LoggerContext getLogger(Class) which
>>>> would
>>>>>>> use getCannonicalName().
>>>>>>> 
>>>>>>> Any objection to adding that?
>>>>>>> 
>>>>>>> Gary
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Ralph Goers]

I would say look at http://logging.apache.org/log4j/2.x/ 
<http://logging.apache.org/log4j/2.x/> and that paragraph entitled “API 
Separation”. Then look at http://logging.apache.org/log4j/2.x/manual/api.html 
<http://logging.apache.org/log4j/2.x/manual/api.html>. The first paragraph 
makes it clear what our intent is. It should be telling that nowhere on that 
page is the LoggerContext mentioned. It isn’t until you get to the 
Configuration section that LoggerContext APIs are discussed. 

So the intent of the design is that code that is performing logging sticks to 
the Log4j API - providing it with a guarantee of backward compatibility. In a 
lot of cases no custom configuration is needed and so the whole application 
will be compatible no matter what we change internally.  That doesn’t mean that 
getLogger() cannot be called - but IMO applications should never be calling it 
for “normal" logging operations.

All of that said, I wouldn’t veto a code commit to do what you want. It is just 
not something I’d consider as a worst practice if I found it in someone’s code 
for “normal” logging and I would strongly recommend they change it.

Ralph

> On Aug 21, 2017, at 6:45 PM, Gary Gregory  wrote:
> 
> Hi Ralph,
> 
> Would you say that is your opinion or the intent of the design? And if the
> latter, should we adjust the Javadoc accordingly.
> 
> Gary
> 
> On Mon, Aug 21, 2017 at 7:31 PM, Ralph Goers 
> wrote:
> 
>> I am against encouraging users to directly acquire a Logger.
>> 
>> Ralph
>> 
>> 
>>> On Aug 21, 2017, at 5:24 PM, Gary Gregory 
>> wrote:
>>> 
>>> On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers >> 
>>> wrote:
>>> 
>>>> It is actually funny that you say that. The API we provide for
>> performing
>>>> logging is log4j-api, not log4j-core. We provide access in log4j-core
>> for
>>>> users to customize how they configure their logging - not perform it.
>>>> 
>>> 
>>> I'm all about humoring the ML :-)
>>> 
>>> Any further thoughts on adding these APIs? For or against?
>>> 
>>> Gary
>>> 
>>>> 
>>>> Ralph
>>>> 
>>>>> On Aug 21, 2017, at 3:42 PM, Gary Gregory 
>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> When someone calls any of the init methods like
>>>>> org.apache.logging.log4j.core.config.Configurator.initialize(String,
>>>>> ClassLoader, String), you get a Core LoggerContext, and that's what
>>>> you've
>>>>> got to work with... Why is that a bad idea? That's the API we provide.
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Mon, Aug 21, 2017 at 4:30 PM, Ralph Goers <
>> ralph.go...@dslextreme.com
>>>>> 
>>>>> wrote:
>>>>> 
>>>>>> So you are saying that your application is getting Loggers by doing
>>>>>> LoggerContext.getLogger()?  I guess I don’t really understand why that
>>>> is a
>>>>>> good idea. Are you saying you have your own custom LoggerContext and
>>>> that
>>>>>> you want to modify Log4j’s LoggerContext simply so you can modify
>> yours?
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Aug 21, 2017, at 3:01 PM, Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>> My use case is that deep in the guts and call stack of my
>> server/app, I
>>>>>>> have a specific Core LoggerContext that I should/must use. Log4j and
>>>>>> other
>>>>>>> components must co-exist in a long-lived server that have modules
>> that
>>>>>> are
>>>>>>> constantly re-initialized/re-configured during development and
>> testing
>>>>>>> phases. During acceptance and production, the are fewer
>>>> reconfigurations,
>>>>>>> but they do happen. The bottom line is that most logging code dishes
>>>> out
>>>>>>> Loggers out of specific LoggerContext instances and not out of the
>>>>>>> LogManager classes (only in a few rare places.)
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Mon, Aug 21, 2017 at 3:47 PM, Ralph Goers <
>>>> ralph.go...@dslextreme.com
>>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Did you ask this question last week?  Why is it needed? Why can’t
>> this
>>>>>> be
>>>>>>>> handled in LogManager?
>>>>>>>> 
>>>>>>>> Ralph
>>>>>>>> 
>>>>>>>>> On Aug 21, 2017, at 2:10 PM, Gary Gregory 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi All:
>>>>>>>>> 
>>>>>>>>> I have a need for the shortcut method
>>>>>>>>> org.apache.logging.log4j.core.LoggerContext getLogger(Class) which
>>>>>> would
>>>>>>>>> use getCannonicalName().
>>>>>>>>> 
>>>>>>>>> Any objection to adding that?
>>>>>>>>> 
>>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

[Ralph Goers]

“Out of bounds” is not the correct statement. Unnecessary is.  We already 
convert the class name to a String in the API so there is no reason to have 
that method.

Ralph

> On Aug 22, 2017, at 8:32 AM, Gary Gregory  wrote:
> 
> Hi Ralph,
> 
> I looked over the links and I (still) do understand the separation and I
> have a follow up question below.
> 
> First, to be precise, I am proposing to add this shorthand method (note
> there is no @Override to ease compatibility, so no change to
> org.apache.logging.log4j.spi.LoggerContext):
> 
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> index cd15dce..8002853 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> @@ -410,6 +410,17 @@
> }
> 
> /**
> + * Returns a Logger using the fully qualified name of the Class as the
> Logger name.
> + *
> + * @param clazz The Class whose name should be used as the Logger
> name. If null it will default to the calling
> + *class.
> + * @return The Logger.
> + */
> +public Logger getLogger(final Class clazz) {
> +return getLogger(clazz.getCanonicalName(), null);
> +}
> +
> +/**
>  * Gets a Logger from the Context.
>  *
>  * @param name The name of the Logger to return.
> 
> Regardless of the above, would you say that the interface
> org.apache.logging.log4j.spi.LoggerContext is also "out of bounds" for
> normal/non-advanced use cases of "get me a logger" even though it is in the
> log4j-api module?
> 
> Thank you again!
> Gary
> 
> 
> On Mon, Aug 21, 2017 at 10:34 PM, Gary Gregory 
> wrote:
> 
>> On Mon, Aug 21, 2017 at 10:27 PM, Ralph Goers 
>> wrote:
>> 
>>> I would say look at http://logging.apache.org/log4j/2.x/ <
>>> http://logging.apache.org/log4j/2.x/> and that paragraph entitled “API
>>> Separation”. Then look at http://logging.apache.org/log4
>>> j/2.x/manual/api.html <http://logging.apache.org/log
>>> 4j/2.x/manual/api.html>. The first paragraph makes it clear what our
>>> intent is. It should be telling that nowhere on that page is the
>>> LoggerContext mentioned. It isn’t until you get to the Configuration
>>> section that LoggerContext APIs are discussed.
>>> 
>>> So the intent of the design is that code that is performing logging
>>> sticks to the Log4j API - providing it with a guarantee of backward
>>> compatibility. In a lot of cases no custom configuration is needed and so
>>> the whole application will be compatible no matter what we change
>>> internally.  That doesn’t mean that getLogger() cannot be called - but IMO
>>> applications should never be calling it for “normal" logging operations.
>>> 
>>> All of that said, I wouldn’t veto a code commit to do what you want. It
>>> is just not something I’d consider as a worst practice if I found it in
>>> someone’s code for “normal” logging and I would strongly recommend they
>>> change it.
>>> 
>> 
>> Thanks for the details. I'll read up on the links and sleep on it.
>> 
>> Gary
>> 
>> 
>>> 
>>> Ralph
>>> 
>>>> On Aug 21, 2017, at 6:45 PM, Gary Gregory 
>>> wrote:
>>>> 
>>>> Hi Ralph,
>>>> 
>>>> Would you say that is your opinion or the intent of the design? And if
>>> the
>>>> latter, should we adjust the Javadoc accordingly.
>>>> 
>>>> Gary
>>>> 
>>>> On Mon, Aug 21, 2017 at 7:31 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
>>>> wrote:
>>>> 
>>>>> I am against encouraging users to directly acquire a Logger.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>> 
>>>>>> On Aug 21, 2017, at 5:24 PM, Gary Gregory 
>>>>> wrote:
>>>>>> 
>>>>>> On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> It is actually funny that you say that. The API we provide for
>>>>> performing
>>>>>>> logging is log4j-api, not log4j-core. We provide access in log4j-core
>>>>> for
>>>>>>> 

Re: Scala web site

[Ralph Goers]

I have already added the link to the Log4j site.xml so it will be there when I 
do the release.  Modifying the main site should be pretty easy to do.

Ralph

> On Aug 24, 2017, at 1:05 PM, Mikael Ståldal  wrote:
> 
> 3. Do both seems fine to me.
> 
> 
> On 2017-08-20 20:08, Ralph Goers wrote:
>> The Scala web site is now published at 
>> http://logging.apache.org/log4j/scala/index.html 
>> <http://logging.apache.org/log4j/scala/index.html>. I have modified it to 
>> use the generic Log4j 2 logo instead of the one for Log4j 2 2.7.  I see 3 
>> options for linking to the site:
>> 1. Add a link to the Log4j web site.
>> 2. Add it to the logging home page.
>> 3. Do both.
>> Personally, I am in favor of number 3 but I don’t want to make that change 
>> without consensus. I would also like to remove log4j 1 extras from the 
>> logging home page since it is EOL along with Log4j 1.
>> Thoughts?
>> Ralph
> 
> 

Re: [log4j2] sys props driving me nuts

[Ralph Goers]

I am just about to start the release build of 2.9 so please hold off on 
committing.

Ralph

> On Aug 26, 2017, at 10:54 AM, Matt Sicker  wrote:
> 
> I've finally got some time this weekend and am working on merging this
> today. Strangely enough, my old branch merged with no git merge conflicts,
> so it shouldn't be too hard to integrate at this point. I'll be handling
> documentation updates along with trying to copy over all the old property
> names into a full unit test to verify the old names always work in the
> future for BC.
> 
> On 23 August 2017 at 14:59, Gary Gregory  wrote:
> 
>> I hope you fell better soon Matt.
>> 
>> Gary
>> 
>> On Wed, Aug 23, 2017 at 12:35 PM, Matt Sicker  wrote:
>> 
>>> May not get a chance to work on this tonight. Haven't been feeling too
>> well
>>> today or yesterday. :(
>>> 
>>> On 21 August 2017 at 18:38, Matt Sicker  wrote:
>>> 
>>>> I won't be free until Wednesday night at the earliest. If Ralph wants
>> to
>>>> start the release before that, I'm alright with that.
>>>> 
>>>> On 21 August 2017 at 17:43, Gary Gregory 
>> wrote:
>>>> 
>>>>> Sweet. I've been going through the back log and picking some
>> low-hanging
>>>>> fruit as you may have noticed. Maybe others could do the same.
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Mon, Aug 21, 2017 at 4:31 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
>>>>> wrote:
>>>>> 
>>>>>> I plan on starting the 2.9 release any day…
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Aug 21, 2017, at 3:25 PM, Gary Gregory >> 
>>>>>> wrote:
>>>>>>> 
>>>>>>> On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory <
>>> garydgreg...@gmail.com
>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker 
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I haven't been able to get to this so far this week. Been
>>> finishing
>>>>> up
>>>>>> a
>>>>>>>>> project for work. I should hopefully have enough time to merge
>>> this
>>>>>>>>> tomorrow though.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thank you for the update Matt.
>>>>>>>> 
>>>>>>> 
>>>>>>> Hi Matt,
>>>>>>> 
>>>>>>> Any chance of this getting in this week?
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> Gary
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 16 July 2017 at 14:36, Gary Gregory 
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On Sun, Jul 16, 2017 at 12:29 PM, Matt Sicker <
>> boa...@gmail.com>
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I don't think I'll have time to manage the merge conflicts
>>> today,
>>>>>>>>> though
>>>>>>>>>> I
>>>>>>>>>>> can shoot for tomorrow.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> That's great. I just wanted to check that it was still on your
>>> near
>>>>>> term
>>>>>>>>>> to-do list.
>>>>>>>>>> 
>>>>>>>>>> Gary
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 16 July 2017 at 14:14, Gary Gregory <
>> garydgreg...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> HI Matt,
>>>>>>>>>>>> 
>>>>>>>>>>>> Do you still plan to do this over this weekend?
>>>>>

Re: [log4j2] sys props driving me nuts

[Ralph Goers]

Scratch that. It seems Log4j now has a dependency on log4j-server? That must be 
released before a release build can be run. Why does the main project have a 
dependency on that?

Ralph

> On Aug 26, 2017, at 11:21 AM, Ralph Goers  wrote:
> 
> 
> I am just about to start the release build of 2.9 so please hold off on 
> committing.
> 
> Ralph
> 
>> On Aug 26, 2017, at 10:54 AM, Matt Sicker  wrote:
>> 
>> I've finally got some time this weekend and am working on merging this
>> today. Strangely enough, my old branch merged with no git merge conflicts,
>> so it shouldn't be too hard to integrate at this point. I'll be handling
>> documentation updates along with trying to copy over all the old property
>> names into a full unit test to verify the old names always work in the
>> future for BC.
>> 
>> On 23 August 2017 at 14:59, Gary Gregory  wrote:
>> 
>>> I hope you fell better soon Matt.
>>> 
>>> Gary
>>> 
>>> On Wed, Aug 23, 2017 at 12:35 PM, Matt Sicker  wrote:
>>> 
>>>> May not get a chance to work on this tonight. Haven't been feeling too
>>> well
>>>> today or yesterday. :(
>>>> 
>>>> On 21 August 2017 at 18:38, Matt Sicker  wrote:
>>>> 
>>>>> I won't be free until Wednesday night at the earliest. If Ralph wants
>>> to
>>>>> start the release before that, I'm alright with that.
>>>>> 
>>>>> On 21 August 2017 at 17:43, Gary Gregory 
>>> wrote:
>>>>> 
>>>>>> Sweet. I've been going through the back log and picking some
>>> low-hanging
>>>>>> fruit as you may have noticed. Maybe others could do the same.
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Mon, Aug 21, 2017 at 4:31 PM, Ralph Goers <
>>>> ralph.go...@dslextreme.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> I plan on starting the 2.9 release any day…
>>>>>>> 
>>>>>>> Ralph
>>>>>>> 
>>>>>>>> On Aug 21, 2017, at 3:25 PM, Gary Gregory >>> 
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory <
>>>> garydgreg...@gmail.com
>>>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker 
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I haven't been able to get to this so far this week. Been
>>>> finishing
>>>>>> up
>>>>>>> a
>>>>>>>>>> project for work. I should hopefully have enough time to merge
>>>> this
>>>>>>>>>> tomorrow though.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thank you for the update Matt.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Matt,
>>>>>>>> 
>>>>>>>> Any chance of this getting in this week?
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Gary
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 16 July 2017 at 14:36, Gary Gregory 
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> On Sun, Jul 16, 2017 at 12:29 PM, Matt Sicker <
>>> boa...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> I don't think I'll have time to manage the merge conflicts
>>>> today,
>>>>>>>>>> though
>>>>>>>>>>> I
>>>>>>>>>>>> can shoot for tomorrow.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> That's great. I just wanted to check that it was still on your
>>>> near
>>>>>>> term
>>>>>>>>>&g

Re: [log4j2] sys props driving me nuts

[Ralph Goers]

I moved the test classes that were dependent on log4j-server to that project.

Ralph

> On Aug 26, 2017, at 11:27 AM, Ralph Goers  wrote:
> 
> Scratch that. It seems Log4j now has a dependency on log4j-server? That must 
> be released before a release build can be run. Why does the main project have 
> a dependency on that?
> 
> Ralph
> 
>> On Aug 26, 2017, at 11:21 AM, Ralph Goers  wrote:
>> 
>> 
>> I am just about to start the release build of 2.9 so please hold off on 
>> committing.
>> 
>> Ralph
>> 
>>> On Aug 26, 2017, at 10:54 AM, Matt Sicker  wrote:
>>> 
>>> I've finally got some time this weekend and am working on merging this
>>> today. Strangely enough, my old branch merged with no git merge conflicts,
>>> so it shouldn't be too hard to integrate at this point. I'll be handling
>>> documentation updates along with trying to copy over all the old property
>>> names into a full unit test to verify the old names always work in the
>>> future for BC.
>>> 
>>> On 23 August 2017 at 14:59, Gary Gregory  wrote:
>>> 
>>>> I hope you fell better soon Matt.
>>>> 
>>>> Gary
>>>> 
>>>> On Wed, Aug 23, 2017 at 12:35 PM, Matt Sicker  wrote:
>>>> 
>>>>> May not get a chance to work on this tonight. Haven't been feeling too
>>>> well
>>>>> today or yesterday. :(
>>>>> 
>>>>> On 21 August 2017 at 18:38, Matt Sicker  wrote:
>>>>> 
>>>>>> I won't be free until Wednesday night at the earliest. If Ralph wants
>>>> to
>>>>>> start the release before that, I'm alright with that.
>>>>>> 
>>>>>> On 21 August 2017 at 17:43, Gary Gregory 
>>>> wrote:
>>>>>> 
>>>>>>> Sweet. I've been going through the back log and picking some
>>>> low-hanging
>>>>>>> fruit as you may have noticed. Maybe others could do the same.
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Mon, Aug 21, 2017 at 4:31 PM, Ralph Goers <
>>>>> ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I plan on starting the 2.9 release any day…
>>>>>>>> 
>>>>>>>> Ralph
>>>>>>>> 
>>>>>>>>> On Aug 21, 2017, at 3:25 PM, Gary Gregory >>>> 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory <
>>>>> garydgreg...@gmail.com
>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker 
>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I haven't been able to get to this so far this week. Been
>>>>> finishing
>>>>>>> up
>>>>>>>> a
>>>>>>>>>>> project for work. I should hopefully have enough time to merge
>>>>> this
>>>>>>>>>>> tomorrow though.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thank you for the update Matt.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Matt,
>>>>>>>>> 
>>>>>>>>> Any chance of this getting in this week?
>>>>>>>>> 
>>>>>>>>> Thank you,
>>>>>>>>> Gary
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Gary
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 16 July 2017 at 14:36, Gary Gregory 
>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Sun, Jul 16, 2017 at 12:29 PM, Matt Sicker <
>>>> boa...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>

Re: [log4j2] sys props driving me nuts

[Ralph Goers]

I have restarted the release build.

Ralph

> On Aug 26, 2017, at 12:29 PM, Matt Sicker  wrote:
> 
> Should I update the @since to 2.9.1 then, or is the release on hold for
> now? I've got the code working and docs are pretty updated at this point.
> 
> On 26 August 2017 at 14:14, Gary Gregory  wrote:
> 
>> IMO, the simplest solution is to bring log4j-server back into the main
>> repo.
>> 
>> Gary
>> 
>> On Aug 26, 2017 12:27, "Ralph Goers"  wrote:
>> 
>>> Scratch that. It seems Log4j now has a dependency on log4j-server? That
>>> must be released before a release build can be run. Why does the main
>>> project have a dependency on that?
>>> 
>>> Ralph
>>> 
>>>> On Aug 26, 2017, at 11:21 AM, Ralph Goers 
>>> wrote:
>>>> 
>>>> 
>>>> I am just about to start the release build of 2.9 so please hold off on
>>> committing.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Aug 26, 2017, at 10:54 AM, Matt Sicker  wrote:
>>>>> 
>>>>> I've finally got some time this weekend and am working on merging this
>>>>> today. Strangely enough, my old branch merged with no git merge
>>> conflicts,
>>>>> so it shouldn't be too hard to integrate at this point. I'll be
>> handling
>>>>> documentation updates along with trying to copy over all the old
>>> property
>>>>> names into a full unit test to verify the old names always work in the
>>>>> future for BC.
>>>>> 
>>>>> On 23 August 2017 at 14:59, Gary Gregory 
>>> wrote:
>>>>> 
>>>>>> I hope you fell better soon Matt.
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Wed, Aug 23, 2017 at 12:35 PM, Matt Sicker 
>>> wrote:
>>>>>> 
>>>>>>> May not get a chance to work on this tonight. Haven't been feeling
>> too
>>>>>> well
>>>>>>> today or yesterday. :(
>>>>>>> 
>>>>>>> On 21 August 2017 at 18:38, Matt Sicker  wrote:
>>>>>>> 
>>>>>>>> I won't be free until Wednesday night at the earliest. If Ralph
>> wants
>>>>>> to
>>>>>>>> start the release before that, I'm alright with that.
>>>>>>>> 
>>>>>>>> On 21 August 2017 at 17:43, Gary Gregory 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Sweet. I've been going through the back log and picking some
>>>>>> low-hanging
>>>>>>>>> fruit as you may have noticed. Maybe others could do the same.
>>>>>>>>> 
>>>>>>>>> Gary
>>>>>>>>> 
>>>>>>>>> On Mon, Aug 21, 2017 at 4:31 PM, Ralph Goers <
>>>>>>> ralph.go...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I plan on starting the 2.9 release any day…
>>>>>>>>>> 
>>>>>>>>>> Ralph
>>>>>>>>>> 
>>>>>>>>>>> On Aug 21, 2017, at 3:25 PM, Gary Gregory <
>> garydgreg...@gmail.com
>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory <
>>>>>>> garydgreg...@gmail.com
>>>>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker >> 
>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I haven't been able to get to this so far this week. Been
>>>>>>> finishing
>>>>>>>>> up
>>>>>>>>>> a
>>>>>>>>>>>>> project for work. I should hopefully have enough time to merge
>>>>>>> this
>>>>>>>>>>>>> tomorrow though.
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>&

Release build failed

[Ralph Goers]

The release build failed with something I have never seen before.  I am going 
to try a normal build and see if it works.

Ralph

[INFO] [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on 
project log4j-core: There are test failures.
[INFO] [ERROR] 
[INFO] [ERROR] Please refer to 
/Users/rgoers/projects/apache/logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire-reports
 for the individual test results.
[INFO] [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[INFO] [ERROR] ExecutionException The forked VM terminated without properly 
saying goodbye. VM crash or System.exit called?
[INFO] [ERROR] Command was /bin/sh -c cd 
/Users/rgoers/projects/apache/logging/log4j/log4j2/logging-log4j2/log4j-core && 
/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java 
-XX:MaxPermSize=512m -jar 
/Users/rgoers/projects/apache/logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/surefirebooter8990144667850082747.jar
 
/Users/rgoers/projects/apache/logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp 
surefire_2796483572982439695337tmp
[INFO] [ERROR] Error occurred in starting fork, check output in log
[INFO] [ERROR] Process Exit Code: 1
[INFO] [ERROR] Crashed tests:
[INFO] [ERROR] org.apache.logging.log4j.core.layout.Log4j2_1482_CoreTest
[INFO] [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: 
ExecutionException The forked VM terminated without properly saying goodbye. VM 
crash or System.exit called?
[INFO] [ERROR] Command was /bin/sh -c cd 
/Users/rgoers/projects/apache/logging/log4j/log4j2/logging-log4j2/log4j-core && 
/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java 
-XX:MaxPermSize=512m -jar 
/Users/rgoers/projects/apache/logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/surefirebooter8990144667850082747.jar
 
/Users/rgoers/projects/apache/logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp 
surefire_2796483572982439695337tmp
[INFO] [ERROR] Error occurred in starting fork, check output in log
[INFO] [ERROR] Process Exit Code: 1
[INFO] [ERROR] Crashed tests:
[INFO] [ERROR] org.apache.logging.log4j.core.layout.Log4j2_1482_CoreTest
[INFO] [ERROR]  at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
[INFO] [ERROR]  at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
[INFO] [ERROR]  at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:292)
[INFO] [ERROR]  at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
[INFO] [ERROR]  at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
[INFO] [ERROR]  at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
[INFO] [ERROR]  at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
[INFO] [ERROR]  at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[INFO] [ERROR]  at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[INFO] [ERROR]  at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[INFO] [ERROR]  at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[INFO] [ERROR]  at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[INFO] [ERROR]  at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[INFO] [ERROR]  at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[INFO] [ERROR]  at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[INFO] [ERROR]  at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
[INFO] [ERROR]  at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
[INFO] [ERROR]  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
[INFO] [ERROR]  at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
[INFO] [ERROR]  at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
[INFO] [ERROR]  at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
[INFO] [ERROR]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO] [ERROR]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[INFO] [ERROR]  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[INFO] [ERROR]  at java.lang.reflect.Method.invoke(Method.java:606)
[

Re: Release build failed

[Ralph Goers]

The regular build ran fine. I’m trying it again.

Ralph

> On Aug 26, 2017, at 1:18 PM, Gary Gregory  wrote:
> 
> How about trying with Java 8?
> 
> G
> 
> On Aug 26, 2017 14:00, "Matt Sicker"  wrote:
> 
>> I don't see anything wrong with that test. Strange.
>> 
>> On 26 August 2017 at 14:45, Ralph Goers 
>> wrote:
>> 
>>> The release build failed with something I have never seen before.  I am
>>> going to try a normal build and see if it works.
>>> 
>>> Ralph
>>> 
>>> [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:
>>> maven-surefire-plugin:2.20:test (default-test) on project log4j-core:
>>> There are test failures.
>>> [INFO] [ERROR]
>>> [INFO] [ERROR] Please refer to /Users/rgoers/projects/apache/
>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire-reports
>>> for the individual test results.
>>> [INFO] [ERROR] Please refer to dump files (if any exist)
>>> [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
>>> [INFO] [ERROR] ExecutionException The forked VM terminated without
>>> properly saying goodbye. VM crash or System.exit called?
>>> [INFO] [ERROR] Command was /bin/sh -c cd /Users/rgoers/projects/apache/
>>> logging/log4j/log4j2/logging-log4j2/log4j-core && /Library/Java/
>>> JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java
>>> -XX:MaxPermSize=512m -jar /Users/rgoers/projects/apache/
>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/
>>> surefirebooter8990144667850082747.jar /Users/rgoers/projects/apache/
>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
>>> 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp
>> surefire_
>>> 2796483572982439695337tmp
>>> [INFO] [ERROR] Error occurred in starting fork, check output in log
>>> [INFO] [ERROR] Process Exit Code: 1
>>> [INFO] [ERROR] Crashed tests:
>>> [INFO] [ERROR] org.apache.logging.log4j.core.layout.Log4j2_1482_CoreTest
>>> [INFO] [ERROR] org.apache.maven.surefire.booter.
>> SurefireBooterForkException:
>>> ExecutionException The forked VM terminated without properly saying
>>> goodbye. VM crash or System.exit called?
>>> [INFO] [ERROR] Command was /bin/sh -c cd /Users/rgoers/projects/apache/
>>> logging/log4j/log4j2/logging-log4j2/log4j-core && /Library/Java/
>>> JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java
>>> -XX:MaxPermSize=512m -jar /Users/rgoers/projects/apache/
>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/
>>> surefirebooter8990144667850082747.jar /Users/rgoers/projects/apache/
>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
>>> 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp
>> surefire_
>>> 2796483572982439695337tmp
>>> [INFO] [ERROR] Error occurred in starting fork, check output in log
>>> [INFO] [ERROR] Process Exit Code: 1
>>> [INFO] [ERROR] Crashed tests:
>>> [INFO] [ERROR] org.apache.logging.log4j.core.layout.Log4j2_1482_CoreTest
>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>> ForkStarter.awaitResultsDone(ForkStarter.java:494)
>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>> ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>> ForkStarter.run(ForkStarter.java:292)
>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>> ForkStarter.run(ForkStarter.java:243)
>>> [INFO] [ERROR]  at org.apache.maven.plugin.
>> surefire.AbstractSurefireMojo.
>>> executeProvider(AbstractSurefireMojo.java:1077)
>>> [INFO] [ERROR]  at org.apache.maven.plugin.
>> surefire.AbstractSurefireMojo.
>>> executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
>>> [INFO] [ERROR]  at org.apache.maven.plugin.
>> surefire.AbstractSurefireMojo.
>>> execute(AbstractSurefireMojo.java:785)
>>> [INFO] [ERROR]  at org.apache.maven.plugin.DefaultBuildPluginManager.
>>> executeMojo(DefaultBuildPluginManager.java:134)
>>> [INFO] [ERROR]  at org.apache.maven.lifecycle.
>>> internal.MojoExecutor.execute(MojoExecutor.java:208)
>>> [INFO] [ERROR]  at org.apache.maven.lifecycle.
>>> internal.MojoExecutor.execute(MojoExecutor.java:154)
>>> [INFO] [ERROR]  at org.apache.maven.lifecycle.
>>> internal.MojoExecutor.execute(MojoExecut

Re: Release build failed

[Ralph Goers]

The release build ran fine the second time around. Now I have to verify it, 
build the site, etc.

Ralph

> On Aug 26, 2017, at 1:20 PM, Ralph Goers  wrote:
> 
> The regular build ran fine. I’m trying it again.
> 
> Ralph
> 
>> On Aug 26, 2017, at 1:18 PM, Gary Gregory  wrote:
>> 
>> How about trying with Java 8?
>> 
>> G
>> 
>> On Aug 26, 2017 14:00, "Matt Sicker"  wrote:
>> 
>>> I don't see anything wrong with that test. Strange.
>>> 
>>> On 26 August 2017 at 14:45, Ralph Goers 
>>> wrote:
>>> 
>>>> The release build failed with something I have never seen before.  I am
>>>> going to try a normal build and see if it works.
>>>> 
>>>> Ralph
>>>> 
>>>> [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:
>>>> maven-surefire-plugin:2.20:test (default-test) on project log4j-core:
>>>> There are test failures.
>>>> [INFO] [ERROR]
>>>> [INFO] [ERROR] Please refer to /Users/rgoers/projects/apache/
>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire-reports
>>>> for the individual test results.
>>>> [INFO] [ERROR] Please refer to dump files (if any exist)
>>>> [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
>>>> [INFO] [ERROR] ExecutionException The forked VM terminated without
>>>> properly saying goodbye. VM crash or System.exit called?
>>>> [INFO] [ERROR] Command was /bin/sh -c cd /Users/rgoers/projects/apache/
>>>> logging/log4j/log4j2/logging-log4j2/log4j-core && /Library/Java/
>>>> JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java
>>>> -XX:MaxPermSize=512m -jar /Users/rgoers/projects/apache/
>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/
>>>> surefirebooter8990144667850082747.jar /Users/rgoers/projects/apache/
>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
>>>> 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp
>>> surefire_
>>>> 2796483572982439695337tmp
>>>> [INFO] [ERROR] Error occurred in starting fork, check output in log
>>>> [INFO] [ERROR] Process Exit Code: 1
>>>> [INFO] [ERROR] Crashed tests:
>>>> [INFO] [ERROR] org.apache.logging.log4j.core.layout.Log4j2_1482_CoreTest
>>>> [INFO] [ERROR] org.apache.maven.surefire.booter.
>>> SurefireBooterForkException:
>>>> ExecutionException The forked VM terminated without properly saying
>>>> goodbye. VM crash or System.exit called?
>>>> [INFO] [ERROR] Command was /bin/sh -c cd /Users/rgoers/projects/apache/
>>>> logging/log4j/log4j2/logging-log4j2/log4j-core && /Library/Java/
>>>> JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java
>>>> -XX:MaxPermSize=512m -jar /Users/rgoers/projects/apache/
>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/
>>>> surefirebooter8990144667850082747.jar /Users/rgoers/projects/apache/
>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
>>>> 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp
>>> surefire_
>>>> 2796483572982439695337tmp
>>>> [INFO] [ERROR] Error occurred in starting fork, check output in log
>>>> [INFO] [ERROR] Process Exit Code: 1
>>>> [INFO] [ERROR] Crashed tests:
>>>> [INFO] [ERROR] org.apache.logging.log4j.core.layout.Log4j2_1482_CoreTest
>>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>>> ForkStarter.awaitResultsDone(ForkStarter.java:494)
>>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>>> ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
>>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>>> ForkStarter.run(ForkStarter.java:292)
>>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>>> ForkStarter.run(ForkStarter.java:243)
>>>> [INFO] [ERROR]  at org.apache.maven.plugin.
>>> surefire.AbstractSurefireMojo.
>>>> executeProvider(AbstractSurefireMojo.java:1077)
>>>> [INFO] [ERROR]  at org.apache.maven.plugin.
>>> surefire.AbstractSurefireMojo.
>>>> executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
>>>> [INFO] [ERROR]  at org.apache.maven.plugin.
>>> surefire.AbstractSurefireMojo.
>>>> execute(AbstractSurefireMojo.java:785)

Re: Release build failed

[Ralph Goers]

I’d prefer not to add enhancements until after the release vote.

Ralph

> On Aug 26, 2017, at 1:58 PM, Matt Sicker  wrote:
> 
> Sounds good. Do you want me to hold off on merging the LOG4J2-1431 branch?
> 
> On 26 August 2017 at 15:57, Ralph Goers  wrote:
> 
>> The release build ran fine the second time around. Now I have to verify
>> it, build the site, etc.
>> 
>> Ralph
>> 
>>> On Aug 26, 2017, at 1:20 PM, Ralph Goers 
>> wrote:
>>> 
>>> The regular build ran fine. I’m trying it again.
>>> 
>>> Ralph
>>> 
>>>> On Aug 26, 2017, at 1:18 PM, Gary Gregory 
>> wrote:
>>>> 
>>>> How about trying with Java 8?
>>>> 
>>>> G
>>>> 
>>>> On Aug 26, 2017 14:00, "Matt Sicker"  wrote:
>>>> 
>>>>> I don't see anything wrong with that test. Strange.
>>>>> 
>>>>> On 26 August 2017 at 14:45, Ralph Goers 
>>>>> wrote:
>>>>> 
>>>>>> The release build failed with something I have never seen before.  I
>> am
>>>>>> going to try a normal build and see if it works.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>> [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:
>>>>>> maven-surefire-plugin:2.20:test (default-test) on project log4j-core:
>>>>>> There are test failures.
>>>>>> [INFO] [ERROR]
>>>>>> [INFO] [ERROR] Please refer to /Users/rgoers/projects/apache/
>>>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/
>> surefire-reports
>>>>>> for the individual test results.
>>>>>> [INFO] [ERROR] Please refer to dump files (if any exist)
>>>>>> [date]-jvmRun[N].dump, [date].dumpstream and
>> [date]-jvmRun[N].dumpstream.
>>>>>> [INFO] [ERROR] ExecutionException The forked VM terminated without
>>>>>> properly saying goodbye. VM crash or System.exit called?
>>>>>> [INFO] [ERROR] Command was /bin/sh -c cd
>> /Users/rgoers/projects/apache/
>>>>>> logging/log4j/log4j2/logging-log4j2/log4j-core && /Library/Java/
>>>>>> JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java
>>>>>> -XX:MaxPermSize=512m -jar /Users/rgoers/projects/apache/
>>>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/
>>>>>> surefirebooter8990144667850082747.jar /Users/rgoers/projects/apache/
>>>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
>>>>>> 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp
>>>>> surefire_
>>>>>> 2796483572982439695337tmp
>>>>>> [INFO] [ERROR] Error occurred in starting fork, check output in log
>>>>>> [INFO] [ERROR] Process Exit Code: 1
>>>>>> [INFO] [ERROR] Crashed tests:
>>>>>> [INFO] [ERROR] org.apache.logging.log4j.core.
>> layout.Log4j2_1482_CoreTest
>>>>>> [INFO] [ERROR] org.apache.maven.surefire.booter.
>>>>> SurefireBooterForkException:
>>>>>> ExecutionException The forked VM terminated without properly saying
>>>>>> goodbye. VM crash or System.exit called?
>>>>>> [INFO] [ERROR] Command was /bin/sh -c cd
>> /Users/rgoers/projects/apache/
>>>>>> logging/log4j/log4j2/logging-log4j2/log4j-core && /Library/Java/
>>>>>> JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/bin/java
>>>>>> -XX:MaxPermSize=512m -jar /Users/rgoers/projects/apache/
>>>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire/
>>>>>> surefirebooter8990144667850082747.jar /Users/rgoers/projects/apache/
>>>>>> logging/log4j/log4j2/logging-log4j2/log4j-core/target/surefire
>>>>>> 2017-08-26T12-15-56_011-jvmRun12 surefire5406253882794901287tmp
>>>>> surefire_
>>>>>> 2796483572982439695337tmp
>>>>>> [INFO] [ERROR] Error occurred in starting fork, check output in log
>>>>>> [INFO] [ERROR] Process Exit Code: 1
>>>>>> [INFO] [ERROR] Crashed tests:
>>>>>> [INFO] [ERROR] org.apache.logging.log4j.core.
>> layout.Log4j2_1482_CoreTest
>>>>>> [INFO] [ERROR]  at org.apache.maven.plugin.surefire.booterclient.
>>>>>> ForkStarter.awaitResults

[VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

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

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

The vote will remain open for 72 hours (or more if required). All votes are 
welcome and we encourage everyone to test the release, but only Logging PMC 
votes are “officially” counted. As always, at least 3 +1 votes and more 
positive than negative votes are required.
Changes in this version include:

 
New
 Features

LOG4J2-2008 : Support 
printing multiple StructuredData elements in RFC5424Layout.
LOG4J2-1986 : Public API for 
parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent.
LOG4J2-1981 : JsonLayout, 
XmlLayout and YamlLayout support 0-byte termination of log events.
LOG4J2-1864 : Support capped 
collections for MongoDb appender. Thanks to Matthias Kappeller.
LOG4J2-1813 : Log4j2 will 
now print all internal logging to the console if system property log4j2.debug 
is defined with any value (or no value).
LOG4J2-1766 : Temporary 
compress directory during rollover (#88). Thanks to Pierrick HYMBERT.
LOG4J2-1814 : Added wrapper 
classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid class name 
with a dollar ($) character which has special meaning in many *nix command line 
environments.
LOG4J2-1884 : Added process 
ID (pid) pattern converter.
LOG4J2-1699 : Configurable 
Log File Permissions with PosixFilePermission. Thanks to Demetrios Dimatos, 
Pierrick HYMBERT.
LOG4J2-1945 : Generate 
source jas for all test jars.
LOG4J2-1934 : JMS Appender 
does not know how to recover from a broken connection.
LOG4J2-1955 : JMS Appender 
should be able connect to a broker (later) even it is not present at 
configuration time.
LOG4J2-1874 : Added methods 
::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to 
ByteBufferDestination interface and use these methods in TextEncoderHelper 
where possible to prepare for future enhancements to reduce lock contention. 
Thanks to Roman Leventov.
LOG4J2-1442 : Generic HTTP 
appender.
LOG4J2-1935 : Add 
with(String, primitive) methods to org.apache.logging.log4j.message.MapMessage.
LOG4J2-1930 : Add forEach() 
methods to org.apache.logging.log4j.message.MapMessage.
LOG4J2-1932 : Add 
containsKey() methods to org.apache.logging.log4j.message.MapMessage.
LOG4J2-1854 : Support null 
byte delimiter in GelfLayout. Thanks to Xavier Jodoin.
LOG4J2-1359 : Add support 
for Java 9 StackWalker.
LOG4J2-1880 : Warn when a 
configuration file for an inactive ConfigurationFactory is found.
LOG4J2-1855 : Add an 
optional random delay in TimeBasedTriggeringPolicy Thanks to Anthony Maire.
LOG4J2-1860 : Shortcut to 
add Property and KeyValuePair component in ConfigurationBuilder.
LOG4J2-1294 : The JMS 
Appender should use a JMS MapMessage for a Log4j MapMessage.
 
Fixed
 Bugs

LOG4J2-1833 : Prevent 
NullPointerException when a file name is specified with the 
DirectWriteRolloverStrategy.
LOG4J2-2018 : Fix incorrect 
documentation for LoggerNameLevelRewritePolicy.
LOG4J2-922 : Parameter of 
mdcId in SyslogAppender has no default value. Thanks to angus.aqlu, Paul 
Burrowes.
LOG4J2-2001 : 
StyleConverter.newInstance argument validation is incorrect. Thanks to Paul 
Burrowes.
LOG4J2-1999 : 
HighlightConverter converts all unrecognized levels to DEBUG. Thanks to Paul 
Burrowes.
LOG4J2-201

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

Matt added an exclude for the docker file back before the 2.8. release. I’m not 
sure why.

Ralph

> On Aug 27, 2017, at 7:50 AM, Gary Gregory  wrote:
> 
> Minor bug but not a blocker: the Dockerfile is missing from the src
> distribution zip.
> 
> Gary
> 
> On Sat, Aug 26, 2017 at 8:45 PM, Ralph Goers 
> wrote:
> 
>> This is a vote to release Log4j 2.9.0 the next version of the Log4j 2
>> project.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because...
>> 
>> The vote will remain open for 72 hours (or more if required). All votes
>> are welcome and we encourage everyone to test the release, but only Logging
>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>> positive than negative votes are required.
>> Changes in this version include:
>> 
>> <https://github.com/apache/logging-log4j2/blob/master/
>> RELEASE-NOTES.md#new-features>New Features
>> 
>> LOG4J2-2008 <https://issues.apache.org/jira/browse/LOG4J2-2008>: Support
>> printing multiple StructuredData elements in RFC5424Layout.
>> LOG4J2-1986 <https://issues.apache.org/jira/browse/LOG4J2-1986>: Public
>> API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a
>> LogEvent.
>> LOG4J2-1981 <https://issues.apache.org/jira/browse/LOG4J2-1981>:
>> JsonLayout, XmlLayout and YamlLayout support 0-byte termination of log
>> events.
>> LOG4J2-1864 <https://issues.apache.org/jira/browse/LOG4J2-1864>: Support
>> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
>> LOG4J2-1813 <https://issues.apache.org/jira/browse/LOG4J2-1813>: Log4j2
>> will now print all internal logging to the console if system property
>> log4j2.debug is defined with any value (or no value).
>> LOG4J2-1766 <https://issues.apache.org/jira/browse/LOG4J2-1766>:
>> Temporary compress directory during rollover (#88). Thanks to Pierrick
>> HYMBERT.
>> LOG4J2-1814 <https://issues.apache.org/jira/browse/LOG4J2-1814>: Added
>> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid
>> class name with a dollar ($) character which has special meaning in many
>> *nix command line environments.
>> LOG4J2-1884 <https://issues.apache.org/jira/browse/LOG4J2-1884>: Added
>> process ID (pid) pattern converter.
>> LOG4J2-1699 <https://issues.apache.org/jira/browse/LOG4J2-1699>:
>> Configurable Log File Permissions with PosixFilePermission. Thanks to
>> Demetrios Dimatos, Pierrick HYMBERT.
>> LOG4J2-1945 <https://issues.apache.org/jira/browse/LOG4J2-1945>: Generate
>> source jas for all test jars.
>> LOG4J2-1934 <https://issues.apache.org/jira/browse/LOG4J2-1934>: JMS
>> Appender does not know how to recover from a broken connection.
>> LOG4J2-1955 <https://issues.apache.org/jira/browse/LOG4J2-1955>: JMS
>> Appender should be able connect to a broker (later) even it is not present
>> at configuration time.
>> LOG4J2-1874 <https://issues.apache.org/jira/browse/LOG4J2-1874>: Added
>> methods ::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to
>> ByteBufferDestination interface and use these methods in TextEncoderHelper
>> where possible to prepare for future enhancements to reduce lock
>> contention. Thanks to Roman Leventov.
>> LOG4J2-1442 <https://issues.apache.org/jira/browse/LOG4J2-1442>: Generic
>> HTTP appender.
>> LOG4J2-1935 <https://issues.apache.org/jira/browse/LOG4J2-1935>: Add
>> with(String, primitive) methods to org.apache.logging.log4j.
>> message.MapMessage.
>> LOG4J2-1930 <https://issues.apache.org/jira/browse/LOG4J2-1930>: Add
>> forEach() methods to org.apache.logging.log4j.message.MapMessage.
>> LOG4J2-1932 <https://issues.apache.org/jira/browse/LOG4J2-1932>: Add
>> containsKey() methods to org.apache.logging.log4j.message.MapMessage.
>> LOG4J2-1854 <https://issues.apache.org/jira/browse/LOG4J2-1854>: Support
>> null byte delimiter in GelfLayout. Thanks to Xavier Jodoin.
>> LOG4J2-1359 <https://issues.apache.org/jira/browse/LOG4J2-1359>: Add
>> support for Java 9 StackWalker.
>> LOG4J2-1880 <https://issues.apache.org/jira/browse/LOG4J2-1880>: Warn
>> when a configuration file for an inactive ConfigurationFactory is found.
>> LOG4J2-1855 <https://issues.apache.org/jira/browse/LOG4J2-1855>: Add an
>> optional random delay in TimeBasedTriggeringPolicy Thanks to Anthony Maire.
>> LOG4J2-1860 <https://issues.apache.org/jira/brow

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

With regard to the CLIRR report:
1. The change the return type from a MapMessage to a StructuredDataMessage was 
done by you on June 6. It isn’t clear why you did that. However, I don’t see 
how this change could cause any problems since a StructuredDataMessage is a 
MapMessage.
2. The second change to StructuredDataMessage was also made by you on the same 
date for LOG4J2-1935. I believe you moved the method into MapMessage so this 
shouldn’t be a problem.
3. ReflectionUtil was eliminated as part of implementing the support for 
StackWalker. The class was documented as private so it should not be a problem 
to remove it.

Ralph

> On Aug 27, 2017, at 7:12 AM, Gary Gregory  wrote:
> 
> From src zip file and using guidance from BUILDING.md
> 
> ASC, MD5, SHA1, OK.
> 
> RAT check OK
> 
> mvn clean install OK
> 
> CLIRR check OK but MUST be done AFTER the above and I get:
> 
> [INFO] --- clirr-maven-plugin:2.8:check (default-cli) @ log4j-api ---
> [INFO] artifact org.apache.logging.log4j:log4j-api: checking for updates
> from central
> [INFO] Comparing to version: 2.8.2
> [ERROR] 7006: org.apache.logging.log4j.message.StructuredDataMessage:
> Return type of method 'public org.apache.logging.log4j.message.MapMessage
> newInstance(java.util.Map)' has been changed to
> org.apache.logging.log4j.message.StructuredDataMessage
> [ERROR] 7002: org.apache.logging.log4j.message.StructuredDataMessage:
> Method 'public org.apache.logging.log4j.message.StructuredDataMessage
> with(java.lang.String, java.lang.String)' has been removed
> [ERROR] 8001: org.apache.logging.log4j.util.ReflectionUtil: Class
> org.apache.logging.log4j.util.ReflectionUtil removed
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 12.582 s
> [INFO] Finished at: 2017-08-27T08:10:31-06:00
> [INFO] Final Memory: 44M/430M
> [INFO]
> 
> 
> 
> Thoughts? Since CLIRR is dead, we could also switch to japicmp.
> 
> Gary
> 
> 
> 
> 
> On Sat, Aug 26, 2017 at 8:45 PM, Ralph Goers 
> wrote:
> 
>> This is a vote to release Log4j 2.9.0 the next version of the Log4j 2
>> project.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because...
>> 
>> The vote will remain open for 72 hours (or more if required). All votes
>> are welcome and we encourage everyone to test the release, but only Logging
>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>> positive than negative votes are required.
>> Changes in this version include:
>> 
>> <https://github.com/apache/logging-log4j2/blob/master/
>> RELEASE-NOTES.md#new-features>New Features
>> 
>> LOG4J2-2008 <https://issues.apache.org/jira/browse/LOG4J2-2008>: Support
>> printing multiple StructuredData elements in RFC5424Layout.
>> LOG4J2-1986 <https://issues.apache.org/jira/browse/LOG4J2-1986>: Public
>> API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a
>> LogEvent.
>> LOG4J2-1981 <https://issues.apache.org/jira/browse/LOG4J2-1981>:
>> JsonLayout, XmlLayout and YamlLayout support 0-byte termination of log
>> events.
>> LOG4J2-1864 <https://issues.apache.org/jira/browse/LOG4J2-1864>: Support
>> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
>> LOG4J2-1813 <https://issues.apache.org/jira/browse/LOG4J2-1813>: Log4j2
>> will now print all internal logging to the console if system property
>> log4j2.debug is defined with any value (or no value).
>> LOG4J2-1766 <https://issues.apache.org/jira/browse/LOG4J2-1766>:
>> Temporary compress directory during rollover (#88). Thanks to Pierrick
>> HYMBERT.
>> LOG4J2-1814 <https://issues.apache.org/jira/browse/LOG4J2-1814>: Added
>> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid
>> class name with a dollar ($) character which has special meaning in many
>> *nix command line environments.
>> LOG4J2-1884 <https://issues.apache.org/jira/browse/LOG4J2-1884>: Added
>> process ID (pid) pattern converter.
>> LOG4J2-1699 <https://issues.apache.org/jira/browse/LOG4J2-1699>:
>> Configurable Log File Permissions with PosixFilePermission. Thanks to
>> Demetrios Dimatos, Pierrick HYMBERT.
>> LOG4J2-1945 <https://issues.apache.org/jira/browse/LOG4J2-1945>: Generate
>> source jas for all test jars.
>>

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

The KEYS file is where it has been since 2013 - 
https://dist.apache.org/repos/dist/release/logging/KEYS 
<https://dist.apache.org/repos/dist/release/logging/KEYS>. This is documented 
at http://logging.apache.org/log4j/2.x/download.html 
<http://logging.apache.org/log4j/2.x/download.html>.

Ralph



> On Aug 27, 2017, at 6:41 AM, Gary Gregory  wrote:
> 
> Link to KEYS file please?
> 
> Gary
> 
> On Sat, Aug 26, 2017 at 8:45 PM, Ralph Goers 
> wrote:
> 
>> This is a vote to release Log4j 2.9.0 the next version of the Log4j 2
>> project.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because...
>> 
>> The vote will remain open for 72 hours (or more if required). All votes
>> are welcome and we encourage everyone to test the release, but only Logging
>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>> positive than negative votes are required.
>> Changes in this version include:
>> 
>> <https://github.com/apache/logging-log4j2/blob/master/
>> RELEASE-NOTES.md#new-features>New Features
>> 
>> LOG4J2-2008 <https://issues.apache.org/jira/browse/LOG4J2-2008>: Support
>> printing multiple StructuredData elements in RFC5424Layout.
>> LOG4J2-1986 <https://issues.apache.org/jira/browse/LOG4J2-1986>: Public
>> API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a
>> LogEvent.
>> LOG4J2-1981 <https://issues.apache.org/jira/browse/LOG4J2-1981>:
>> JsonLayout, XmlLayout and YamlLayout support 0-byte termination of log
>> events.
>> LOG4J2-1864 <https://issues.apache.org/jira/browse/LOG4J2-1864>: Support
>> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
>> LOG4J2-1813 <https://issues.apache.org/jira/browse/LOG4J2-1813>: Log4j2
>> will now print all internal logging to the console if system property
>> log4j2.debug is defined with any value (or no value).
>> LOG4J2-1766 <https://issues.apache.org/jira/browse/LOG4J2-1766>:
>> Temporary compress directory during rollover (#88). Thanks to Pierrick
>> HYMBERT.
>> LOG4J2-1814 <https://issues.apache.org/jira/browse/LOG4J2-1814>: Added
>> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid
>> class name with a dollar ($) character which has special meaning in many
>> *nix command line environments.
>> LOG4J2-1884 <https://issues.apache.org/jira/browse/LOG4J2-1884>: Added
>> process ID (pid) pattern converter.
>> LOG4J2-1699 <https://issues.apache.org/jira/browse/LOG4J2-1699>:
>> Configurable Log File Permissions with PosixFilePermission. Thanks to
>> Demetrios Dimatos, Pierrick HYMBERT.
>> LOG4J2-1945 <https://issues.apache.org/jira/browse/LOG4J2-1945>: Generate
>> source jas for all test jars.
>> LOG4J2-1934 <https://issues.apache.org/jira/browse/LOG4J2-1934>: JMS
>> Appender does not know how to recover from a broken connection.
>> LOG4J2-1955 <https://issues.apache.org/jira/browse/LOG4J2-1955>: JMS
>> Appender should be able connect to a broker (later) even it is not present
>> at configuration time.
>> LOG4J2-1874 <https://issues.apache.org/jira/browse/LOG4J2-1874>: Added
>> methods ::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to
>> ByteBufferDestination interface and use these methods in TextEncoderHelper
>> where possible to prepare for future enhancements to reduce lock
>> contention. Thanks to Roman Leventov.
>> LOG4J2-1442 <https://issues.apache.org/jira/browse/LOG4J2-1442>: Generic
>> HTTP appender.
>> LOG4J2-1935 <https://issues.apache.org/jira/browse/LOG4J2-1935>: Add
>> with(String, primitive) methods to org.apache.logging.log4j.
>> message.MapMessage.
>> LOG4J2-1930 <https://issues.apache.org/jira/browse/LOG4J2-1930>: Add
>> forEach() methods to org.apache.logging.log4j.message.MapMessage.
>> LOG4J2-1932 <https://issues.apache.org/jira/browse/LOG4J2-1932>: Add
>> containsKey() methods to org.apache.logging.log4j.message.MapMessage.
>> LOG4J2-1854 <https://issues.apache.org/jira/browse/LOG4J2-1854>: Support
>> null byte delimiter in GelfLayout. Thanks to Xavier Jodoin.
>> LOG4J2-1359 <https://issues.apache.org/jira/browse/LOG4J2-1359>: Add
>> support for Java 9 StackWalker.
>> LOG4J2-1880 <https://issues.apache.org/jira/browse/LOG4J2-1880>: Warn
>> when a configuration file for an inactive ConfigurationFactory is found.
>> LOG4J2-1855 <https://issues.apache.org/jira/browse/LOG4J2-1855>: Add 

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

Thanks Matt. I agree that we should stick with 2.x.x from here on out. Whoever 
modified the version in changes.xml set it to 2.9.0 so I just followed suit. 

Ralph

> On Aug 28, 2017, at 8:51 AM, Matt Sicker  wrote:
> 
> +1
> 
> Builds fine with Java 8 and 9 (tried originally with Zulu 8u144 and JDK 9
> EA +181) on macOS 10.12. Also builds fine in Docker.
> 
> Signatures are all good.
> 
> Maven artifacts work with my tested applications (which are Scala 2.12
> applications using SBT 0.13.16 with log4j-api-scala 11.0 as well).
> 
> Notes on site and docs in general:
> 
> * Would be good to note Java 9 compatibility in the news bit on the
> homepage.
> * Same with README.md
> * Should update readme to point to 2.9.0 in maven snippets and whatnot
> (would be nice to figure out how to automate this in a sort of post-release
> build script).
> * Maven artifacts page <
> https://rgoers.github.io/log4j2-site/maven-artifacts.html> has the
> incorrect version for log4j-api-scala now ever since the 11.0 release.
> * Rat report should have RELEASE-NOTES.md added to the exclude filter
> (which is the only missing license found in the report)
> * Still need to remove the surefire report from the top level component
> report as it's only applicable to sub-components.
> * Same goes for the dependencies link on the top level component (we're
> only using dependency management in the top level).
> * Mikael still works for Magine TV on the team page; he should update his
> organization. ;)
> * Mailing list page still have log4j-dev@ instead of dev@, though the
> bounce message helps aid that.
> * On the downloads page, we should start using the full fingerprint id for
> GPG keys rather than the abbreviated version. More info: <
> http://www.zdnet.com/article/pgp-security-weakness-exposed/>.
> 
> Side note: if we stick to calling this version 2.9.0, I'd like to stick
> with that naming scheme moving forward for all 2.x.0 releases.
> 
> On 28 August 2017 at 10:18, Matt Sicker  wrote:
> 
>> I do like the full version number, but I'm just comparing to historical
>> releases:
>> 
>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
>> apache.logging.log4j%22%20AND%20a%3A%22log4j-api%22
>> 
>> On 28 August 2017 at 10:17, Gary Gregory  wrote:
>> 
>>> It sorts pertier?
>>> 
>>> On Mon, Aug 28, 2017 at 9:15 AM, Matt Sicker  wrote:
>>> 
>>>> Any particular reason this is tagged as 2.9.0 instead of 2.9?
>>>> 
>>>> On 27 August 2017 at 19:03, Matt Sicker  wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 27 August 2017 at 11:23, Ralph Goers 
>>>>> wrote:
>>>>> 
>>>>>> Matt added an exclude for the docker file back before the 2.8.
>>> release.
>>>>>> I’m not sure why.
>>>>>> 
>>>>> 
>>>>> I don't remember exactly why, but my guess is a rat-check error. The
>>>>> license header wasn't added until after 2.8 according to the tags:
>>>>> 
>>>>> https://github.com/apache/logging-log4j2/commit/
>>>>> 33f97a804b6f44364b5913cd5a893c1b55a6
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Aug 27, 2017, at 7:50 AM, Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>> Minor bug but not a blocker: the Dockerfile is missing from the src
>>>>>>> distribution zip.
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Sat, Aug 26, 2017 at 8:45 PM, Ralph Goers <
>>>>>> ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> This is a vote to release Log4j 2.9.0 the next version of the
>>> Log4j 2
>>>>>>>> project.
>>>>>>>> 
>>>>>>>> Please download, test, and cast your votes on the log4j developers
>>>>>> list.
>>>>>>>> [] +1, release the artifacts
>>>>>>>> [] -1, don't release because...
>>>>>>>> 
>>>>>>>> The vote will remain open for 72 hours (or more if required). All
>>>> votes
>>>>>>>> are welcome and we encourage everyone to test the release, but
>>> only
>>>>>> Logging
>>>>>>>> PMC votes are

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

Oh, and if you check out from the release tag and create a branch the web site 
fixes can be made there after the release is complete.

Ralph

> On Aug 28, 2017, at 8:51 AM, Matt Sicker  wrote:
> 
> +1
> 
> Builds fine with Java 8 and 9 (tried originally with Zulu 8u144 and JDK 9
> EA +181) on macOS 10.12. Also builds fine in Docker.
> 
> Signatures are all good.
> 
> Maven artifacts work with my tested applications (which are Scala 2.12
> applications using SBT 0.13.16 with log4j-api-scala 11.0 as well).
> 
> Notes on site and docs in general:
> 
> * Would be good to note Java 9 compatibility in the news bit on the
> homepage.
> * Same with README.md
> * Should update readme to point to 2.9.0 in maven snippets and whatnot
> (would be nice to figure out how to automate this in a sort of post-release
> build script).
> * Maven artifacts page <
> https://rgoers.github.io/log4j2-site/maven-artifacts.html> has the
> incorrect version for log4j-api-scala now ever since the 11.0 release.
> * Rat report should have RELEASE-NOTES.md added to the exclude filter
> (which is the only missing license found in the report)
> * Still need to remove the surefire report from the top level component
> report as it's only applicable to sub-components.
> * Same goes for the dependencies link on the top level component (we're
> only using dependency management in the top level).
> * Mikael still works for Magine TV on the team page; he should update his
> organization. ;)
> * Mailing list page still have log4j-dev@ instead of dev@, though the
> bounce message helps aid that.
> * On the downloads page, we should start using the full fingerprint id for
> GPG keys rather than the abbreviated version. More info: <
> http://www.zdnet.com/article/pgp-security-weakness-exposed/>.
> 
> Side note: if we stick to calling this version 2.9.0, I'd like to stick
> with that naming scheme moving forward for all 2.x.0 releases.
> 
> On 28 August 2017 at 10:18, Matt Sicker  wrote:
> 
>> I do like the full version number, but I'm just comparing to historical
>> releases:
>> 
>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
>> apache.logging.log4j%22%20AND%20a%3A%22log4j-api%22
>> 
>> On 28 August 2017 at 10:17, Gary Gregory  wrote:
>> 
>>> It sorts pertier?
>>> 
>>> On Mon, Aug 28, 2017 at 9:15 AM, Matt Sicker  wrote:
>>> 
>>>> Any particular reason this is tagged as 2.9.0 instead of 2.9?
>>>> 
>>>> On 27 August 2017 at 19:03, Matt Sicker  wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 27 August 2017 at 11:23, Ralph Goers 
>>>>> wrote:
>>>>> 
>>>>>> Matt added an exclude for the docker file back before the 2.8.
>>> release.
>>>>>> I’m not sure why.
>>>>>> 
>>>>> 
>>>>> I don't remember exactly why, but my guess is a rat-check error. The
>>>>> license header wasn't added until after 2.8 according to the tags:
>>>>> 
>>>>> https://github.com/apache/logging-log4j2/commit/
>>>>> 33f97a804b6f44364b5913cd5a893c1b55a6
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Aug 27, 2017, at 7:50 AM, Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>> Minor bug but not a blocker: the Dockerfile is missing from the src
>>>>>>> distribution zip.
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Sat, Aug 26, 2017 at 8:45 PM, Ralph Goers <
>>>>>> ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> This is a vote to release Log4j 2.9.0 the next version of the
>>> Log4j 2
>>>>>>>> project.
>>>>>>>> 
>>>>>>>> Please download, test, and cast your votes on the log4j developers
>>>>>> list.
>>>>>>>> [] +1, release the artifacts
>>>>>>>> [] -1, don't release because...
>>>>>>>> 
>>>>>>>> The vote will remain open for 72 hours (or more if required). All
>>>> votes
>>>>>>>> are welcome and we encourage everyone to test the release, but
>>> only
>>>>>> Logging
>>>>>>>> PMC votes are “officially” counted. As always,

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

Here is my +1

Ralph

> On Aug 26, 2017, at 7:45 PM, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.9.0 the next version of the Log4j 2 project.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for 72 hours (or more if required). All votes are 
> welcome and we encourage everyone to test the release, but only Logging PMC 
> votes are “officially” counted. As always, at least 3 +1 votes and more 
> positive than negative votes are required.
> Changes in this version include:
> 
> <https://github.com/apache/logging-log4j2/blob/master/RELEASE-NOTES.md#new-features>New
>  Features
> 
> LOG4J2-2008 <https://issues.apache.org/jira/browse/LOG4J2-2008>: Support 
> printing multiple StructuredData elements in RFC5424Layout.
> LOG4J2-1986 <https://issues.apache.org/jira/browse/LOG4J2-1986>: Public API 
> for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent.
> LOG4J2-1981 <https://issues.apache.org/jira/browse/LOG4J2-1981>: JsonLayout, 
> XmlLayout and YamlLayout support 0-byte termination of log events.
> LOG4J2-1864 <https://issues.apache.org/jira/browse/LOG4J2-1864>: Support 
> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
> LOG4J2-1813 <https://issues.apache.org/jira/browse/LOG4J2-1813>: Log4j2 will 
> now print all internal logging to the console if system property log4j2.debug 
> is defined with any value (or no value).
> LOG4J2-1766 <https://issues.apache.org/jira/browse/LOG4J2-1766>: Temporary 
> compress directory during rollover (#88). Thanks to Pierrick HYMBERT.
> LOG4J2-1814 <https://issues.apache.org/jira/browse/LOG4J2-1814>: Added 
> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid 
> class name with a dollar ($) character which has special meaning in many *nix 
> command line environments.
> LOG4J2-1884 <https://issues.apache.org/jira/browse/LOG4J2-1884>: Added 
> process ID (pid) pattern converter.
> LOG4J2-1699 <https://issues.apache.org/jira/browse/LOG4J2-1699>: Configurable 
> Log File Permissions with PosixFilePermission. Thanks to Demetrios Dimatos, 
> Pierrick HYMBERT.
> LOG4J2-1945 <https://issues.apache.org/jira/browse/LOG4J2-1945>: Generate 
> source jas for all test jars.
> LOG4J2-1934 <https://issues.apache.org/jira/browse/LOG4J2-1934>: JMS Appender 
> does not know how to recover from a broken connection.
> LOG4J2-1955 <https://issues.apache.org/jira/browse/LOG4J2-1955>: JMS Appender 
> should be able connect to a broker (later) even it is not present at 
> configuration time.
> LOG4J2-1874 <https://issues.apache.org/jira/browse/LOG4J2-1874>: Added 
> methods ::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to 
> ByteBufferDestination interface and use these methods in TextEncoderHelper 
> where possible to prepare for future enhancements to reduce lock contention. 
> Thanks to Roman Leventov.
> LOG4J2-1442 <https://issues.apache.org/jira/browse/LOG4J2-1442>: Generic HTTP 
> appender.
> LOG4J2-1935 <https://issues.apache.org/jira/browse/LOG4J2-1935>: Add 
> with(String, primitive) methods to 
> org.apache.logging.log4j.message.MapMessage.
> LOG4J2-1930 <https://issues.apache.org/jira/browse/LOG4J2-1930>: Add 
> forEach() methods to org.apache.logging.log4j.message.MapMessage.
> LOG4J2-1932 <https://issues.apache.org/jira/browse/LOG4J2-1932>: Add 
> containsKey() methods to org.apache.logging.log4j.message.MapMessage.
> LOG4J2-1854 <https://issues.apache.org/jira/browse/LOG4J2-1854>: Support null 
> byte delimiter in GelfLayout. Thanks to Xavier Jodoin.
> LOG4J2-1359 <https://issues.apache.org/jira/browse/LOG4J2-1359>: Add support 
> for Java 9 StackWalker.
> LOG4J2-1880 <https://issues.apache.org/jira/browse/LOG4J2-1880>: Warn when a 
> configuration file for an inactive ConfigurationFactory is found.
> LOG4J2-1855 <https://issues.apache.org/jira/browse/LOG4J2-1855>: Add an 
> optional random delay in TimeBasedTriggeringPolicy Thanks to Anthony Maire.
> LOG4J2-1860 <https://issues.apache.org/jira/browse/LOG4J2-1860>: Shortcut to 
> add Property and KeyValuePair component in ConfigurationBuilder.
> LOG4J2-1294 <https://issues.apache.org/jira/browse/LOG4J2-1294>: The JMS 
> Appender should use a JMS MapMessage for a Log4j MapMessage.
> <https://github.com/apache/logging-log4j2/blob/master/RELEASE-NOTES.md#fixed-bugs>Fixed
>  Bugs
> 
> LOG4J2-1833 <https://issues.apache.org/jira/browse/LOG4J2-1833>: Prevent 
> NullPointerException when a file name is specified with the 
&g

[VOTE][RESULT] Log4j 2.9.0-rc1

[Ralph Goers]

The vote to release Log4j 2.9.0 based on release candidate 1 has passed with +1 
votes from Gary Gregory, Matt Sicker, Mikael Ståldal, Remko Popma, and Ralph 
Goers. No other votes were cast.

I will continue with the release process.

Ralph

Re: Module log4j-core-its not in MC

[Ralph Goers]

Yes, I manually deleted that before publishing to central. I can’t think of any 
reason why anyone would need that as a dependency. The release process used to 
manually delete several other modules but I modified the poms to have the 
deploy goal be ignored. Apparently I missed core-its. That will be corrected 
for the next release.

Ralph

> On Aug 30, 2017, at 7:46 AM, Gary Gregory  wrote:
> 
> Hi All,
> 
> My build is going fine with 2.9.0 from MC but I do not see the
> log4j-core-its in MC:
> 
> https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core-its%22
> 
> Shouldn't it be there?
> 
> Gary

Re: Module log4j-core-its not in MC

[Ralph Goers]

We publish unit test jars. Those contain test classes with some value for 
testing end user applications.

Ralph

> On Aug 30, 2017, at 8:28 AM, Matt Sicker  wrote:
> 
> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.logging.log4j%22%20AND%20a%3A%22log4j-api%22
> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.logging.log4j%22%20AND%20a%3A%22log4j-core%22
> 
> So it looks like we do have a history of publishing unit test jars. I think
> you have a point.
> 
> On 30 August 2017 at 10:21, Gary Gregory  wrote:
> 
>> But I think that is a _good_ thing to have all modules published.
>> 
>> Gary
>> 
>> On Wed, Aug 30, 2017 at 9:20 AM, Matt Sicker  wrote:
>> 
>>> I was the one who published 2.8.2, and I think I simply forgot to delete
>>> that from the staging repo before releasing.
>>> 
>>> On 30 August 2017 at 09:46, Gary Gregory  wrote:
>>> 
 Hi All,
 
 My build is going fine with 2.9.0 from MC but I do not see the
 log4j-core-its in MC:
 
 https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core-its%22
 
 Shouldn't it be there?
 
 Gary
 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Ralph Goers]

For what it is worth, if you go to https://repository.apache.org/#central-stat 
 you can see that about 25% of the 
downloads for log4j-api are for versions that still support Java 6. 
Unfortunately, I don’t know of any way to detect how many users are still using 
Java 7 unless we can find a commons component that has a Java 7 and Java 8 
version and look at those download stats. But if we have 1/4 or our users still 
on Java 6 I have to believe a larger number than that are using Java 7.

Ralph

> On Aug 30, 2017, at 8:31 AM, Matt Sicker  wrote:
> 
> Oh well, so much for that idea. Do you think net-2.0 is still in wide
> enough use to continue supporting it? We moved on from Java 6 to 7 as
> baseline requirements for Log4j a while back even though there are still
> stragglers using 6, though the idea there is that most users still on 6
> aren't really updating anything anymore other than security patches if
> applicable. Would you say it's similar in .net 2?
> 
> On 30 August 2017 at 02:39, Dominik Psenner  wrote:
> 
>> 
>> On 2017-08-29 16:12, Matt Sicker wrote:
>> 
>>> I'm not too familiar with this area, but would using Windows containers
>>> (e.g., via Docker or similar) work here? Or would that only support newer
>>> versions of .net anyways?
>>> 
>> 
>> Good idea Matt, unfortunately net-2.0 is not available in a windows server
>> docker container as documented in the image variants section at
>> https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer
>> are available. We already build net-3.5, net-4.0 and net-4.5 with jenkins.
>> I've the impression that if we changed this today, we would gain nothing.
>> 
>> 
>> 
>>> On 28 August 2017 at 23:32, Dominik Psenner  wrote:
>>> 
>>> Hi,
 
 Chris just resolved our infra ticket regarding .net frameworks on the
 windows nodes. This is a summary of the outcome:
 
 Chris Thistlethwaite resolved INFRA-14645.
> --
>Resolution: Fixed
> 
>> 1. We have observed that none of the windows nodes appear to have
>> 
> net-2.0 installed so we cannot build assemblies against it. Is it
 possible
 to install it on one or more of the windows nodes? It may well be the
 case
 that it is not possible to have .NET framework 2.0 installed when a newer
 .NET framework is installed on the same windows os.
 
 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
> 
 installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd
 also
 argue that building for .Net 2 isn't something we can support if the
 tools
 at hand only allow newer binaries.
 
 To me this means that we can no longer build assemblies targeted against
 the framework net-2.0. net-3.5 is the oldest we can get from jenkins.
 We'll
 have to announce this soon.
 
 2. We have observed that windows-2012-3 does not have .NET framework 3.5
>> 
> installed while the other two Windows nodes have it installed.
 
 2. jenkins-win2012-3 has been updated to fall in line with the other
> 
 nodes.
 
 This means we will no longer see intermittent build failures because of
 the
 missing framework.
 
 3. As an improvement to the windows node labels we suggest to add
>> 
> additional labels that match the installed .NET frameworks. Currently
 it is
 rather unclear what the windows nodes actually can do and it would
 further
 allow that not all windows nodes to have exactly the same components
 installed. (i.e. windows-2012-1 could have the labels "Windows",
 "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)
 
 3. Agreed, the windows nodes could use more organized labeling, however,
> 
 we're currently keeping them all built out the same (or as close as
 possible obviously) so we can maximize the few boxes we have. We just
 don't
 have enough need to run specific Windows configurations.
 
 Now that [2] is fixed, all windows nodes have the same capabilities and
 therefore this is not an issue.
 
 Cheers,
 Dominik
 
 
>>> 
>>> 
>> 
> 
> 
> -- 
> Matt Sicker 

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

Please create a Jira issue for this. It should be a simple matter to catch the 
exception and ignore it.

Ralph

> On Aug 30, 2017, at 2:56 PM, Leon Finker  wrote:
> 
> Hi,
> 
> Tested with two large legacy projects. The only issue found due to xerces
> 2.6.2 version being pulled in in one app and then causing log4j2 failure to
> initialize (changes are from LOG4J2-1959). I guess we may have to try and
> upgrade xerces to latest due to this.
> 
> Exception in thread "main" java.lang.AbstractMethodError:
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
>at
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
>at
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
>at
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
>at
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
>at
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
>at
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
>at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
>at
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
>at
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
>at
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
>at
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)
> 
> On Sat, Aug 26, 2017 at 10:45 PM, Ralph Goers 
> wrote:
> 
>> This is a vote to release Log4j 2.9.0 the next version of the Log4j 2
>> project.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because...
>> 
>> The vote will remain open for 72 hours (or more if required). All votes
>> are welcome and we encourage everyone to test the release, but only Logging
>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>> positive than negative votes are required.
>> Changes in this version include:
>> 
>> <https://github.com/apache/logging-log4j2/blob/master/
>> RELEASE-NOTES.md#new-features>New Features
>> 
>> LOG4J2-2008 <https://issues.apache.org/jira/browse/LOG4J2-2008>: Support
>> printing multiple StructuredData elements in RFC5424Layout.
>> LOG4J2-1986 <https://issues.apache.org/jira/browse/LOG4J2-1986>: Public
>> API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a
>> LogEvent.
>> LOG4J2-1981 <https://issues.apache.org/jira/browse/LOG4J2-1981>:
>> JsonLayout, XmlLayout and YamlLayout support 0-byte termination of log
>> events.
>> LOG4J2-1864 <https://issues.apache.org/jira/browse/LOG4J2-1864>: Support
>> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
>> LOG4J2-1813 <https://issues.apache.org/jira/browse/LOG4J2-1813>: Log4j2
>> will now print all internal logging to the console if system property
>> log4j2.debug is defined with any value (or no value).
>> LOG4J2-1766 <https://issues.apache.org/jira/browse/LOG4J2-1766>:
>> Temporary compress directory during rollover (#88). Thanks to Pierrick
>> HYMBERT.
>> LOG4J2-1814 <https://issues.apache.org/jira/browse/LOG4J2-1814>: Added
>> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid
>> class name with a dollar ($) character which has special meaning in many
>> *nix command line environments.
>> LOG4J2-1884 <https://issues.apache.org/jira/browse/LOG4J2-1884>: Added
>> process ID (pid) pattern converter.
>> LOG4J2-1699 <https://issues.apache.org/jira/browse/LOG4J2-1699>:
>> Configurable Log File Permissions with PosixFilePermission. Thanks to
>> Demetrios Dimatos, Pierrick HYMBERT.
>> LOG4J2-1945 <https://issues.apache.org/jira/browse/LOG4J2-1945>: Generate
>> source jas for all test jars.
>> LOG4J2-1934 <https://issues.apache.org/jira/browse/LOG4J2-1934>: JMS
>> Appender does not know how to recover from a broken connection.
>> LOG4J2-1955 <https://issues.apache.org/jira/browse/LOG4J2-1955>: JMS
>> Appender should be able connect to a broker (later) even it is not present
>> at configuration time.
>> LOG4J2-1874 <https://issues.apache.org/jira/browse/LOG4J2-1

Re: [VOTE][RESULT] Log4j 2.9.0-rc1

[Ralph Goers]

Thanks for the reminder. I will do it momentarily.

Ralph

> On Aug 30, 2017, at 4:44 PM, Remko Popma  wrote:
> 
> I drafted a Log4j 2.9 release blog post. 
> I'll hold off on publishing until the announcement email. Roughly what time 
> do you think you'll send it, Ralph?
> 
> Remko 
> 
>> On Aug 30, 2017, at 14:43, Ralph Goers  wrote:
>> 
>> The vote to release Log4j 2.9.0 based on release candidate 1 has passed with 
>> +1 votes from Gary Gregory, Matt Sicker, Mikael Ståldal, Remko Popma, and 
>> Ralph Goers. No other votes were cast.
>> 
>> I will continue with the release process.
>> 
>> Ralph
> 

[ANNOUNCE] Apache Log4j 2.9.0 released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.9.0 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

This release contains the first support of Java 9 as well as bugfixes and minor 
enhancements. The Log4j API was modified to use java.util.ServiceLoader to 
locate Log4j implementations, although the former binding mechanism is still 
supported. The Log4j jar is now a multi-release jar to provide implementations 
of the Java 9 specific classes. Multi-release jars are not supported by the 
OSGi specification so OSGi modules will not be able to take advantage of these 
implementations but will not lose functionality as they will fall back to the 
implementations used in Java 7 and 8. More details on the new features and 
fixes are itemized below.

Note that subsequent to the 2.9 release, for security reasons, SerializedLayout 
is deprecated and no longer used as default in the Socket and JMS appenders. 
SerializedLayout can still be used as before, but has to be specified 
explicitly. To retain old behaviour, you have to change configuration like:


  

into:


  

  

We do, however, discourage the use of SerializedLayout and recommend JsonLayout 
as a replacement:


  

  

Note that subsequent to the 2.9 release, for security reasons, Log4j does not 
process DTD in XML files. If you used DTD for including snippets, you have to 
use XInclude or Composite Configuration instead.

The Log4j 2.9.0 API, as well as many core components, maintains binary 
compatibility with previous releases.

 
GA
 Release 2.9.0

Changes in this version include:

 
New
 Features

LOG4J2-2008 : Support 
printing multiple StructuredData elements in RFC5424Layout.
LOG4J2-1986 : Public API for 
parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent.
LOG4J2-1981 : JsonLayout, 
XmlLayout and YamlLayout support 0-byte termination of log events.
LOG4J2-1864 : Support capped 
collections for MongoDb appender. Thanks to Matthias Kappeller.
LOG4J2-1813 : Log4j2 will 
now print all internal logging to the console if system property log4j2.debug 
is defined with any value (or no value).
LOG4J2-1766 : Temporary 
compress directory during rollover (#88). Thanks to Pierrick HYMBERT.
LOG4J2-1814 : Added wrapper 
classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid class name 
with a dollar ($) character which has special meaning in many *nix command line 
environments.
LOG4J2-1884 : Added process 
ID (pid) pattern converter.
LOG4J2-1699 : Configurable 
Log File Permissions with PosixFilePermission. Thanks to Demetrios Dimatos, 
Pierrick HYMBERT.
LOG4J2-1945 : Generate 
source jas for all test jars.
LOG4J2-1934 : JMS Appender 
does not know how to recover from a broken connection.
LOG4J2-1955 : JMS Appender 
should be able connect to a broker (later) even it is not present at 
configuration time.
LOG4J2-1874 : Added methods 
::writeBytes(ByteBuffer) and ::writeBytes(byte[], int, int) to 
ByteBufferDestination interface and use these methods in TextEncoderHelper 
where possible to prepare for future enhancements to reduce lock contention. 
Thanks to Roman Leventov.
LOG4J2-1442 : Generic HTTP 
appender.
LOG4J2-1935 : Add 
with(String, primitive) methods to org.apache.logging.log4j.message.MapMessage.
LOG4J2-1930 : Add forEach() 
methods to org.apache.logging.log4j.message.MapMessage.
LOG4J2-1932 : Add 
containsKey() methods to org.apache.logging.log4j.message.

Re: [VOTE] Release Log4j 2.9.0-rc1

[Ralph Goers]

That is actually documented in the original release vote email. 

a)  for a new copy do "git clone 
https://git-wip-us.apache.org/repos/asf/logging-log4j2.git 
<https://git-wip-us.apache.org/repos/asf/logging-log4j2.git> 
<https://git-wip-us.apache.org/repos/asf/logging-log4j2.git 
<https://git-wip-us.apache.org/repos/asf/logging-log4j2.git>>" and then "git 
checkout tags/log4j-2.9-rc1”
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.9-rc1”


> On Aug 31, 2017, at 12:46 PM, Mikael Ståldal  wrote:
> 
> How can I do that?
> 
> On 2017-08-28 18:18, Ralph Goers wrote:
>> Oh, and if you check out from the release tag and create a branch the web 
>> site fixes can be made there after the release is complete.
> 
> 

Re: [Log4j] Public beta release

[Ralph Goers]

Yup. Besides, what is the difference between creating a release named 
2.9.0-beta1 and 2.9.0 at this point. The release process is exactly the same. 
In addition, even if you do that I guarantee you will still find minor issues 
right after the non-beta release.

Betas make sense when you are releasing code that you think isn’t quite ready 
for the prime time.

Ralph

> On Aug 31, 2017, at 12:59 PM, Gary Gregory  wrote:
> 
> That might help but some folks will only use releases...
> 
> Gary
> 
> On Thu, Aug 31, 2017 at 1:51 PM, Mikael Ståldal  wrote:
> 
>> Yet again some users find bugs right after release of a minor version, so
>> far LOG4J2-2023 and LOG4J2-2026.
>> 
>> Maybe we should do a public beta before next minor release (2.10) to
>> encourage testing by users who are not committers or PMC?
>> 

Announcement is ugly

[Ralph Goers]

Although it looks great at GitHub, I really dislike what copying the page there 
makes the actual announcement look like. It doesn’t look too bad below, except 
that the headings look odd, but when it goes to the announcement list it looks 
terrible. 
http://mail-archives.us.apache.org/mod_mbox/www-announce/201708.mbox/%3ccd8b8bef-882e-fb69-6e89-d72428416...@apache.org%3E
 
<http://mail-archives.us.apache.org/mod_mbox/www-announce/201708.mbox/%3ccd8b8bef-882e-fb69-6e89-d72428416...@apache.org%3E>.

Any ideas?

Ralph


> On Aug 30, 2017, at 5:26 PM, Ralph Goers  wrote:
> 
> The Apache Log4j 2 team is pleased to announce the Log4j 2.9.0 release!
> 
> Apache Log4j is a well known framework for logging application behavior. 
> Log4j 2 is an upgrade to Log4j that provides significant improvements over 
> its predecessor, Log4j 1.x, and provides many other modern features such as 
> support for Markers, lambda expressions for lazy logging, property 
> substitution using Lookups, multiple patterns on a PatternLayout and 
> asynchronous Loggers. Another notable Log4j 2 feature is the ability to be 
> "garbage-free" (avoid allocating temporary objects) while logging. In 
> addition, Log4j 2 will not lose events while reconfiguring.
> 
> This release contains the first support of Java 9 as well as bugfixes and 
> minor enhancements. The Log4j API was modified to use java.util.ServiceLoader 
> to locate Log4j implementations, although the former binding mechanism is 
> still supported. The Log4j jar is now a multi-release jar to provide 
> implementations of the Java 9 specific classes. Multi-release jars are not 
> supported by the OSGi specification so OSGi modules will not be able to take 
> advantage of these implementations but will not lose functionality as they 
> will fall back to the implementations used in Java 7 and 8. More details on 
> the new features and fixes are itemized below.
> 
> Note that subsequent to the 2.9 release, for security reasons, 
> SerializedLayout is deprecated and no longer used as default in the Socket 
> and JMS appenders. SerializedLayout can still be used as before, but has to 
> be specified explicitly. To retain old behaviour, you have to change 
> configuration like:
> 
> 
>  
> 
> into:
> 
> 
>  
>
>  
> 
> We do, however, discourage the use of SerializedLayout and recommend 
> JsonLayout as a replacement:
> 
> 
>  
>
>  
> 
> Note that subsequent to the 2.9 release, for security reasons, Log4j does not 
> process DTD in XML files. If you used DTD for including snippets, you have to 
> use XInclude or Composite Configuration instead.
> 
> The Log4j 2.9.0 API, as well as many core components, maintains binary 
> compatibility with previous releases.
> 
> <https://github.com/apache/logging-log4j2/blob/master/RELEASE-NOTES.md#ga-release-290>GA
>  Release 2.9.0
> 
> Changes in this version include:
> 
> <https://github.com/apache/logging-log4j2/blob/master/RELEASE-NOTES.md#new-features>New
>  Features
> 
> LOG4J2-2008 <https://issues.apache.org/jira/browse/LOG4J2-2008>: Support 
> printing multiple StructuredData elements in RFC5424Layout.
> LOG4J2-1986 <https://issues.apache.org/jira/browse/LOG4J2-1986>: Public API 
> for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent.
> LOG4J2-1981 <https://issues.apache.org/jira/browse/LOG4J2-1981>: JsonLayout, 
> XmlLayout and YamlLayout support 0-byte termination of log events.
> LOG4J2-1864 <https://issues.apache.org/jira/browse/LOG4J2-1864>: Support 
> capped collections for MongoDb appender. Thanks to Matthias Kappeller.
> LOG4J2-1813 <https://issues.apache.org/jira/browse/LOG4J2-1813>: Log4j2 will 
> now print all internal logging to the console if system property log4j2.debug 
> is defined with any value (or no value).
> LOG4J2-1766 <https://issues.apache.org/jira/browse/LOG4J2-1766>: Temporary 
> compress directory during rollover (#88). Thanks to Pierrick HYMBERT.
> LOG4J2-1814 <https://issues.apache.org/jira/browse/LOG4J2-1814>: Added 
> wrapper classes CustomLoggerGenerator and ExtendedLoggerGenerator to avoid 
> class name with a dollar ($) character which has special meaning in many *nix 
> command line environments.
> LOG4J2-1884 <https://issues.apache.org/jira/browse/LOG4J2-1884>: Added 
> process ID (pid) pattern converter.
> LOG4J2-1699 <https://issues.apache.org/jira/browse/LOG4J2-1699>: Configurable 
> Log File Permissions with PosixFilePermission. Thanks to Demetrios Dimatos, 
> Pierrick HYMBERT.
> LOG4J2-1945 <https://issues.apache.org/jira/browse/LOG4J2-1945>: Generate 
> source jas for all test jars.
> LOG4J2-1934 <https://issues.apa

Re: Announcement is ugly

[Ralph Goers]

   - LOG4J2-1908 <https://issues.apache.org/jira/browse/LOG4J2-1908>:
>   Improved error message when misconfigured with multiple incompatible
>   appenders targeting same file.
>   - LOG4J2-1954 <https://issues.apache.org/jira/browse/LOG4J2-1954>:
>   Configurations with multiple root loggers now fail loudly.
>   - LOG4J2-1958 <https://issues.apache.org/jira/browse/LOG4J2-1958>:
>   Deprecate SerializedLayout and remove it as default.
>   - LOG4J2-1959 <https://issues.apache.org/jira/browse/LOG4J2-1959>:
>   Disable DTD processing in XML configuration files.
>   - LOG4J2-1950 <https://issues.apache.org/jira/browse/LOG4J2-1950>: Fix
>   docker build with jdk9 requirements (#84). Thanks to Pierrick HYMBERT.
>   - LOG4J2-1801 <https://issues.apache.org/jira/browse/LOG4J2-1801>: Add
>   more detail to WARN "Ignoring log event" messages printed to the console
>   after log4j was shut down.
>   - LOG4J2-1926 <https://issues.apache.org/jira/browse/LOG4J2-1926>:
>   Facilitate log4j use in Android applications: remove dependency on RMI and
>   Management APIs from log4j-api.
>   - LOG4J2-1956 <https://issues.apache.org/jira/browse/LOG4J2-1956>: JMS
>   Appender broker password should be a char[], not a String.
>   - LOG4J2-1917 <https://issues.apache.org/jira/browse/LOG4J2-1917>:
>   Support using java.util.ServiceLoader to locate Log4j 2 API providers.
>   - LOG4J2-1966 <https://issues.apache.org/jira/browse/LOG4J2-1966>:
>   Include separator option of PatternLayout in manual (and other updates).
>   Thanks to M Sazzadul Hoque.
>   - LOG4J2-1851 <https://issues.apache.org/jira/browse/LOG4J2-1851>: Move
>   server components from log4j-core to new log4-server module.
>   - LOG4J2-1991 <https://issues.apache.org/jira/browse/LOG4J2-1991>:
>   Refactor SimpleMessage to be concise and clear (#100) Thanks to .
>   - LOG4J2-2017 <https://issues.apache.org/jira/browse/LOG4J2-2017>:
>   Update Jackson from 2.8.9 to 2.9.0.
>   - LOG4J2-1868 <https://issues.apache.org/jira/browse/LOG4J2-1868>:
>   Update ZeroMQ's JeroMQ from 0.3.6 to 0.4.0.
>   - LOG4J2-1960 <https://issues.apache.org/jira/browse/LOG4J2-1960>:
>   Update ZeroMQ's JeroMQ from 0.4.0 to 0.4.1.
>   - LOG4J2-1974 <https://issues.apache.org/jira/browse/LOG4J2-1974>:
>   Update ZeroMQ's JeroMQ from 0.4.1 to 0.4.2.
>   - LOG4J2-1869 <https://issues.apache.org/jira/browse/LOG4J2-1869>:
>   Update Kafka client from 0.10.1.1 to 0.10.2.0
>   - LOG4J2-1962 <https://issues.apache.org/jira/browse/LOG4J2-1962>:
>   Update Kafka client from 0.10.2.0 to 0.11.0.0
>   - LOG4J2-1872 <https://issues.apache.org/jira/browse/LOG4J2-1872>:
>   Update JavaMail from 1.5.5 to 1.5.6.
>   - LOG4J2-1879 <https://issues.apache.org/jira/browse/LOG4J2-1879>:
>   Update JAnsi from 1.14 to 1.15.
>   - LOG4J2-1877 <https://issues.apache.org/jira/browse/LOG4J2-1877>:
>   Missing documentation for Max index limit in DefaultRolloverStrategy.
>   Thanks to Chandra Tungathurthi.
>   - LOG4J2-1899 <https://issues.apache.org/jira/browse/LOG4J2-1899>: Add
>   missing getters to classes in package org.apache.logging.log4j.core.net.ssl.
>   - LOG4J2-1900 <https://issues.apache.org/jira/browse/LOG4J2-1900>:
>   Update JAnsi from 1.15 to 1.16.
>   - LOG4J2- <https://issues.apache.org/jira/browse/LOG4J2->: Update SLF4J
>   from 1.7.24 to 1.7.25.
>   - LOG4J2-1938 <https://issues.apache.org/jira/browse/LOG4J2-1938>:
>   Update Jackson from 2.8.7 to 2.8.9.
>   - LOG4J2-1970 <https://issues.apache.org/jira/browse/LOG4J2-1970>:
>   Update HdrHistogram from 2.1.8 to 2.1.9.
>   - LOG4J2-1975 <https://issues.apache.org/jira/browse/LOG4J2-1975>:
>   Update javax.persistence from 2.1.0 to 2.1.1.
>   - LOG4J2-1976 <https://issues.apache.org/jira/browse/LOG4J2-1976>:
>   Update org.osgi.core from 4.3.1 to 6.0.0.
> 
> --
> 
> Apache Log4j 2.9.0 requires a minimum of Java 7 to build and run. Log4j 2.3
> was the last release that supported Java 6.
> 
> Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api
> component, however it does not implement some of the very implementation
> specific classes and methods. The package names and Maven groupId have been
> changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.
> 
> For complete information on Apache Log4j 2, including instructions on how
> to submit bug reports, patches, or suggestions for improvement, see the
> Apache Apache Log4j 2 website:
> 
> https://logging.apache.org/log4j/2.x/
> 
> On 31 August 2017 at 19:36, Ralph Goers  wrote:
> 
>> Although it looks great at GitHub, I

Log4j-audit

[Ralph Goers]

I just pushed the initial commit of Log4j Audit. It is by no means “done” but I 
am using it to perform some audit logging In a production environment. 
Unfortunately, the next major item I need to work on is the documentation. 
Right now there isn’t any, so it is going to be pretty difficult for you to 
understand what it is doing.  

All that said, please feel free to take a look.

Ralph

Log4j support for Tomcat, TomEE, JBoss, etc.

[Ralph Goers]

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?

Ralph

Re: [Log4j] Broken link to ScalaDoc on site

[Ralph Goers]

Should that page even be in the manual any more?

Ralph

> On Sep 6, 2017, at 12:23 PM, Mikael Ståldal  wrote:
> 
> The ScalaDoc link on 
> https://logging.apache.org/log4j/2.x/manual/scala-api.html is broken.
> 
> 

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

[Ralph Goers]

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: Log4j-audit

[Ralph Goers]

Thanks, I will look at JavaPoet and see if it makes things any simpler.

Only the web app and rest service depend on Spring. At this point it is a 
requirement.

What JavaEE stuff?

The catalog-war project is a user interface for editing the catalog. When I 
start creating documents I will take screen shots to document it. It is about 
95% complete. Ironically, the one piece that is missing is the button to 
persist the catalog back to git.

Ralph

> On Sep 6, 2017, at 12:49 PM, Mikael Ståldal  wrote:
> 
> I had a quick look. Some comments:
> 
> * You might want to use the JavaPoet library to generate Java source code, it 
> is Apache-licensed, available on Maven central and has no transitive 
> dependencies: https://github.com/square/javapoet
> 
> * Some users might not like to depend on Spring Framework.
> 
> * Some users might not like to depend on JavaEE stuff.
> 
> * Is the catalog.json supposed to be written/edited by hand?
> 
> 
> On 2017-09-03 04:21, Ralph Goers wrote:
>> I just pushed the initial commit of Log4j Audit. It is by no means “done” 
>> but I am using it to perform some audit logging In a production environment. 
>> Unfortunately, the next major item I need to work on is the documentation. 
>> Right now there isn’t any, so it is going to be pretty difficult for you to 
>> understand what it is doing.
>> All that said, please feel free to take a look.
>> Ralph
> 
> 

Re: Log4j-audit

[Ralph Goers]

Yup, it is needed in log4j-catalog-jpa to get javax.persistence. I probably 
don’t need it in the other modules (except for the wars).

Ralph

> On Sep 6, 2017, at 1:13 PM, Mikael Ståldal  wrote:
> 
> I see that several modules depends on javax:javaee-api. Is that necessary? It 
> should only be necessary in log4j-catalog-jpa, right?
> 
> I see that log4j-catalog-api and log4j-catalog-git depends on 
> javax:javaee-api and on Spring Framework. It would be better if those modules 
> didn't.
> 
> 
> On 2017-09-06 22:00, Ralph Goers wrote:
>> Thanks, I will look at JavaPoet and see if it makes things any simpler.
>> Only the web app and rest service depend on Spring. At this point it is a 
>> requirement.
>> What JavaEE stuff?
>> The catalog-war project is a user interface for editing the catalog. When I 
>> start creating documents I will take screen shots to document it. It is 
>> about 95% complete. Ironically, the one piece that is missing is the button 
>> to persist the catalog back to git.
>> Ralph
>>> On Sep 6, 2017, at 12:49 PM, Mikael Ståldal  wrote:
>>> 
>>> I had a quick look. Some comments:
>>> 
>>> * You might want to use the JavaPoet library to generate Java source code, 
>>> it is Apache-licensed, available on Maven central and has no transitive 
>>> dependencies: https://github.com/square/javapoet
>>> 
>>> * Some users might not like to depend on Spring Framework.
>>> 
>>> * Some users might not like to depend on JavaEE stuff.
>>> 
>>> * Is the catalog.json supposed to be written/edited by hand?
>>> 
>>> 
>>> On 2017-09-03 04:21, Ralph Goers wrote:
>>>> I just pushed the initial commit of Log4j Audit. It is by no means “done” 
>>>> but I am using it to perform some audit logging In a production 
>>>> environment. Unfortunately, the next major item I need to work on is the 
>>>> documentation. Right now there isn’t any, so it is going to be pretty 
>>>> difficult for you to understand what it is doing.
>>>> All that said, please feel free to take a look.
>>>> Ralph
>>> 
>>> 
> 
> 

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

[Ralph Goers]

That was more or less my thought.

In the main repo or a different one?

Ralph

> On Sep 6, 2017, at 3:07 PM, 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: Log4j support for Tomcat, TomEE, JBoss, etc.

[Ralph Goers]

I would expect all the dependencies to be marked as “provided” so it shouldn’t 
matter if they are all together.

Ralph


> On Sep 6, 2017, at 4:10 PM, Remko Popma  wrote:
> 
> I guess it depends on what dependencies this module requires. 
> 
> If this module requires Tomcat dependencies then perhaps  log4j-tomcat is 
> better because another container wouldn't want to drag in the Tomcat 
> dependencies. 
> 
> If there's no dependency on any specific container or on any javaEE jars I'd 
> keep it to generic container and split further when appropriate...
> 
> About the repo, this may be a good candidate for moving outside the main repo 
> to speed up the build. Update/release frequency may differ from the main 
> releases.  
> Maybe log4j-tools?
> 
> One thing about the separate repos is that integration is still incomplete. 
> Is the log4j-tools site published? It's not referenced from the Log4j2 site. 
> Also we should link to the log4j-tools artifacts from the main Download page. 
> 
> Remko 
> 
> (Shameless plug) Every java main() method deserves http://picocli.info
> 
>> On Sep 7, 2017, at 7:39, Gary Gregory  wrote:
>> 
>> The word container is so vague... container of what? Files, Applications,
>> NoSQL things? How about app-container?
>> 
>> Gary
>> 
>>> On Wed, Sep 6, 2017 at 4:07 PM, 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: Log4J 2.9.1 release

[Ralph Goers]

I thought about that, but it really is a pretty minor addition - it is one 
class. That said, if others feel that 2.10.0 is better I am happy to 
accommodate.

Ralph

> On Sep 11, 2017, at 8:31 AM, Gary Gregory  wrote:
> 
> Hi All,
> 
> It seems to me that the recent addition of the log4j-appserver module
> requires a version bump to 2.10.0, not 2.9.1.
> 
> Gary
> 
> On Mon, Sep 11, 2017 at 8:25 AM, Matt Sicker  wrote:
> 
>> I still have my outstanding branch that didn't make it into 2.9.0 that's
>> ready to merge, though if you're ready to do a bugfix release like that,
>> I'd rather wait for that first.
>> 
>> On 11 September 2017 at 03:43, Mikael Ståldal  wrote:
>> 
>>> Sounds good. Have we fixed all discovered regressions and new bugs in
>>> 2.9.0?
>>> 
>>> 
>>> 
>>> On 2017-09-11 09:39, Apache wrote:
>>> 
 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
 
 
>>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 

Re: Log4J 2.9.1 release

[Ralph Goers]

It was indeed my intention to have Jetty, JBoss, etc in that module. They are 
all mutually exclusive and presumably the dependencies would be 
provided so there really should be no conflict in having them 
all reside in the same module.

I haven’t been pushing splitting up core as I have been advocating that some of 
the things in the log4j 2 build might be better served being moved to another 
repo/sub-project much as we have done for Scala.

Ralph

> On Sep 11, 2017, at 8:45 AM, Gary Gregory  wrote:
> 
> I'm not sure how much of semantic versioning we really want to adopt or
> have adopted in the past. This is really about managing user's expectations
> when they update from one version to the next.
> 
> In this case, a new module feels like a new feature. Yes, the new module
> adds only one class, but we can slap a "Works with Apache Tomcat" sticker
> on the front now, so I am leaning toward 2.10.0.
> 
> Also, do we really want to end up with an log4j-appserver module as opposed
> to a log4j-tomcat module? What happens when we want to provide some code
> for JBoss, WebSphere, and so on? It seems heavy/messy to lump all of those
> dependencies in the one module. Especially since we have been talking
> splitting up the core module...
> 
> Thoughts?
> 
> Gary
> 
> On Mon, Sep 11, 2017 at 9:34 AM, Ralph Goers 
> wrote:
> 
>> I thought about that, but it really is a pretty minor addition - it is one
>> class. That said, if others feel that 2.10.0 is better I am happy to
>> accommodate.
>> 
>> Ralph
>> 
>>> On Sep 11, 2017, at 8:31 AM, Gary Gregory 
>> wrote:
>>> 
>>> Hi All,
>>> 
>>> It seems to me that the recent addition of the log4j-appserver module
>>> requires a version bump to 2.10.0, not 2.9.1.
>>> 
>>> Gary
>>> 
>>> On Mon, Sep 11, 2017 at 8:25 AM, Matt Sicker  wrote:
>>> 
>>>> I still have my outstanding branch that didn't make it into 2.9.0 that's
>>>> ready to merge, though if you're ready to do a bugfix release like that,
>>>> I'd rather wait for that first.
>>>> 
>>>> On 11 September 2017 at 03:43, Mikael Ståldal  wrote:
>>>> 
>>>>> Sounds good. Have we fixed all discovered regressions and new bugs in
>>>>> 2.9.0?
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2017-09-11 09:39, Apache wrote:
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Matt Sicker 
>>>> 
>> 
>> 
>> 

Automatic module names

[Ralph Goers]

I know we discussed module names in the past and decided not to go the route of 
modularizing now - in fact, we can’t until all of our dependencies are 
modularized. However, we can (and probably should) add the automatic module 
name as a manifest entry to each of our jars. My understanding is that these 
would be the package name of the individual modules. For the most part this 
should be trivial given the structure of our code base. However I have two 
concerns:

The package name used in log4j-api is org.apache.logging.log4j. My 
understanding is that the module name should match the package name, but I 
suspect most people would expect the module name to be 
org.apache.logging.log4j.api.
Both log4j-slf4j-impl and log4j-to-slf4j use org.apache.loggingj.slf4j. Notice 
that neither has log4j in the package name. These need to be separate packages 
to be able to define module names to them.

Thoughts?

Ralph

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

[Ralph Goers]

Looks like you removed unused imports that aren’t unused? For some reason this 
feels like it has happened before.

Ralph

> On Sep 11, 2017, at 11:36 AM, Apache Jenkins Server 
>  wrote:
> 
> See 
> 
> 
> Changes:
> 
> [garydgregory] [LOG4J2-2045] Update javax.mail from 1.5.6 to 1.6.0.
> 
> [garydgregory] Remove unused imports.
> 
> --
> [...truncated 1.14 MB...]
> [INFO] 
> [INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ 
> log4j-taglib ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO] Copying 3 resources
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ 
> log4j-taglib ---
> [INFO] Toolchain in maven-compiler-plugin: 
> JDK[/home/jenkins/tools/java/latest1.7]
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 20 source files to 
> 
> [INFO] 
> [INFO] --- maven-bundle-plugin:3.3.0:manifest (default) @ log4j-taglib ---
> [INFO] 
> [INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) 
> @ log4j-taglib ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO] Copying 3 resources
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ 
> log4j-taglib ---
> [INFO] Toolchain in maven-compiler-plugin: 
> JDK[/home/jenkins/tools/java/latest1.7]
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 13 source files to 
> 
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.20:test (default-test) @ log4j-taglib ---
> [INFO] Toolchain in maven-surefire-plugin: 
> JDK[/home/jenkins/tools/java/latest1.7]
> [INFO] 
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running org.apache.logging.log4j.taglib.CatchingTagTest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.906 
> s - in org.apache.logging.log4j.taglib.CatchingTagTest
> [INFO] Running org.apache.logging.log4j.taglib.SetLoggerTagTest
> ERROR StatusLogger No log4j2 configuration file found. Using default 
> configuration: logging only errors to the console. Set system property 
> 'log4j2.debug' to show Log4j2 internal initialization logging.
> [INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.569 
> s - in org.apache.logging.log4j.taglib.SetLoggerTagTest
> [INFO] Running org.apache.logging.log4j.taglib.LogTagTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.119 
> s - in org.apache.logging.log4j.taglib.LogTagTest
> [INFO] Running org.apache.logging.log4j.taglib.ExceptionAwareTagSupportTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.076 
> s - in org.apache.logging.log4j.taglib.ExceptionAwareTagSupportTest
> [INFO] Running org.apache.logging.log4j.taglib.DumpTagTest
> [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.182 
> s - in org.apache.logging.log4j.taglib.DumpTagTest
> [INFO] Running org.apache.logging.log4j.taglib.IfEnabledTagTest
> [INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.896 
> s - in org.apache.logging.log4j.taglib.IfEnabledTagTest
> [INFO] Running org.apache.logging.log4j.taglib.LoggerAwareTagSupportTest
> ERROR StatusLogger No log4j2 configuration file found. Using default 
> configuration: logging only errors to the console. Set system property 
> 'log4j2.debug' to show Log4j2 internal initialization logging.
> [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.546 
> s - in org.apache.logging.log4j.taglib.LoggerAwareTagSupportTest
> [INFO] Running org.apache.logging.log4j.taglib.EnterTagTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.837 
> s - in org.apache.logging.log4j.taglib.EnterTagTest
> [INFO] Running org.apache.logging.log4j.taglib.ExitTagTest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.899 
> s - in org.apache.logging.log4j.taglib.ExitTagTest
> [INFO] Running org.apache.logging.log4j.taglib.TagUtilsLevelTest
> [INFO] Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.148 
> s - in org.apache.logging.log4j.taglib.TagUtilsLevelTest
> [INFO] Running org.apache.logging.log4j.taglib.LoggingMessageTagSupportTest
> [INFO] Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.91 
> s - in org.apache.logging.log4j.taglib.LoggingMessageTagSupportTest
> [INFO] Running org.apache.logging.log4j.taglib.TagLevelTest
> [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.116 
> s - in org.apache.logg

Re: Log4J 2.9.1 release

[Ralph Goers]

I’d be OK with not publishing log4j-appserver right now but I’d prefer to leave 
the module in but remove it from the parent pom so that it doesn’t get built or 
deployed. Then I don’t think it has to be added to the release notes even 
though it technically is still part of the source release.

Does anyone have a problem with that?

Ralph

> On Sep 11, 2017, at 12:13 PM, Mikael Ståldal  wrote:
> 
> I don't think we should decide the versioning based on number of 
> classes/methods/LOC added. We should decide it based on features added. A new 
> feature warrants a bump in minor version, so the app server support should be 
> in 2.10.0.
> 
> We could also descope the app server support for now, and release 2.9.1 
> without it. I think that would be good given that we had quite some 
> regressions in 2.9.0.
> 
> 
> On 2017-09-11 17:34, Ralph Goers wrote:
>> I thought about that, but it really is a pretty minor addition - it is one 
>> class. That said, if others feel that 2.10.0 is better I am happy to 
>> accommodate.
>> Ralph
>>> On Sep 11, 2017, at 8:31 AM, Gary Gregory  wrote:
>>> 
>>> Hi All,
>>> 
>>> It seems to me that the recent addition of the log4j-appserver module
>>> requires a version bump to 2.10.0, not 2.9.1.
>>> 
>>> Gary
>>> 
>>> On Mon, Sep 11, 2017 at 8:25 AM, Matt Sicker  wrote:
>>> 
>>>> I still have my outstanding branch that didn't make it into 2.9.0 that's
>>>> ready to merge, though if you're ready to do a bugfix release like that,
>>>> I'd rather wait for that first.
>>>> 
>>>> On 11 September 2017 at 03:43, Mikael Ståldal  wrote:
>>>> 
>>>>> Sounds good. Have we fixed all discovered regressions and new bugs in
>>>>> 2.9.0?
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2017-09-11 09:39, Apache wrote:
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Matt Sicker 
>>>> 
> 
> 

Re: Log4J 2.9.1 release

[Ralph Goers]

OK. The module is commented out along with the update to changes.xml.

Ralph

> On Sep 11, 2017, at 4:56 PM, Matt Sicker  wrote:
> 
> Sounds good to me. I'd rather get some more features in for 2.10.0 first.
> 
> On 11 September 2017 at 18:33, Gary Gregory  wrote:
> 
>> On Mon, Sep 11, 2017 at 5:19 PM, Ralph Goers 
>> wrote:
>> 
>>> I’d be OK with not publishing log4j-appserver right now but I’d prefer to
>>> leave the module in but remove it from the parent pom so that it doesn’t
>>> get built or deployed. Then I don’t think it has to be added to the
>> release
>>> notes even though it technically is still part of the source release.
>>> 
>>> Does anyone have a problem with that?
>>> 
>> 
>> Sounds reasonable.
>> 
>> Gary
>> 
>> 
>>> 
>>> Ralph
>>> 
>>>> On Sep 11, 2017, at 12:13 PM, Mikael Ståldal  wrote:
>>>> 
>>>> I don't think we should decide the versioning based on number of
>>> classes/methods/LOC added. We should decide it based on features added. A
>>> new feature warrants a bump in minor version, so the app server support
>>> should be in 2.10.0.
>>>> 
>>>> We could also descope the app server support for now, and release 2.9.1
>>> without it. I think that would be good given that we had quite some
>>> regressions in 2.9.0.
>>>> 
>>>> 
>>>> On 2017-09-11 17:34, Ralph Goers wrote:
>>>>> I thought about that, but it really is a pretty minor addition - it is
>>> one class. That said, if others feel that 2.10.0 is better I am happy to
>>> accommodate.
>>>>> Ralph
>>>>>> On Sep 11, 2017, at 8:31 AM, Gary Gregory 
>>> wrote:
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> It seems to me that the recent addition of the log4j-appserver module
>>>>>> requires a version bump to 2.10.0, not 2.9.1.
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Mon, Sep 11, 2017 at 8:25 AM, Matt Sicker 
>> wrote:
>>>>>> 
>>>>>>> I still have my outstanding branch that didn't make it into 2.9.0
>>> that's
>>>>>>> ready to merge, though if you're ready to do a bugfix release like
>>> that,
>>>>>>> I'd rather wait for that first.
>>>>>>> 
>>>>>>> On 11 September 2017 at 03:43, Mikael Ståldal 
>>> wrote:
>>>>>>> 
>>>>>>>> Sounds good. Have we fixed all discovered regressions and new bugs
>> in
>>>>>>>> 2.9.0?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2017-09-11 09:39, Apache wrote:
>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Matt Sicker 
>>>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Automatic module names

[Ralph Goers]

You should read (or re-read) this - 
http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html 
<http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html>. I believe it 
is the most likely standard to be adopted.

Ralph

> On Sep 11, 2017, at 6:26 PM, Matt Sicker  wrote:
> 
> Is it possible to make the JPMS module names the same as the OSGi ones? The
> default OSGi naming scheme is basically:
> 
> groupId: org.apache.logging.log4j, artifactId: log4j-foo becomes bundleId:
> org.apache.logging.log4j.foo
> 
> On 11 September 2017 at 13:01, Gary Gregory  wrote:
> 
>> On Mon, Sep 11, 2017 at 11:27 AM, Ralph Goers 
>> wrote:
>> 
>>> I know we discussed module names in the past and decided not to go the
>>> route of modularizing now - in fact, we can’t until all of our
>> dependencies
>>> are modularized. However, we can (and probably should) add the automatic
>>> module name as a manifest entry to each of our jars. My understanding is
>>> that these would be the package name of the individual modules. For the
>>> most part this should be trivial given the structure of our code base.
>>> However I have two concerns:
>>> 
>>> The package name used in log4j-api is org.apache.logging.log4j. My
>>> understanding is that the module name should match the package name, but
>> I
>>> suspect most people would expect the module name to be
>>> org.apache.logging.log4j.api.
>>> 
>> 
>> I think we can leave that one as is. The package is
>> org.apache.logging.log4j and that seems reasonable. It's the module
>> name/artifact ID that we chose that is "different". If anything, I would
>> change that.
>> 
>> 
>>> Both log4j-slf4j-impl and log4j-to-slf4j use org.apache.loggingj.slf4j.
>>> Notice that neither has log4j in the package name. These need to be
>>> separate packages to be able to define module names to them.
>>> 
>>> Thoughts?
>>> 
>> 
>> I think we should just bite the bullet and repackage these two under
>> org.apache.logging.log4j. That means changing the module name and artifact
>> ID though to avoid jar hell. log4j-slf4j-to-log4j and log4j-log4j-to-slf4j?
>> A bit wordy... proposals?
>> 
>> Gary
>> 
>> 
>>> Ralph
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Automatic module names

[Ralph Goers]

Actually, re-reading this again makes it clear to me that log4j-slf4j-impl and 
log4j-to-slf4j SHOULD use the same package name as it prevents them from both 
being present at the same time. Obviously, their module names still have to be 
different but this could mean the code doesn’t really need to be modified.

Ralph

> On Sep 11, 2017, at 6:26 PM, Matt Sicker  wrote:
> 
> Is it possible to make the JPMS module names the same as the OSGi ones? The
> default OSGi naming scheme is basically:
> 
> groupId: org.apache.logging.log4j, artifactId: log4j-foo becomes bundleId:
> org.apache.logging.log4j.foo
> 
> On 11 September 2017 at 13:01, Gary Gregory  wrote:
> 
>> On Mon, Sep 11, 2017 at 11:27 AM, Ralph Goers 
>> wrote:
>> 
>>> I know we discussed module names in the past and decided not to go the
>>> route of modularizing now - in fact, we can’t until all of our
>> dependencies
>>> are modularized. However, we can (and probably should) add the automatic
>>> module name as a manifest entry to each of our jars. My understanding is
>>> that these would be the package name of the individual modules. For the
>>> most part this should be trivial given the structure of our code base.
>>> However I have two concerns:
>>> 
>>> The package name used in log4j-api is org.apache.logging.log4j. My
>>> understanding is that the module name should match the package name, but
>> I
>>> suspect most people would expect the module name to be
>>> org.apache.logging.log4j.api.
>>> 
>> 
>> I think we can leave that one as is. The package is
>> org.apache.logging.log4j and that seems reasonable. It's the module
>> name/artifact ID that we chose that is "different". If anything, I would
>> change that.
>> 
>> 
>>> Both log4j-slf4j-impl and log4j-to-slf4j use org.apache.loggingj.slf4j.
>>> Notice that neither has log4j in the package name. These need to be
>>> separate packages to be able to define module names to them.
>>> 
>>> Thoughts?
>>> 
>> 
>> I think we should just bite the bullet and repackage these two under
>> org.apache.logging.log4j. That means changing the module name and artifact
>> ID though to avoid jar hell. log4j-slf4j-to-log4j and log4j-log4j-to-slf4j?
>> A bit wordy... proposals?
>> 
>> Gary
>> 
>> 
>>> Ralph
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Automatic module names

[Ralph Goers]

While true that would be immensely confusing to users I think. However, if two 
modules have the same packages in them you will get an error at runtime.

"Now consider again the key restriction that a package must be found in one and 
only one module. This restriction applies to hidden packages as well as 
exported ones. Therefore if your application depends on two modules and both 
have the same hidden package, your application cannot be run as the packages 
clash"

Ralph

> On Sep 11, 2017, at 10:30 PM, Remko Popma  wrote:
> 
> Isn't it the opposite? Giving them the same module name will prevents them 
> from being used together, which is what we want:
> 
> http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html?m=1
> "JPMS will simply refuse to start a modulepath where two modules have the 
> same name, even if they contain different packages."
> 
> (Shameless plug) Every java main() method deserves http://picocli.info
> 
>> On Sep 12, 2017, at 13:29, Ralph Goers  wrote:
>> 
>> Actually, re-reading this again makes it clear to me that log4j-slf4j-impl 
>> and log4j-to-slf4j SHOULD use the same package name as it prevents them from 
>> both being present at the same time. Obviously, their module names still 
>> have to be different but this could mean the code doesn’t really need to be 
>> modified.
>> 
>> Ralph
>> 
>>> On Sep 11, 2017, at 6:26 PM, Matt Sicker  wrote:
>>> 
>>> Is it possible to make the JPMS module names the same as the OSGi ones? The
>>> default OSGi naming scheme is basically:
>>> 
>>> groupId: org.apache.logging.log4j, artifactId: log4j-foo becomes bundleId:
>>> org.apache.logging.log4j.foo
>>> 
>>>> On 11 September 2017 at 13:01, Gary Gregory  wrote:
>>>> 
>>>> On Mon, Sep 11, 2017 at 11:27 AM, Ralph Goers 
>>>> wrote:
>>>> 
>>>>> I know we discussed module names in the past and decided not to go the
>>>>> route of modularizing now - in fact, we can’t until all of our
>>>> dependencies
>>>>> are modularized. However, we can (and probably should) add the automatic
>>>>> module name as a manifest entry to each of our jars. My understanding is
>>>>> that these would be the package name of the individual modules. For the
>>>>> most part this should be trivial given the structure of our code base.
>>>>> However I have two concerns:
>>>>> 
>>>>> The package name used in log4j-api is org.apache.logging.log4j. My
>>>>> understanding is that the module name should match the package name, but
>>>> I
>>>>> suspect most people would expect the module name to be
>>>>> org.apache.logging.log4j.api.
>>>>> 
>>>> 
>>>> I think we can leave that one as is. The package is
>>>> org.apache.logging.log4j and that seems reasonable. It's the module
>>>> name/artifact ID that we chose that is "different". If anything, I would
>>>> change that.
>>>> 
>>>> 
>>>>> Both log4j-slf4j-impl and log4j-to-slf4j use org.apache.loggingj.slf4j.
>>>>> Notice that neither has log4j in the package name. These need to be
>>>>> separate packages to be able to define module names to them.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>> 
>>>> I think we should just bite the bullet and repackage these two under
>>>> org.apache.logging.log4j. That means changing the module name and artifact
>>>> ID though to avoid jar hell. log4j-slf4j-to-log4j and log4j-log4j-to-slf4j?
>>>> A bit wordy... proposals?
>>>> 
>>>> Gary
>>>> 
>>>> 
>>>>> Ralph
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Matt Sicker 
>> 
>> 

Log4j-core and Android?

[Ralph Goers]

We are getting Jira issues about getting log4j to work in Android. At first, 
all I thought was required was getting the API to function on top of Android’s 
logging system. However, it seems that there are some who want to use the 
RollingFileAppender or perhaps other appenders. The issue I have is that I am 
pretty sure there are other things inside core that won’t work in Android, 
which was why my first attempt was to just get the API working there.

Right now there are 8 open issues that mention Android. LOG4J2-1915, 
LOG4J2-1920 LOG4J2-1921 all say that 2.8.2 doesn’t work, which was before the 
Java 9 support was added. LOG4J2-2042 says 2.9 doesn’t work because of a 
dependency on java.lang.management classes. LOG4J2-1920 says it has an error 
because the ScriptEngineManager is not available.

I am not sure how to solve this. We could just say Android is not supported 
although that would likely cause problems for a lot of people. We could only 
support API integration, as I first tried to do,  We could put in a bunch of 
code to try to detect android and disable stuff that doesn’t work there, but 
that is quite a bit of work and as far as I can tell none of the committers 
work with Android. Finally, we could create a log4j-android that contains the 
API combined with a minimal version of core.

Any thoughts on this?

Ralph

Re: Log4j-core and Android?

[Ralph Goers]

Great. But how would you do it?

Ralph

> On Sep 13, 2017, at 7:11 AM, Gary Gregory  wrote:
> 
> I would like to see support for Android, all in our one code base, for now.
> 
> Gary
> 
> On Sep 13, 2017 08:02, "Ralph Goers"  wrote:
> 
>> We are getting Jira issues about getting log4j to work in Android. At
>> first, all I thought was required was getting the API to function on top of
>> Android’s logging system. However, it seems that there are some who want to
>> use the RollingFileAppender or perhaps other appenders. The issue I have is
>> that I am pretty sure there are other things inside core that won’t work in
>> Android, which was why my first attempt was to just get the API working
>> there.
>> 
>> Right now there are 8 open issues that mention Android. LOG4J2-1915,
>> LOG4J2-1920 LOG4J2-1921 all say that 2.8.2 doesn’t work, which was before
>> the Java 9 support was added. LOG4J2-2042 says 2.9 doesn’t work because of
>> a dependency on java.lang.management classes. LOG4J2-1920 says it has an
>> error because the ScriptEngineManager is not available.
>> 
>> I am not sure how to solve this. We could just say Android is not
>> supported although that would likely cause problems for a lot of people. We
>> could only support API integration, as I first tried to do,  We could put
>> in a bunch of code to try to detect android and disable stuff that doesn’t
>> work there, but that is quite a bit of work and as far as I can tell none
>> of the committers work with Android. Finally, we could create a
>> log4j-android that contains the API combined with a minimal version of core.
>> 
>> Any thoughts on this?
>> 
>> Ralph
>> 

Re: Log4J 2.9.1 release

[Ralph Goers]

I plan on doing the release build this weekend. Please hold off on merging new 
features until after that. I agree with your plan.

Ralph

> On Sep 14, 2017, at 12:09 PM, Mikael Ståldal  wrote:
> 
> So do we plan to release 2.9.1 soon? Should we wait with merging new features 
> into master?
> 
> I think it would be good to release 2.9.1 before the Java 9 release on 
> September 21th, since we have fixed a few Java 9 related issues.
> 
> Then we should wait for the Java 9 release, and test Log4j 2.9.1 with Java 9 
> GA to verify that everything works fine. If not, we can do a 2.9.2 to fix any 
> issues found.
> 
> Then we add new features for 2.10.0.
> 
> 
> On 2017-09-12 06:18, Ralph Goers wrote:
>> OK. The module is commented out along with the update to changes.xml.
>> Ralph
> 

Chainsaw

[Ralph Goers]

Chainsaw has been in limbo for far too long. There really is only 1 active 
committer on the project and he has been telling people to use the latest code 
in master in production, which is not acceptable by the Apache release policy. 
We either need to have a release performed by the time of the next board report 
in November or retire it.  

Are there any volunteers?

Ralph

Re: [Log4j] Missing Git tag for 2.9.0 release

[Ralph Goers]

> On Sep 15, 2017, at 11:44 AM, Mikael Ståldal  wrote:
> 
> It seems like we miss a Git tag for the 2.9.0 release.

Thanks. I forgot to add the tag after the release vote. I will do that. The rc1 
tag is there.

Ralph

Re: Chainsaw

[Ralph Goers]

Since Scott is telling people to download the source, build it and use it I 
would feel safe in saying it is production ready. However, I would take a look 
at the web site and see if anything there needs to be updated.

Ralph

> On Sep 17, 2017, at 12:00 PM, Matt Sicker  wrote:
> 
> If Scott can polish up whatever needs to be done before a release, I can
> help coordinate the release itself. I'm not too familiar with the project,
> so I wouldn't know if it's release-ready or not beforehand, though.
> 
> On 14 September 2017 at 19:46, Ralph Goers 
> wrote:
> 
>> Chainsaw has been in limbo for far too long. There really is only 1 active
>> committer on the project and he has been telling people to use the latest
>> code in master in production, which is not acceptable by the Apache release
>> policy. We either need to have a release performed by the time of the next
>> board report in November or retire it.
>> 
>> Are there any volunteers?
>> 
>> Ralph
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: [Log4j] Release in README.md

[Ralph Goers]

I have an issue with anything that references a release version in the README. 
Keeping that up to date requires that it manually be updated before the release 
to the release version and then be updated again after the release to the 
snapshot version. Everywhere else a version appears in things that are part of 
the release it is rendered via a velocity template using the release version in 
the pom.  I really do not want to be manually updating this.

Ralph

> On Sep 16, 2017, at 2:58 AM, Mikael Ståldal  wrote:
> 
> The Git tagging is already there, in 17.a.
> 
> Updating README.md is not there, I suggest we add between 6 and 7:
> 
> x. Update README.md with the release version.
> 
> 
> On 2017-09-15 23:04, Matt Sicker wrote:
>> The release checklist is on the wiki:
>> https://wiki.apache.org/logging/Log4j2ReleaseGuide
>> I don't think I have an account on there.
>> On 15 September 2017 at 13:53, Mikael Ståldal  wrote:
>>> We (should) have a link to the latest release in README.md in Git.
>>> However, that was not updated since 2.8. I have updated it to 2.9.0 now.
>>> 
>>> We should make sure to update it for every release.
>>> 
>>> Do we have a release checklist? On that we should add to create a Git tag,
>>> and update README.md.
>>> 
> 
> 

Re: [Log4j] Release in README.md

[Ralph Goers]

I am replacing the section in the README regarding Maven and Gradle with a link 
to the relevant web site page.

Ralph

> On Sep 17, 2017, at 8:24 PM, Ralph Goers  wrote:
> 
> I have an issue with anything that references a release version in the 
> README. Keeping that up to date requires that it manually be updated before 
> the release to the release version and then be updated again after the 
> release to the snapshot version. Everywhere else a version appears in things 
> that are part of the release it is rendered via a velocity template using the 
> release version in the pom.  I really do not want to be manually updating 
> this.
> 
> Ralph
> 
>> On Sep 16, 2017, at 2:58 AM, Mikael Ståldal  wrote:
>> 
>> The Git tagging is already there, in 17.a.
>> 
>> Updating README.md is not there, I suggest we add between 6 and 7:
>> 
>> x. Update README.md with the release version.
>> 
>> 
>> On 2017-09-15 23:04, Matt Sicker wrote:
>>> The release checklist is on the wiki:
>>> https://wiki.apache.org/logging/Log4j2ReleaseGuide
>>> I don't think I have an account on there.
>>> On 15 September 2017 at 13:53, Mikael Ståldal  wrote:
>>>> We (should) have a link to the latest release in README.md in Git.
>>>> However, that was not updated since 2.8. I have updated it to 2.9.0 now.
>>>> 
>>>> We should make sure to update it for every release.
>>>> 
>>>> Do we have a release checklist? On that we should add to create a Git tag,
>>>> and update README.md.
>>>> 
>> 
>> 
> 
> 
> 

Re: Moving log4net-logviewer to apache

[Ralph Goers]

> On Sep 17, 2017, at 9:47 PM, Stefan Bodewig  wrote:
> 
> On 2017-09-09, Dominik Psenner wrote:
> 
>> What does the community think should happen? Are there people out there who
>> use log4net-logviewer or any of its binaries?
> 
> I don't.
> 
> https://github.com/wallymathieu/log4net-logviewer/issues/7#issuecomment-327423060
> and the following comment sounds as if "moving to Apache" was seen as a
> way to keep logviewer maintained. I'm not convinced this would be any
> easier here than in github so I doubt logviewer would win much by moving
> while we (well, actually mostly you, Dominik) would have more code to
> maintain.


I would put it another way. In order for it to move to Logging Services I would 
want to know that there are at least 3 active committers on the project.

Ralph

[VOTE] Release Log4j 2.9.1-rc1

[Ralph Goers]

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

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

The vote will remain open for 72 hours (or more if required). All votes are 
welcome and we encourage everyone to test the release, but only Logging PMC 
votes are “officially” counted. As always, at least 3 +1 votes and more 
positive than negative votes are required.

Changes in this version include:

Fixed Bugs

• LOG4J2-1988: Prevent ConcurrentModificationException with 
AsyncLoggerConfig.
• LOG4J2-1914: Prevent ConcurrentModificationException with 
AsyncLoggerConfig.
• LOG4J2-2048: Increase default queue size for AsyncAppender from 128 
to 1024.
• LOG4J2-2035: Fix documentation to clarify disruptor-3.3.4 is now 
required for async loggers: disruptor-3.3.3 was never released.
• LOG4J2-2030: Inspect all known ClassLoaders to locate the service 
provider.
• LOG4J2-2028: Java 9 StackLocator was not properly skipping the 
initial stack frames. Thanks to Jason Tedor.
• LOG4J2-2026: java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature(). Thanks to Leon Finker.
• LOG4J2-2029: Marker examples should not use deprecated flow APIs. 
Thanks to Fabrizio Cucci.
• LOG4J2-1936: ClassNotFoundException when making all loggers 
asynchronous under OSGi environment. Thanks to Helber Belmiro.

Changes

• LOG4J2-2023: Use a class' canonical name instead of name to create 
its logger name.
• LOG4J2-2043: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9.)
• LOG4J2-2044: Update Apache Commons CSV from 1.4 to 1.5.
• LOG4J2-2045: Update javax.mail from 1.5.6 to 1.6.0.
• LOG4J2-2046: Update Apache Commons Compress from 1.13 to 1.14.
• LOG4J2-2047: Update Cassandra driver from 3.1.0 to 3.1.4.
• LOG4J2-2049: Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1.

Tag: 
a)  for a new copy do "git clone 
https://git-wip-us.apache.org/repos/asf/logging-log4j2.git"; and then "git 
checkout tags/log4j-2.9.1-rc1”
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.9.1-rc1”

Web Site:  http://rgoers.github.io/log4j2-site/index.html 

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

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

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

Ralph

Re: [VOTE] Release Log4j 2.9.1-rc1

[Ralph Goers]

My +1

Ralph

> On Sep 18, 2017, at 12:07 AM, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.9.1, the next version of the Log4j 2 
> project.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for 72 hours (or more if required). All votes are 
> welcome and we encourage everyone to test the release, but only Logging PMC 
> votes are “officially” counted. As always, at least 3 +1 votes and more 
> positive than negative votes are required.
> 
> Changes in this version include:
> 
> Fixed Bugs
> 
>   • LOG4J2-1988: Prevent ConcurrentModificationException with 
> AsyncLoggerConfig.
>   • LOG4J2-1914: Prevent ConcurrentModificationException with 
> AsyncLoggerConfig.
>   • LOG4J2-2048: Increase default queue size for AsyncAppender from 128 
> to 1024.
>   • LOG4J2-2035: Fix documentation to clarify disruptor-3.3.4 is now 
> required for async loggers: disruptor-3.3.3 was never released.
>   • LOG4J2-2030: Inspect all known ClassLoaders to locate the service 
> provider.
>   • LOG4J2-2028: Java 9 StackLocator was not properly skipping the 
> initial stack frames. Thanks to Jason Tedor.
>   • LOG4J2-2026: java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(). Thanks to Leon Finker.
>   • LOG4J2-2029: Marker examples should not use deprecated flow APIs. 
> Thanks to Fabrizio Cucci.
>   • LOG4J2-1936: ClassNotFoundException when making all loggers 
> asynchronous under OSGi environment. Thanks to Helber Belmiro.
> 
> Changes
> 
>   • LOG4J2-2023: Use a class' canonical name instead of name to create 
> its logger name.
>   • LOG4J2-2043: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9.)
>   • LOG4J2-2044: Update Apache Commons CSV from 1.4 to 1.5.
>   • LOG4J2-2045: Update javax.mail from 1.5.6 to 1.6.0.
>   • LOG4J2-2046: Update Apache Commons Compress from 1.13 to 1.14.
>   • LOG4J2-2047: Update Cassandra driver from 3.1.0 to 3.1.4.
>   • LOG4J2-2049: Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1.
> 
> Tag: 
> a)  for a new copy do "git clone 
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git"; and then "git 
> checkout tags/log4j-2.9.1-rc1”
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.9.1-rc1”
> 
> Web Site:  http://rgoers.github.io/log4j2-site/index.html 
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1030
> 
> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/
> 
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1030/org/apache/logging/log4j/
> 
> Ralph
> 

Re: [log4j] "JDK 9 Ready"

[Ralph Goers]

> On Sep 21, 2017, at 7:35 AM, Gary Gregory  wrote:
> 
> Hi,
> 
> Oracle has asked me if we have an official announcement that we are "JDK 9
> ready". Do we?
> 
> We are listed here:
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach 
> 

I have been hesitant to do that simply because we are not modularized. There is 
one user I have seen who is trying to build an application that only uses 
modularized components. I don’t think he is going to be successful at this 
point.

On the other hand, if JDK 9 ready means that we support running in Java 9 
applications then the answer would be yes, so it depends on what the definition 
of “JDK 9 Ready” is. I did send an mail to Rory a couple of weeks ago saying 
Log4j was ready to run in Java 9.

Ralph

Re: [log4j] "JDK 9 Ready"

[Ralph Goers]

> On Sep 21, 2017, at 9:36 AM, Gary Gregory  wrote:
> 
> On Thu, Sep 21, 2017 at 9:39 AM, Ralph Goers 
> wrote:
> 
>> 
>>> On Sep 21, 2017, at 7:35 AM, Gary Gregory 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> Oracle has asked me if we have an official announcement that we are "JDK
>> 9
>>> ready". Do we?
>>> 
>>> We are listed here:
>>> https://wiki.openjdk.java.net/display/quality/Quality+Outreach <
>> https://wiki.openjdk.java.net/display/quality/Quality+Outreach>
>> 
>> I have been hesitant to do that simply because we are not modularized.
>> There is one user I have seen who is trying to build an application that
>> only uses modularized components. I don’t think he is going to be
>> successful at this point.
>> 
>> On the other hand, if JDK 9 ready means that we support running in Java 9
>> applications then the answer would be yes, so it depends on what the
>> definition of “JDK 9 Ready” is. I did send an mail to Rory a couple of
>> weeks ago saying Log4j was ready to run in Java 9.
>> 
> 
> Just to close the loop, it is Rory I am emailing with as well.
> 
> Gary

OK, then you might want to clarify what JDK 9 Ready really means.

Ralph

Re: [log4j] "JDK 9 Ready"

[Ralph Goers]

Also, I plan on adding the manifest headers so Log4j classifies as somewhat 
modularized before the next release.

Ralph

> On Sep 21, 2017, at 1:08 PM, Ralph Goers  wrote:
> 
>> 
>> On Sep 21, 2017, at 9:36 AM, Gary Gregory  wrote:
>> 
>> On Thu, Sep 21, 2017 at 9:39 AM, Ralph Goers 
>> wrote:
>> 
>>> 
>>>> On Sep 21, 2017, at 7:35 AM, Gary Gregory 
>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Oracle has asked me if we have an official announcement that we are "JDK
>>> 9
>>>> ready". Do we?
>>>> 
>>>> We are listed here:
>>>> https://wiki.openjdk.java.net/display/quality/Quality+Outreach <
>>> https://wiki.openjdk.java.net/display/quality/Quality+Outreach>
>>> 
>>> I have been hesitant to do that simply because we are not modularized.
>>> There is one user I have seen who is trying to build an application that
>>> only uses modularized components. I don’t think he is going to be
>>> successful at this point.
>>> 
>>> On the other hand, if JDK 9 ready means that we support running in Java 9
>>> applications then the answer would be yes, so it depends on what the
>>> definition of “JDK 9 Ready” is. I did send an mail to Rory a couple of
>>> weeks ago saying Log4j was ready to run in Java 9.
>>> 
>> 
>> Just to close the loop, it is Rory I am emailing with as well.
>> 
>> Gary
> 
> OK, then you might want to clarify what JDK 9 Ready really means.
> 
> Ralph

Re: [VOTE] Release Log4j 2.9.1-rc1

[Ralph Goers]

I changed it some, yes.

Ralph

> On Sep 21, 2017, at 2:55 PM, Remko Popma  wrote:
> 
> I started writing the blog post for 2.9.1.
> Quick question: no changes to the announcement text this time, is that
> correct?
> 
> On Thu, Sep 21, 2017 at 1:12 PM, Ralph Goers 
> wrote:
> 
>> My +1
>> 
>> Ralph
>> 
>>> On Sep 18, 2017, at 12:07 AM, Ralph Goers 
>> wrote:
>>> 
>>> This is a vote to release Log4j 2.9.1, the next version of the Log4j 2
>> project.
>>> 
>>> Please download, test, and cast your votes on the log4j developers list.
>>> [] +1, release the artifacts
>>> [] -1, don't release because...
>>> 
>>> The vote will remain open for 72 hours (or more if required). All votes
>> are welcome and we encourage everyone to test the release, but only Logging
>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>> positive than negative votes are required.
>>> 
>>> Changes in this version include:
>>> 
>>> Fixed Bugs
>>> 
>>>  • LOG4J2-1988: Prevent ConcurrentModificationException with
>> AsyncLoggerConfig.
>>>  • LOG4J2-1914: Prevent ConcurrentModificationException with
>> AsyncLoggerConfig.
>>>  • LOG4J2-2048: Increase default queue size for AsyncAppender from
>> 128 to 1024.
>>>  • LOG4J2-2035: Fix documentation to clarify disruptor-3.3.4 is now
>> required for async loggers: disruptor-3.3.3 was never released.
>>>  • LOG4J2-2030: Inspect all known ClassLoaders to locate the
>> service provider.
>>>  • LOG4J2-2028: Java 9 StackLocator was not properly skipping the
>> initial stack frames. Thanks to Jason Tedor.
>>>  • LOG4J2-2026: java.lang.AbstractMethodError: javax.xml.parsers.
>> DocumentBuilderFactory.setFeature(). Thanks to Leon Finker.
>>>  • LOG4J2-2029: Marker examples should not use deprecated flow
>> APIs. Thanks to Fabrizio Cucci.
>>>  • LOG4J2-1936: ClassNotFoundException when making all loggers
>> asynchronous under OSGi environment. Thanks to Helber Belmiro.
>>> 
>>> Changes
>>> 
>>>  • LOG4J2-2023: Use a class' canonical name instead of name to
>> create its logger name.
>>>  • LOG4J2-2043: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9.)
>>>  • LOG4J2-2044: Update Apache Commons CSV from 1.4 to 1.5.
>>>  • LOG4J2-2045: Update javax.mail from 1.5.6 to 1.6.0.
>>>  • LOG4J2-2046: Update Apache Commons Compress from 1.13 to 1.14.
>>>  • LOG4J2-2047: Update Cassandra driver from 3.1.0 to 3.1.4.
>>>  • LOG4J2-2049: Update Apache Kafka Client from 0.11.0.0 to
>> 0.11.0.1.
>>> 
>>> Tag:
>>> a)  for a new copy do "git clone https://git-wip-us.apache.org/
>> repos/asf/logging-log4j2.git" and then "git checkout tags/log4j-2.9.1-rc1”
>>> b) for an existing working copy to “git pull” and then “git checkout
>> tags/log4j-2.9.1-rc1”
>>> 
>>> Web Site:  http://rgoers.github.io/log4j2-site/index.html
>>> 
>>> Maven Artifacts: https://repository.apache.org/content/repositories/
>> orgapachelogging-1030
>>> 
>>> Distribution archives: https://dist.apache.org/repos/
>> dist/dev/logging/log4j/
>>> 
>>> You may download all the Maven artifacts by executing:
>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>> https://repository.apache.org/content/repositories/
>> orgapachelogging-1030/org/apache/logging/log4j/
>>> 
>>> Ralph
>>> 
>> 
>> 
>> 

Release Announcement: General Availability of JDK 9

[Ralph Goers]

This was copied from another list. We stopped getting these emails when we 
merged all the dev lists and Rory doesn’t seem to have fixed the problem.

Ralph


Three items to share with you today 

JDK 9 General Availability 
GPL'd binaries from Oracle are available here:
http://jdk.java.net/9 
See Mark Reinhold's email for more details on the Release [1] 
delivery of Project Jigsaw [2]
Are you JDK 9 Ready ?
The Quality Outreach wiki has been updated to include a JDK 9 Ready column.  
If you would like us to identify your project as JDK 9 ready , please let me 
know and I will add it to the wiki.
Quality Outreach Report for September 2017 is available
many thanks for your continued support and welcome to the new projects!
Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html 

[2] https://mreinhold.org/blog/jigsaw-complete 


-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 
___
slf4j-dev mailing list
slf4j-...@qos.ch 
http://mailman.qos.ch/mailman/listinfo/slf4j-dev 

[ANNOUNCE] Apache Log4j 2.9.1 released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.9.1 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

This release contains bugfixes and minor enhancements.

As of Log4j 2.9.0, the Log4j API was modified to use java.util.ServiceLoader to 
locate Log4j implementations, although the former binding mechanism is still 
supported. The Log4j jar is now a multi-release jar to provide implementations 
of Java 9 specific classes. Multi-release jars are not supported by the OSGi 
specification so OSGi modules will not be able to take advantage of these 
implementations but will not lose functionality as they will fall back to the 
implementations used in Java 7 and 8. More details on the new features and 
fixes are itemized below. Note that some tools are not compatible with 
multi-release jars and may fail trying to process class files in the 
META-INF/versions/9 folder. Those errors should be reported to the tool vendor.

Note that subsequent to the 2.9.0 release, for security reasons, 
SerializedLayout is deprecated and no longer used as default in the Socket and 
JMS appenders. SerializedLayout can still be used as before, but has to be 
specified explicitly. To retain old behaviour, you have to change configuration 
like:


  

into:


  

  

We do, however, discourage the use of SerializedLayout and recommend JsonLayout 
as a replacement:


  

  

Note that subsequent to the 2.9.0 release, for security reasons, Log4j does not 
process DTD in XML files. If you used DTD for including snippets, you have to 
use XInclude or Composite Configuration instead.

The Log4j 2.9.1 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.9.1

Changes in this version include:

Fixed Bugs

LOG4J2-1988: Prevent ConcurrentModificationException with AsyncLoggerConfig.
LOG4J2-1914: Prevent ConcurrentModificationException with AsyncLoggerConfig.
LOG4J2-2048: Increase default queue size for AsyncAppender from 128 to 1024.
LOG4J2-2035: Fix documentation to clarify disruptor-3.3.4 is now required for 
async loggers (previously the docs referred to disruptor-3.3.3 which was never 
released)
LOG4J2-2030: Inspect all known ClassLoaders to locate the service provider.
LOG4J2-2028: Java 9 StackLocator was not properly skipping the initial stack 
frames. Thanks to Jason Tedor.
LOG4J2-2026: java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature(). Thanks to Leon Finker.
LOG4J2-2029: Marker examples should not use deprecated flow APIs. Thanks to 
Fabrizio Cucci.
LOG4J2-1936: ClassNotFoundException when making all loggers asynchronous under 
OSGi environment. Thanks to Helber Belmiro.
Changes

LOG4J2-2023: Use a class' canonical name instead of name to create its logger 
name.
LOG4J2-2043: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9.)
LOG4J2-2044: Update Apache Commons CSV from 1.4 to 1.5.
LOG4J2-2045: Update javax.mail from 1.5.6 to 1.6.0.
LOG4J2-2046: Update Apache Commons Compress from 1.13 to 1.14.
LOG4J2-2047: Update Cassandra driver from 3.1.0 to 3.1.4.
LOG4J2-2049: Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1.
Apache Log4j 2.9.1 requires a minimum of Java 7 to build and run. Log4j 2.3 was 
the last release that supported Java 6.

Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api 
component, however it does not implement some of the very implementation 
specific classes and methods. The package names and Maven groupId have been 
changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Apache Log4j 2 website:

https://logging.apache.org/log4j/2.x/

Java 9 module names

[Ralph Goers]

I have created https://issues.apache.org/jira/browse/LOG4J2-2056 
 to identify the module 
names we want to use. The effort to resolve this issue will be to add the 
“Automatic-Module-Name” header to the jar manifest for each of the maven 
modules listed. Before doing that I’d like buy-in that these match expectations.

Ralph

log4j-to-slf4j

[Ralph Goers]

In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is 
strikes me that log4j-to-slf4j is binding to the SLF4J API while 
log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using 
SLF4J’s binding mechanism. So it seems to me that instead of having 
log4j-to-slf4j call the SLF4J API we ought to be able to have it call the SLF4J 
bindings and completely bypass SLF4J itself. Some user’s might find this more 
palatable as it would remove one layer between the Log4j API and whatever 
logging implementation the user chose.

Thoughts?

Ralph

Fwd: log4j-to-slf4j

[Ralph Goers]

Well, SLF4J recently changed the binding mechanism with 1.8 in order to comply 
with Java 9. It isn’t likely to do it again any time soon. 

What we would “solve” is that now it is log4j-api -> log4j-to-slf4j -> 
slf4j-api -> logging implementation.  With this change it would be log4j-api -> 
log4j-slf4j-binding -> logging implementation.  I see 2 advantages to this:
1. It would be harder to say that the log4j-api isn’t appropriate to be the 
logging API since the binding to SLF4J implementations would be very light. 
2. The code path to get to an SLF4J implementation would be shorter.

To be honest, item 1 is the one I find more appealing. It reminds me of how 
OS/2’s support for Windows was not what people really wanted vs the way Windows 
NT handled it.

Ralph

> Begin forwarded message:
> 
> From: Remko Popma 
> Subject: Re: log4j-to-slf4j
> Date: September 24, 2017 at 4:27:59 PM MST
> To: dev@logging.apache.org
> Reply-To: dev@logging.apache.org
> 
> That's certainly possible. 
> The trade off is that we'd need to track the SLF4J binding mechanism and 
> update our implementation when this binding mechanism changes. 
> 
> What problem are we trying to solve?
> 
> Remko 
> 
>> On Sep 25, 2017, at 7:16, Ralph Goers  wrote:
>> 
>> In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is 
>> strikes me that log4j-to-slf4j is binding to the SLF4J API while 
>> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using 
>> SLF4J’s binding mechanism. So it seems to me that instead of having 
>> log4j-to-slf4j call the SLF4J API we ought to be able to have it call the 
>> SLF4J bindings and completely bypass SLF4J itself. Some user’s might find 
>> this more palatable as it would remove one layer between the Log4j API and 
>> whatever logging implementation the user chose.
>> 
>> Thoughts?
>> 
>> Ralph
> 

Re: log4j-to-slf4j

[Ralph Goers]

Yes, that is what we would want to do.

BTW - I mentioned it a while ago but is there any chance we can get updated 
performance charts? The charts are for Log4j 2.6 vs Logback 1.1.7.  Logback is 
now at 1.1.11 and 1.2.3. I am not really clear on what is different between 
1.1.x and 1.2.x.

Ralph

> On Sep 24, 2017, at 9:50 PM, Remko Popma  wrote:
> 
> Ok I see now. 
> It would certainly be good to have more ammunition to argue for using the 
> Log4j2 API directly. 
> 
> Comments on StackOverflow
> https://stackoverflow.com/a/41500347/1446916 
> <https://stackoverflow.com/a/41500347/1446916> show some people perceive the 
> log4j-to-slf4j module as a facade for a facade. 
> 
> If we bind directly, perhaps I should update this diagram to have a direct 
> arrow from log4j-to-slf4j to SLF4J implementation?
> 
> 
> Remko 
> 
> (Shameless plug) Every java main() method deserves http://picocli.info 
> <http://picocli.info/>
> 
> On Sep 25, 2017, at 8:57, Ralph Goers  <mailto:ralph.go...@dslextreme.com>> wrote:
> 
>> Well, SLF4J recently changed the binding mechanism with 1.8 in order to 
>> comply with Java 9. It isn’t likely to do it again any time soon. 
>> 
>> What we would “solve” is that now it is log4j-api -> log4j-to-slf4j -> 
>> slf4j-api -> logging implementation.  With this change it would be log4j-api 
>> -> log4j-slf4j-binding -> logging implementation.  I see 2 advantages to 
>> this:
>> 1. It would be harder to say that the log4j-api isn’t appropriate to be the 
>> logging API since the binding to SLF4J implementations would be very light. 
>> 2. The code path to get to an SLF4J implementation would be shorter.
>> 
>> To be honest, item 1 is the one I find more appealing. It reminds me of how 
>> OS/2’s support for Windows was not what people really wanted vs the way 
>> Windows NT handled it.
>> 
>> Ralph
>> 
>>> Begin forwarded message:
>>> 
>>> From: Remko Popma mailto:remko.po...@gmail.com>>
>>> Subject: Re: log4j-to-slf4j
>>> Date: September 24, 2017 at 4:27:59 PM MST
>>> To: dev@logging.apache.org <mailto:dev@logging.apache.org>
>>> Reply-To: dev@logging.apache.org <mailto:dev@logging.apache.org>
>>> 
>>> That's certainly possible. 
>>> The trade off is that we'd need to track the SLF4J binding mechanism and 
>>> update our implementation when this binding mechanism changes. 
>>> 
>>> What problem are we trying to solve?
>>> 
>>> Remko 
>>> 
>>>> On Sep 25, 2017, at 7:16, Ralph Goers >>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> 
>>>> In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j 
>>>> is strikes me that log4j-to-slf4j is binding to the SLF4J API while 
>>>> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation 
>>>> using SLF4J’s binding mechanism. So it seems to me that instead of having 
>>>> log4j-to-slf4j call the SLF4J API we ought to be able to have it call the 
>>>> SLF4J bindings and completely bypass SLF4J itself. Some user’s might find 
>>>> this more palatable as it would remove one layer between the Log4j API and 
>>>> whatever logging implementation the user chose.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Ralph
>>> 
>> 

Re: Log4J 2.9.1 release

[Ralph Goers]

I am fine with adding new features.

Ralph

> On Sep 25, 2017, at 12:28 PM, Mikael Ståldal  wrote:
> 
> So, now we have released 2.9.1, and JDK 9 GA is out. Do we need an 2.9.2, or 
> can we go on and add features for 2.10.0?
> 
> 
> On 2017-09-14 22:27, Ralph Goers wrote:
>> I plan on doing the release build this weekend. Please hold off on merging 
>> new features until after that. I agree with your plan.
>> Ralph
>>> On Sep 14, 2017, at 12:09 PM, Mikael Ståldal  wrote:
>>> 
>>> So do we plan to release 2.9.1 soon? Should we wait with merging new 
>>> features into master?
>>> 
>>> I think it would be good to release 2.9.1 before the Java 9 release on 
>>> September 21th, since we have fixed a few Java 9 related issues.
>>> 
>>> Then we should wait for the Java 9 release, and test Log4j 2.9.1 with Java 
>>> 9 GA to verify that everything works fine. If not, we can do a 2.9.2 to fix 
>>> any issues found.
>>> 
>>> Then we add new features for 2.10.0.
> 
> 

Re: log4j-to-slf4j

[Ralph Goers]

I have been looking at the log4j-to-slf4j binding and am rethinking changing 
it.  There really isn’t much to SLF4J to begin with. Unlike Log4j 2, Logger is 
an interface; the whole implementation is delegated. All SLF4J really does is 
perform the binding between it and the implementation. So what really happens 
with our binding is:
When LogManager.getLogger() is first called log4j-to-slf4j provides the Log4j 
API’s logging implementation. That implementation will call SLF4J’s 
LogFactory.getLogger() which will cause SLF4J to bind to its implementation.
We then create a Logger adapter that implements our Logger API but then wraps 
an SLF4J implementation’s Logger. We don’t actually know what that is because 
we are using the SLF4J Logger interface.
When a Logging call is made the Log4j API will call the Logger Adapter which 
will in turn call the SLF4J logging implementation. 

There is no way to remove the dependency on the slf4j-api jar because it is 
required to use the interfaces. 

Since the slf4j jar is required there doesn’t seem to be much point in 
reimplementing SLF4J’s binding logic. 

But the most important point is that when performing logging the picture really 
is: Log4j API -> log4j-slf4j adapter ->. SLF4J logging implementation.  In 
other words, SLF4J isn’t even in the picture at that point.  I think we should 
make that clear in the documentation.  

I can’t seem to come up with any ideas on how to make it simpler than this.

Ralph

> On Sep 25, 2017, at 6:12 AM, Remko Popma  wrote:
> 
> Understood about the log4j-to-slf4j diagram. 
> 
> About updating the performance page, I haven't been able to spend much time 
> on Log4j2 recently. When I did have time it has gone mostly into bug fixes. 
> 
> If you have done this before you probably know this, but doing these 
> performance investigations easily take weeks of work. Every time I do this I 
> have multiple cycles of test design, set up, execution, gathering results, 
> analyzing the results, discovering a problem and starting again from scratch. 
> :-) 
> 
> With that in mind I hope you understand that competitors like Logback 
> improving their product is not a great motivator for me to undertake this 
> work. 
> 
> I'm not averse to doing this work, I like it, but it should be driven by 
> advances in Log4j2 in my opinion. 
> 
> The Java 9 stackwalker performance would be interesting to document though, 
> so I am sure I will get around to it at some point. 
> 
> Remko 
> 
> 
>> On Sep 25, 2017, at 14:33, Ralph Goers  wrote:
>> 
>> Yes, that is what we would want to do.
>> 
>> BTW - I mentioned it a while ago but is there any chance we can get updated 
>> performance charts? The charts are for Log4j 2.6 vs Logback 1.1.7.  Logback 
>> is now at 1.1.11 and 1.2.3. I am not really clear on what is different 
>> between 1.1.x and 1.2.x.
>> 
>> Ralph
>> 
>>> On Sep 24, 2017, at 9:50 PM, Remko Popma  wrote:
>>> 
>>> Ok I see now. 
>>> It would certainly be good to have more ammunition to argue for using the 
>>> Log4j2 API directly. 
>>> 
>>> Comments on StackOverflow
>>> https://stackoverflow.com/a/41500347/1446916 
>>> <https://stackoverflow.com/a/41500347/1446916> show some people perceive 
>>> the log4j-to-slf4j module as a facade for a facade. 
>>> 
>>> If we bind directly, perhaps I should update this diagram to have a direct 
>>> arrow from log4j-to-slf4j to SLF4J implementation?
>>> 
>>> 
>>> Remko 
>>> 
>>> (Shameless plug) Every java main() method deserves http://picocli.info 
>>> <http://picocli.info/>
>>> 
>>>> On Sep 25, 2017, at 8:57, Ralph Goers >>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> 
>>>> Well, SLF4J recently changed the binding mechanism with 1.8 in order to 
>>>> comply with Java 9. It isn’t likely to do it again any time soon. 
>>>> 
>>>> What we would “solve” is that now it is log4j-api -> log4j-to-slf4j -> 
>>>> slf4j-api -> logging implementation.  With this change it would be 
>>>> log4j-api -> log4j-slf4j-binding -> logging implementation.  I see 2 
>>>> advantages to this:
>>>> 1. It would be harder to say that the log4j-api isn’t appropriate to be 
>>>> the logging API since the binding to SLF4J implementations would be very 
>>>> light. 
>>>> 2. The code path to get to an SLF4J implementation would be shorter.
>>>> 
>>>> To be honest, item 1 is the one I find more appealing. It reminds me of 
>>>> how OS/2’s support for Windows wa

Re: log4j-to-slf4j

[Ralph Goers]

Yes, I started doing that when I realized it didn’t solve anything. We still 
would require the slf4j-api jar to get the interfaces and MDC unless we were to 
use Reflection, which I think would be a very bad idea. So the perception would 
still be there that there is extra overhead.

Ralph

> On Sep 25, 2017, at 6:58 PM, Matt Sicker  wrote:
> 
> Would it be possible to make a log4j-api provider that binds directly to
> logback instead?
> 
> On 25 September 2017 at 18:54, Ralph Goers 
> wrote:
> 
>> I have been looking at the log4j-to-slf4j binding and am rethinking
>> changing it.  There really isn’t much to SLF4J to begin with. Unlike Log4j
>> 2, Logger is an interface; the whole implementation is delegated. All SLF4J
>> really does is perform the binding between it and the implementation. So
>> what really happens with our binding is:
>> When LogManager.getLogger() is first called log4j-to-slf4j provides the
>> Log4j API’s logging implementation. That implementation will call SLF4J’s
>> LogFactory.getLogger() which will cause SLF4J to bind to its implementation.
>> We then create a Logger adapter that implements our Logger API but then
>> wraps an SLF4J implementation’s Logger. We don’t actually know what that is
>> because we are using the SLF4J Logger interface.
>> When a Logging call is made the Log4j API will call the Logger Adapter
>> which will in turn call the SLF4J logging implementation.
>> 
>> There is no way to remove the dependency on the slf4j-api jar because it
>> is required to use the interfaces.
>> 
>> Since the slf4j jar is required there doesn’t seem to be much point in
>> reimplementing SLF4J’s binding logic.
>> 
>> But the most important point is that when performing logging the picture
>> really is: Log4j API -> log4j-slf4j adapter ->. SLF4J logging
>> implementation.  In other words, SLF4J isn’t even in the picture at that
>> point.  I think we should make that clear in the documentation.
>> 
>> I can’t seem to come up with any ideas on how to make it simpler than this.
>> 
>> Ralph
>> 
>>> On Sep 25, 2017, at 6:12 AM, Remko Popma  wrote:
>>> 
>>> Understood about the log4j-to-slf4j diagram.
>>> 
>>> About updating the performance page, I haven't been able to spend much
>> time on Log4j2 recently. When I did have time it has gone mostly into bug
>> fixes.
>>> 
>>> If you have done this before you probably know this, but doing these
>> performance investigations easily take weeks of work. Every time I do this
>> I have multiple cycles of test design, set up, execution, gathering
>> results, analyzing the results, discovering a problem and starting again
>> from scratch. :-)
>>> 
>>> With that in mind I hope you understand that competitors like Logback
>> improving their product is not a great motivator for me to undertake this
>> work.
>>> 
>>> I'm not averse to doing this work, I like it, but it should be driven by
>> advances in Log4j2 in my opinion.
>>> 
>>> The Java 9 stackwalker performance would be interesting to document
>> though, so I am sure I will get around to it at some point.
>>> 
>>> Remko
>>> 
>>> 
>>>> On Sep 25, 2017, at 14:33, Ralph Goers 
>> wrote:
>>>> 
>>>> Yes, that is what we would want to do.
>>>> 
>>>> BTW - I mentioned it a while ago but is there any chance we can get
>> updated performance charts? The charts are for Log4j 2.6 vs Logback 1.1.7.
>> Logback is now at 1.1.11 and 1.2.3. I am not really clear on what is
>> different between 1.1.x and 1.2.x.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Sep 24, 2017, at 9:50 PM, Remko Popma 
>> wrote:
>>>>> 
>>>>> Ok I see now.
>>>>> It would certainly be good to have more ammunition to argue for using
>> the Log4j2 API directly.
>>>>> 
>>>>> Comments on StackOverflow
>>>>> https://stackoverflow.com/a/41500347/1446916 <
>> https://stackoverflow.com/a/41500347/1446916> show some people perceive
>> the log4j-to-slf4j module as a facade for a facade.
>>>>> 
>>>>> If we bind directly, perhaps I should update this diagram to have a
>> direct arrow from log4j-to-slf4j to SLF4J implementation?
>>>>> 
>>>>> 
>>>>> Remko
>>>>> 
>>>>> (Shameless plug) Every java main() method deserves http://picocli.info
>> <http://picocli.info/>
>>>&

Re: Binary compatibility for managers in log4j-core

[Ralph Goers]

Since they are not something end users would normally not be accessing via an 
API, I think my answer would be No, it is not essential that binary 
compatibility be maintained with managers.

Ralph

> On Oct 5, 2017, at 9:53 AM, Mikael Ståldal  wrote:
> 
> We try to keep binary compatibility for appenders and layouts in log4j-core. 
> Does that apply to the managers used by appenders as well?
> 

Re: [Log4j] Next release?

[Ralph Goers]

I have a number of issues I have grabbed. I need to look through them and see 
what I can do.

However, I want to get the Automatic-Module-Name headers in. I’ve done the work 
but am waiting to finalize what the names should be based on Stephen 
Colbourne’s recommendations.

Ralph

> On Oct 12, 2017, at 12:36 PM, Mikael Ståldal  wrote:
> 
> Is there any ongoing work that we want to wait for?
> 
> I would like to do these:
> 
> - https://issues.apache.org/jira/browse/LOG4J2-2062 (waiting for contributor 
> to update his PR, will do it myself soon if he doesn't respond timey)
> 
> - https://issues.apache.org/jira/browse/LOG4J2-2069 (looks quite serious if 
> it is valid)
> 
> Anything else?
> 
> 
> On 2017-10-12 21:12, Mikael Ståldal wrote:
>> Some users are eager to get access to some newly added features:
>> https://github.com/apache/logging-log4j2/pull/110
>> When do we plan to do a 2.10.0 release?
> 

Logging list for emails generated by tools

[Ralph Goers]

What do others think about the idea of creating a separate mailing list for 
emails generated by tools? This list gets a bit noisy from all the extra emails 
and I have a hard time filtering this list because of how some of the emails 
are generated. 

I would also say that we expect every committer to be subscribed to that list.

Ralph

Re: [Log4j] Next release?

[Ralph Goers]

Please do work on Chainsaw. Of course, that isn’t related to a Log4j release 
(or vice versa).

Ralph

> On Oct 12, 2017, at 1:53 PM, Matt Sicker  wrote:
> 
> I almost forgot that I have my properties simplification branch still
> waiting to merge. I should be able to get to that this weekend as I'd also
> like to investigate how hard it is to cut an RC for Chainsaw as well.
> 
> On 12 October 2017 at 15:02, Ralph Goers  wrote:
> 
>> I have a number of issues I have grabbed. I need to look through them and
>> see what I can do.
>> 
>> However, I want to get the Automatic-Module-Name headers in. I’ve done the
>> work but am waiting to finalize what the names should be based on Stephen
>> Colbourne’s recommendations.
>> 
>> Ralph
>> 
>>> On Oct 12, 2017, at 12:36 PM, Mikael Ståldal  wrote:
>>> 
>>> Is there any ongoing work that we want to wait for?
>>> 
>>> I would like to do these:
>>> 
>>> - https://issues.apache.org/jira/browse/LOG4J2-2062 (waiting for
>> contributor to update his PR, will do it myself soon if he doesn't respond
>> timey)
>>> 
>>> - https://issues.apache.org/jira/browse/LOG4J2-2069 (looks quite
>> serious if it is valid)
>>> 
>>> Anything else?
>>> 
>>> 
>>> On 2017-10-12 21:12, Mikael Ståldal wrote:
>>>> Some users are eager to get access to some newly added features:
>>>> https://github.com/apache/logging-log4j2/pull/110
>>>> When do we plan to do a 2.10.0 release?
>>> 
>> 
>> 
>> 
> 
> 
> -- 
> Matt Sicker 

Re: Logging list for emails generated by tools

[Ralph Goers]

It will also make the quarterly board reports more accurate. 
reporter.apache.org provides the number of emails received on the list during 
the quarter. In my view, having the GitHub, Jira, Jenkins, etc emails on the 
dev list skews things as they dominate they number of “real” discussion emails 
that happen on the list, which is what I think is the important part of what 
the board wants to know.

Ralph

> On Oct 12, 2017, at 1:58 PM, Matt Sicker  wrote:
> 
> If it makes email filter rules easier to configure, I'd say go for it. It'd
> be just like the commits@ list though with floods of emails coming in every
> so often that I just have to skip over (e.g., rebasing a long lived branch).
> 
> On 12 October 2017 at 15:45, Gary Gregory  wrote:
> 
>> I do not care either way.
>> 
>> Gary
>> 
>> On Thu, Oct 12, 2017 at 2:34 PM, Ralph Goers 
>> wrote:
>> 
>>> What do others think about the idea of creating a separate mailing list
>>> for emails generated by tools? This list gets a bit noisy from all the
>>> extra emails and I have a hard time filtering this list because of how
>> some
>>> of the emails are generated.
>>> 
>>> I would also say that we expect every committer to be subscribed to that
>>> list.
>>> 
>>> Ralph
>>> 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

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

[Ralph Goers]

One of the Jenkins servers must be misconfigured. 

Ralph

> On Oct 12, 2017, at 3:37 PM, Apache Jenkins Server 
>  wrote:
> 
> See 
> 
> 
> Changes:
> 
> [ggregory] [LOG4J2-1216] Nested pattern layout options broken. Apply slightly
> 
> --
> [...truncated 4.77 MB...]
> Downloading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
> Downloaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
>  (2 KB at 1.7 KB/sec)
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31.jar
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31.jar
>  (24 KB at 14.8 KB/sec)
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31.pom
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31.pom
>  (8 KB at 5.1 KB/sec)
> Downloading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/maven-metadata.xml
> Downloaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/maven-metadata.xml
>  (719 B at 1.0 KB/sec)
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
>  (2 KB at 0.7 KB/sec)
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/maven-metadata.xml
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/maven-metadata.xml
>  (719 B at 0.6 KB/sec)
> Deploying the main artifact log4j-slf4j-impl-2.9.2-SNAPSHOT-sources.jar
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31-sources.jar
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31-sources.jar
>  (24 KB at 19.3 KB/sec)
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
>  (2 KB at 1.0 KB/sec)
> Deploying the main artifact log4j-slf4j-impl-2.9.2-SNAPSHOT-test-sources.jar
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31-test-sources.jar
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/log4j-slf4j-impl-2.9.2-20171012.223430-31-test-sources.jar
>  (21 KB at 17.3 KB/sec)
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-slf4j-impl/2.9.2-SNAPSHOT/maven-metadata.xml
>  (2 KB at 1.1 KB/sec)
> [INFO] Deployment in 
> https://repository.apache.org/content/repositories/snapshots 
> (id=apache.snapshots.https,uniqueVersion=true)
> Deploying the main artifact log4j-taglib-2.9.2-SNAPSHOT.jar
> Downloading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-taglib/2.9.2-SNAPSHOT/maven-metadata.xml
> Downloaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-taglib/2.9.2-SNAPSHOT/maven-metadata.xml
>  (2 KB at 2.1 KB/sec)
> Uploading: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-taglib/2.9.2-SNAPSHOT/log4j-taglib-2.9.2-20171012.223442-31.jar
> Uploaded: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-taglib/2.9.2-SNAPSHOT/log4j-taglib-2.9.2-20171012.223442-31.jar
>  (32 KB at 27.9 KB/sec)
> Uploading: 
> https://repository.apache.org/content/reposito

Re: Planning out what we can do to get Chainsaw back in the game

[Ralph Goers]

I’ve worked with JavaFX. It is pretty easy. I have zero interest in working 
with Swing.

I’d prefer to get away from WebStart. I think that may have been what hung up 
Scott in the first place as he needed a cert. Some of the other technologies 
for binary deployment make sense to me.

To be honest, I’ve never run Chainsaw or Lillith. I am not sure how they 
differ. I am not a big fan of having two projects that do exactly the same 
thing so I’d like some understanding of what they do and how they differ.

Ralph

> On Oct 14, 2017, at 11:01 AM, Matt Sicker  wrote:
> 
> First off, for some reason, there are two repositories:
> 
> https://github.com/apache/chainsaw
> https://github.com/apache/logging-chainsaw
> 
> The second one appears to be up to date. Not sure what to do about the
> first one as it seems to be a relic of when Chainsaw was in SVN.
> 
> Next, bug tracking. The pom says its bugs are tracked in Bugzilla. It was
> tracked as a component of Log4j 1. See this: <
> https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__&component=chainsaw&product=Log4j%20-%20Now%20in%20Jira>.
> I believe it would be useful to switch over to JIRA like we're using for
> the rest of the logging projects. Perhaps we can ask infra for some sort of
> issue transfer if possible.
> 
> Another issue: the Java source version is set to 1.4. That means it doesn't
> even compile using Java 8 due to 1.6 being the oldest source version
> usable. That also means that this project hasn't been updated to use
> generics let alone anything else from the past 13 years (Java 5 was
> released in 2004 back when I was learning how to program in the first
> place!). As such, incrementing the base Java version to 1.6 would be a
> minimum change, and I think if we increased to Java 8 or 9 after a release,
> that would give us a nice opportunity to do some mechanical refactorings
> and such which can sometimes be fun.
> 
> Really, though, the choice of Java version or JVM language in general for a
> modernized version should be determined by whoever is interested in helping
> clean everything up and move forward. In that case, since I feel a bit
> interested here, I'd propose going with either Java 9 or Scala 2.12 (Scala
> provides a neat Swing API wrapper as well). Kotlin could also be a
> contender here, though I haven't used it much at all yet, so I can't really
> make a real recommendation there. There's also the option of migrating from
> Swing to JavaFX if there is interest, though I've never really used JavaFX
> before (but have used Swing).
> 
> Then there is the notion of distribution. Since this is a GUI app, it's not
> generally as simple as just publishing to Maven Central. Naturally, the
> standard Apache release process of publishing sources and binaries to SVN
> works fine, but there are additional options we can consider:
> * Publish a Java webstart thing (would require working with infra to get
> the releases signed; current build instructions tell the user how to create
> their own release using a signing key and such)
> * Publish a macOS .app bundle. This can be published through our normal
> release channel, but there may also be a way to publish to the Mac App
> Store. Also, a Homebrew formula (or cask) for this would be nice, though
> they're normally maintained by external package maintainers just like in
> GNU/Linux distros.
> * Publish a native-ish Windows bundle. I don't see anything in the build
> already, but there are some tools out there to distribute a Java GUI app
> for Windows that could be useful here.
> 
> I have other ideas I'd like to see such as adding support for the JSON
> layout and future binary layouts (e.g., Avro/Thrift/Protobuf/custom binary
> logging format) so there is no reliance on serialized log events or dealing
> with ambiguous log files. I'm pretty sure I could come up with a nice
> backlog here, and we could try to recruit some interested developers
> through helpwanted.a.o and potentially next time we have Google Summer of
> Code or other similar hackathon-like things. In general, I always find the
> viewing and searching of logs to be a pain regardless of fancy tools like
> ELK or Graylog or Splunk, and having a nice local GUI to sort through it
> all could be super useful, and I'd be interested to see this succeed in
> that.
> 
> With all that in mind, who would be interested in helping out on this? I'm
> having difficulty with the current version getting compiled let alone
> getting a release cut, so I'm not even sure how feasible it would be to cut
> a release before going ahead with the next generation. If we start working
> on a major version of Chainsaw without a release for the existing code,
> would that need to take place in the incubator, or can we go forward here?
> 
> -- 
> Matt Sicker 

Re: Planning out what we can do to get Chainsaw back in the game

[Ralph Goers]

+1

Small increments seem prudent until there is some understanding of where we 
want to go.

Ralph

> On Oct 14, 2017, at 11:10 AM, Gary Gregory  wrote:
> 
> Hi Matt,
> 
> It seems to me that to get out of the mess we are currently in, we need to
> publish something official ASAP, even it is just an alpha or beta.
> 
> Toward this goal, we should make the least amount of changes as possible.
> Changing the source to 1.6 seems like a requirement to use modern tooling.
> 
> Then we can take it one step at a time. I like the idea of having a longer
> term road map, which, based on your messages, would be a long one full of
> milestones! :-)
> 
> I'm not sure how much I'll be able to help but you can count on me here and
> there ;-)
> 
> Gary
> 
> On Sat, Oct 14, 2017 at 12:01 PM, Matt Sicker  wrote:
> 
>> First off, for some reason, there are two repositories:
>> 
>> https://github.com/apache/chainsaw
>> https://github.com/apache/logging-chainsaw
>> 
>> The second one appears to be up to date. Not sure what to do about the
>> first one as it seems to be a relic of when Chainsaw was in SVN.
>> 
>> Next, bug tracking. The pom says its bugs are tracked in Bugzilla. It was
>> tracked as a component of Log4j 1. See this: <
>> https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__&component=
>> chainsaw&product=Log4j%20-%20Now%20in%20Jira>.
>> I believe it would be useful to switch over to JIRA like we're using for
>> the rest of the logging projects. Perhaps we can ask infra for some sort of
>> issue transfer if possible.
>> 
>> Another issue: the Java source version is set to 1.4. That means it doesn't
>> even compile using Java 8 due to 1.6 being the oldest source version
>> usable. That also means that this project hasn't been updated to use
>> generics let alone anything else from the past 13 years (Java 5 was
>> released in 2004 back when I was learning how to program in the first
>> place!). As such, incrementing the base Java version to 1.6 would be a
>> minimum change, and I think if we increased to Java 8 or 9 after a release,
>> that would give us a nice opportunity to do some mechanical refactorings
>> and such which can sometimes be fun.
>> 
>> Really, though, the choice of Java version or JVM language in general for a
>> modernized version should be determined by whoever is interested in helping
>> clean everything up and move forward. In that case, since I feel a bit
>> interested here, I'd propose going with either Java 9 or Scala 2.12 (Scala
>> provides a neat Swing API wrapper as well). Kotlin could also be a
>> contender here, though I haven't used it much at all yet, so I can't really
>> make a real recommendation there. There's also the option of migrating from
>> Swing to JavaFX if there is interest, though I've never really used JavaFX
>> before (but have used Swing).
>> 
>> Then there is the notion of distribution. Since this is a GUI app, it's not
>> generally as simple as just publishing to Maven Central. Naturally, the
>> standard Apache release process of publishing sources and binaries to SVN
>> works fine, but there are additional options we can consider:
>> * Publish a Java webstart thing (would require working with infra to get
>> the releases signed; current build instructions tell the user how to create
>> their own release using a signing key and such)
>> * Publish a macOS .app bundle. This can be published through our normal
>> release channel, but there may also be a way to publish to the Mac App
>> Store. Also, a Homebrew formula (or cask) for this would be nice, though
>> they're normally maintained by external package maintainers just like in
>> GNU/Linux distros.
>> * Publish a native-ish Windows bundle. I don't see anything in the build
>> already, but there are some tools out there to distribute a Java GUI app
>> for Windows that could be useful here.
>> 
>> I have other ideas I'd like to see such as adding support for the JSON
>> layout and future binary layouts (e.g., Avro/Thrift/Protobuf/custom binary
>> logging format) so there is no reliance on serialized log events or dealing
>> with ambiguous log files. I'm pretty sure I could come up with a nice
>> backlog here, and we could try to recruit some interested developers
>> through helpwanted.a.o and potentially next time we have Google Summer of
>> Code or other similar hackathon-like things. In general, I always find the
>> viewing and searching of logs to be a pain regardless of fancy tools like
>> ELK or Graylog or Splunk, and having a nice local GUI to sort through it
>> all could be super useful, and I'd be interested to see this succeed in
>> that.
>> 
>> With all that in mind, who would be interested in helping out on this? I'm
>> having difficulty with the current version getting compiled let alone
>> getting a release cut, so I'm not even sure how feasible it would be to cut
>> a release before going ahead with the next generation. If we start working
>> on a major version of Chainsaw without a releas

Java Modules

[Ralph Goers]

I have committed the code for LOG4J2-2056. Log4j-api is a “real” module and has 
a module-info.java while all the rest that can be modularized are automatic 
modules.  Please review and test.

In order to create the module-info.java I had to do a few strange things:
Module-info.java is in the log4j-api-java9 project since log4j-api isn’t 
compiled with Java 9.
Compiling module-info.java requires that the packages being exported exist and 
have at least one class in them, so I had to create the directories and place a 
dummy java class in them. 
The assembly that creates the log4j-api-java9 zip ignores all the dummy files 
and directories and only copies module-info.java and the two utility classes 
into the zip.

I have tested this with a simple program that only uses a module path but I 
would appreciate more extensive tests before it is released.

Ralph

Re: Java Modules

[Ralph Goers]

FWIW, I am still torn on whether log4j-core should have a module name of 
org.apache.logging.log4j.core or org.apache.logging.log4j.impl. If it is the 
second then log4j-api could restrict exporting packages only meant for the 
implementation to that module. That would require some refactoring of the API 
classes but that shouldn’t be too big of a deal. Is the benefit of doing that 
greater than the (hypothetical) benefit of supporting multiple log4j 
implementations at the same time?  Should log4j-to-slf4j also then use the same 
module name since it replaces log4j-core?

Ralph

> On Oct 14, 2017, at 10:40 PM, Ralph Goers  wrote:
> 
> I have committed the code for LOG4J2-2056. Log4j-api is a “real” module and 
> has a module-info.java while all the rest that can be modularized are 
> automatic modules.  Please review and test.
> 
> In order to create the module-info.java I had to do a few strange things:
> Module-info.java is in the log4j-api-java9 project since log4j-api isn’t 
> compiled with Java 9.
> Compiling module-info.java requires that the packages being exported exist 
> and have at least one class in them, so I had to create the directories and 
> place a dummy java class in them. 
> The assembly that creates the log4j-api-java9 zip ignores all the dummy files 
> and directories and only copies module-info.java and the two utility classes 
> into the zip.
> 
> I have tested this with a simple program that only uses a module path but I 
> would appreciate more extensive tests before it is released.
> 
> Ralph

Re: Java Modules

[Ralph Goers]

Yes, you can target specific packages for exposure to specific modules. Yes, we 
would want to move the classes that are “private” to a sub package of util if 
we were to do that.

As for the name, yes you could specify multiple exports but that would mean we 
would need to know the name of every log4j implementation that needs access.  
IMO, that would severely limit log4j-api’s usefulness as a logging API. If we 
did that it would make more sense to say “All implementations must use module 
name org.apache.logging.log4j.impl.” Of course, that limits us to only allowing 
a single implementation at a time - which we don’t really support now anyway 
(although we don’t preclude an enhancement to support it).

It is hard to say that there are any “best practices” for something that was 
only officially released a month ago. At this point in time I think most people 
are simply focusing on what the “proper” name should be for their simple 
modules. It isn’t really all that common to what to have multiple 
implementations of the same thing, but it isn’t all that unusual either. But I 
can see several ways to wire these things:
Use a single module name and specify it in module-info.java. This gives you the 
benefit of also being able to export the private packages to the implementation 
declaratively.
Use the service loader (as we presently do). Use 
provider.getClass().getModule() to locate the module the implementation is in. 
Then call module.exports(packageName, targetModule) on the log4j-api module to 
export the private packages to the implementation.

Personally, I like option 2 the best as it provides the most flexibility while 
still achieving all the desired results and is pretty simple to implement.

Ralph


> On Oct 15, 2017, at 7:37 AM, Remko Popma  wrote:
> 
> You mean we may want to do something like this in the future?
> 
> module org.apache.logging.log4j {
>exports org.apache.logging.log4j;
>exports org.apache.logging.log4j.message;
>exports org.apache.logging.log4j.simple;
>exports org.apache.logging.log4j.spi;
>exports org.apache.logging.log4j.status;
>exports org.apache.logging.log4j.util to
> org.apache.logging.log4j.impl; // only impl can see util
>uses org.apache.logging.log4j.spi.Provider;
> }
> 
> The util package in log4j-api is actually a mixture of "consider private"
> implementation classes and interfaces that are actually public API.
> So some refactoring will be needed as you say.
> 
> Question: does it matter what the log4j-core module name is for the above?
> Either impl or core would work, no?
> If more modules need access, we can expand the list:
> 
> exports org.apache.logging.log4j.util to
> org.apache.logging.log4j.core, some.external.impl, yet.another.impl;
> 
> 
> I notice that the JDK module docs I've seen so far don't suggest the use of
> an identical module name to prevent multiple implementations for a service
> on the module path. The emphasis is more on detecting dependencies and
> encapsulation, rather than preventing misconfiguration.
> 
> I wonder if there are other projects that use identical module names to
> prevent misconfiguration. Is this a "best practice"?
> 
> Remko
> 
> 
> On Sun, Oct 15, 2017 at 4:05 PM, Ralph Goers 
> wrote:
> 
>> FWIW, I am still torn on whether log4j-core should have a module name of
>> org.apache.logging.log4j.core or org.apache.logging.log4j.impl. If it is
>> the second then log4j-api could restrict exporting packages only meant for
>> the implementation to that module. That would require some refactoring of
>> the API classes but that shouldn’t be too big of a deal. Is the benefit of
>> doing that greater than the (hypothetical) benefit of supporting multiple
>> log4j implementations at the same time?  Should log4j-to-slf4j also then
>> use the same module name since it replaces log4j-core?
>> 
>> Ralph
>> 
>>> On Oct 14, 2017, at 10:40 PM, Ralph Goers 
>> wrote:
>>> 
>>> I have committed the code for LOG4J2-2056. Log4j-api is a “real” module
>> and has a module-info.java while all the rest that can be modularized are
>> automatic modules.  Please review and test.
>>> 
>>> In order to create the module-info.java I had to do a few strange things:
>>> Module-info.java is in the log4j-api-java9 project since log4j-api isn’t
>> compiled with Java 9.
>>> Compiling module-info.java requires that the packages being exported
>> exist and have at least one class in them, so I had to create the
>> directories and place a dummy java class in them.
>>> The assembly that creates the log4j-api-java9 zip ignores all the dummy
>> files and directories and only copies module-info.java and the two utility
>> classes into the zip.
>>> 
>>> I have tested this with a simple program that only uses a module path
>> but I would appreciate more extensive tests before it is released.
>>> 
>>> Ralph
>> 
>> 
>> 

Re: Java Modules

[Ralph Goers]

I just remembered that option 2 wouldn’t be sufficient as it would only export 
at run time. The implementation needs access at compile time. I remember there 
are ways to achieve this but I don’t recall what they are at the moment, but I 
seem to recall is still requires calling module.exports.

Ralph

> On Oct 15, 2017, at 10:35 AM, Ralph Goers  wrote:
> 
> Yes, you can target specific packages for exposure to specific modules. Yes, 
> we would want to move the classes that are “private” to a sub package of util 
> if we were to do that.
> 
> As for the name, yes you could specify multiple exports but that would mean 
> we would need to know the name of every log4j implementation that needs 
> access.  IMO, that would severely limit log4j-api’s usefulness as a logging 
> API. If we did that it would make more sense to say “All implementations must 
> use module name org.apache.logging.log4j.impl.” Of course, that limits us to 
> only allowing a single implementation at a time - which we don’t really 
> support now anyway (although we don’t preclude an enhancement to support it).
> 
> It is hard to say that there are any “best practices” for something that was 
> only officially released a month ago. At this point in time I think most 
> people are simply focusing on what the “proper” name should be for their 
> simple modules. It isn’t really all that common to what to have multiple 
> implementations of the same thing, but it isn’t all that unusual either. But 
> I can see several ways to wire these things:
> Use a single module name and specify it in module-info.java. This gives you 
> the benefit of also being able to export the private packages to the 
> implementation declaratively.
> Use the service loader (as we presently do). Use 
> provider.getClass().getModule() to locate the module the implementation is 
> in. Then call module.exports(packageName, targetModule) on the log4j-api 
> module to export the private packages to the implementation.
> 
> Personally, I like option 2 the best as it provides the most flexibility 
> while still achieving all the desired results and is pretty simple to 
> implement.
> 
> Ralph
> 
> 
>> On Oct 15, 2017, at 7:37 AM, Remko Popma  wrote:
>> 
>> You mean we may want to do something like this in the future?
>> 
>> module org.apache.logging.log4j {
>>   exports org.apache.logging.log4j;
>>   exports org.apache.logging.log4j.message;
>>   exports org.apache.logging.log4j.simple;
>>   exports org.apache.logging.log4j.spi;
>>   exports org.apache.logging.log4j.status;
>>   exports org.apache.logging.log4j.util to
>> org.apache.logging.log4j.impl; // only impl can see util
>>   uses org.apache.logging.log4j.spi.Provider;
>> }
>> 
>> The util package in log4j-api is actually a mixture of "consider private"
>> implementation classes and interfaces that are actually public API.
>> So some refactoring will be needed as you say.
>> 
>> Question: does it matter what the log4j-core module name is for the above?
>> Either impl or core would work, no?
>> If more modules need access, we can expand the list:
>> 
>> exports org.apache.logging.log4j.util to
>> org.apache.logging.log4j.core, some.external.impl, yet.another.impl;
>> 
>> 
>> I notice that the JDK module docs I've seen so far don't suggest the use of
>> an identical module name to prevent multiple implementations for a service
>> on the module path. The emphasis is more on detecting dependencies and
>> encapsulation, rather than preventing misconfiguration.
>> 
>> I wonder if there are other projects that use identical module names to
>> prevent misconfiguration. Is this a "best practice"?
>> 
>> Remko
>> 
>> 
>> On Sun, Oct 15, 2017 at 4:05 PM, Ralph Goers 
>> wrote:
>> 
>>> FWIW, I am still torn on whether log4j-core should have a module name of
>>> org.apache.logging.log4j.core or org.apache.logging.log4j.impl. If it is
>>> the second then log4j-api could restrict exporting packages only meant for
>>> the implementation to that module. That would require some refactoring of
>>> the API classes but that shouldn’t be too big of a deal. Is the benefit of
>>> doing that greater than the (hypothetical) benefit of supporting multiple
>>> log4j implementations at the same time?  Should log4j-to-slf4j also then
>>> use the same module name since it replaces log4j-core?
>>> 
>>> Ralph
>>> 
>>>> On Oct 14, 2017, at 10:40 PM, Ralph Goers 
>>> wrote:
>>>> 
>>>> I have committed the code for LOG4J2-2056. Log4j-a