Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

[Ralph Goers]

That’s a good point. It is a programmatic interface so it should return an 
error. But generally we want logging to do something reasonable other than 
fail, so it should either use whatever configuration it finds or use the 
default.

Ralph

> On Apr 11, 2017, at 8:42 PM, Remko Popma <remko.po...@gmail.com> wrote:
> 
> I thought Gary needed a way to detect that the specified location didn't 
> work. But perhaps a warning message is sufficient. 
> 
> Sent from my iPhone
> 
> On Apr 12, 2017, at 10:05, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> 
>> I'd prefer an error message but then have it continue with the current 
>> behavior.
>> 
>> Sent from my iPhone
>> 
>> On Apr 11, 2017, at 5:47 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> 
>>> I can see both sides of the argument. 
>>> 
>>> Rather than changing the semantics of the existing method, what about 
>>> adding a method `Configurator.initializeStrict(String, String)` which fails 
>>> if the specified file doesn't exist? Not sure what the best way to fail is: 
>>> return null or throw exception...
>>> 
>>> Sent from my iPhone
>>> 
>>> On Apr 12, 2017, at 9:13, Gary Gregory <garydgreg...@gmail.com 
>>> <mailto:garydgreg...@gmail.com>> wrote:
>>> 
>>>> Hi All:
>>>> 
>>>> Using 2.8.2, I call 
>>>> org.apache.logging.log4j.core.config.Configurator.initialize(String, 
>>>> String) with a non-exiting file location.
>>>> 
>>>> The method does not return null because it found another log4j2.xml file 
>>>> on my classpath. So I get a LoggerContext but not what I expect...
>>>> 
>>>> That does not sound right to me, it should return null, and then I can 
>>>> look in the status logger to see what went wrong (if I happen to have it 
>>>> set to DEBUG in the log4j2.xml file it did find.)
>>>> 
>>>> Thoughts?
>>>> 
>>>> Gary
>>>> 
>>>> -- 
>>>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | 
>>>> ggreg...@apache.org  <mailto:ggreg...@apache.org>
>>>> Java Persistence with Hibernate, Second Edition 
>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>   
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
>>>> JUnit in Action, Second Edition 
>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>   
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
>>>> Spring Batch in Action 
>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>   
>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> 
>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

[Ralph Goers]

I'd prefer an error message but then have it continue with the current behavior.

Sent from my iPhone

> On Apr 11, 2017, at 5:47 PM, Remko Popma  wrote:
> 
> I can see both sides of the argument. 
> 
> Rather than changing the semantics of the existing method, what about adding 
> a method `Configurator.initializeStrict(String, String)` which fails if the 
> specified file doesn't exist? Not sure what the best way to fail is: return 
> null or throw exception...
> 
> Sent from my iPhone
> 
>> On Apr 12, 2017, at 9:13, Gary Gregory  wrote:
>> 
>> Hi All:
>> 
>> Using 2.8.2, I call 
>> org.apache.logging.log4j.core.config.Configurator.initialize(String, String) 
>> with a non-exiting file location.
>> 
>> The method does not return null because it found another log4j2.xml file on 
>> my classpath. So I get a LoggerContext but not what I expect...
>> 
>> That does not sound right to me, it should return null, and then I can look 
>> in the status logger to see what went wrong (if I happen to have it set to 
>> DEBUG in the log4j2.xml file it did find.)
>> 
>> Thoughts?
>> 
>> Gary
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory

[jira] [Closed] (LOG4J2-239) RollingFileAppender should support logging directly to the file referenced in the filePattern.

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers closed LOG4J2-239.
--

> RollingFileAppender should support logging directly to the file referenced in 
> the filePattern.
> --
>
> Key: LOG4J2-239
> URL: https://issues.apache.org/jira/browse/LOG4J2-239
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.0-beta5
>Reporter: Ralph Goers
>Priority: Minor
>  Labels: Rollover
> Fix For: 2.8
>
>
> RollingFileAppender currently requires a fileName to be configured. The 
> current log will be written to this file and then copied or renamed during 
> rollover. RollingFileAppender should support omitting the fileName, in which 
> case the log output will be written directly to the rollover file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-239) RollingFileAppender should support logging directly to the file referenced in the filePattern.

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-239.

   Resolution: Fixed
Fix Version/s: 2.8

> RollingFileAppender should support logging directly to the file referenced in 
> the filePattern.
> --
>
> Key: LOG4J2-239
> URL: https://issues.apache.org/jira/browse/LOG4J2-239
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.0-beta5
>Reporter: Ralph Goers
>Priority: Minor
>  Labels: Rollover
> Fix For: 2.8
>
>
> RollingFileAppender currently requires a fileName to be configured. The 
> current log will be written to this file and then copied or renamed during 
> rollover. RollingFileAppender should support omitting the fileName, in which 
> case the log output will be written directly to the rollover file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [Scala] Let's get version 11.0 going

[Ralph Goers]

1. Perform the release build. 
2. Build the site.
3. Upload the site to where we can view it.
4. Vote on it.
5. When it passes upload the site to a directory adjacent to the log4j2 site 
directory. Something like log4j-scala/log4j-scala-11.0.

Once you have that we can modify the links in the log4j 2 site to point to it. 
We can also, if we chose, add it to the logging main site.  I am reluctant to 
do that though unless it is part of a log4j 2 “extras” site as the main page 
could get pretty busy.

Ralph

> On Apr 11, 2017, at 12:34 PM, Matt Sicker  wrote:
> 
> I'm starting a new project at work using Scala 2.12, and I'd like to not 
> depend on a snapshot version of the API. The maven site generates fine as far 
> as I can tell from the Jenkins job, but I'm not sure how to appropriately 
> integrate it into the core site.
> 
> I'd like to start a release candidate for log4j-api-scala by the end of the 
> week.
> 
> -- 
> Matt Sicker >

[jira] [Commented] (LOG4J2-1185) Ability to change the fileName dynamically in RollingFileAppender

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964851#comment-15964851
 ] 

Ralph Goers commented on LOG4J2-1185:
-

You have to omit the fileName attribute entirely. The rolling file appender 
will write directly to the target file using its pattern.

> Ability to change the fileName dynamically in RollingFileAppender
> -
>
> Key: LOG4J2-1185
> URL: https://issues.apache.org/jira/browse/LOG4J2-1185
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Affects Versions: 2.1
>Reporter: Dhwaneet Bhatt
>Assignee: Ralph Goers
> Fix For: 2.8
>
>
> Right now RollingFileAppender rolls over the current file with fileName to 
> the one generated by FilePattern. However, logging always continues in the 
> same fileName i.e. fileName once created cannot be changed.
> Property Substitution is only once during initialization, fileName is never 
> changed after RollingFileManager is initialized. The RollingFileManager is 
> very tightly tied up to the fileName attribute.
> Consider that I want to name my log files like this using RollingFileAppender:
> mylog-2015-10-30.log
> mylog-2015-10-29.log
> mylog-2015-10-28.log
> There is no good way to achieve this, because even after rolling over the 
> file, the fileName would still remain the same. If I initialized my fileName 
> using $\{date:-MM-dd\}, date would be substituted only once during 
> initialization and it would never change, always continue to log in the same 
> log file (until I restart my application).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1875) Filtering Exceptions on Log4J 1.X

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers closed LOG4J2-1875.
---

> Filtering Exceptions on Log4J 1.X
> -
>
> Key: LOG4J2-1875
> URL: https://issues.apache.org/jira/browse/LOG4J2-1875
> Project: Log4j 2
>  Issue Type: Request
>Reporter: Mert Saygı
>
> Hello there,
> I want to filter some exceptions with Log4J 1.X then i resolved my problem 
> via adding additional library that named log4j-extras-1.2.17.jar in my 
> project. I cannot change log4j.properties to log4j.xml or i cannot upgrade 
> log4j 1.x to log4j 2.x due to my project framework capacities (SmartfoxServer 
> 2X)
> I can filter exceptions that contains FORCE_UPDATE and REGULAR_UPDATE on 
> their message, but i cannot filter exceptions that contains "Room is full" on 
> their message. I tried many combination. I wonder working principle Log4J 
> StringMatchFilter but first, i have to find a solution my problem quickly. Do 
> you know any filter in this library or way to filter exceptions that contains 
> "Room is full" text? Below is my excepiton and filters.
> Best regards.
> My Exception is:
> 07 Apr 2017 | 11:45:26,499 | ERROR | SFSWorker:Ext:1 | Extensions | | 
> EXCEPTION
> com.smartfoxserver.v2.exceptions.SFSJoinRoomException: Join Error - Room is 
> full: 19, Zone: { Zone: Batak } - Can't add User: ( User Name: 
> d354e22339937548abb52ec442eb4eb4, Id: 3, Priv: 0, Sess: 88.253.243.151:33453 )
> at com.smartfoxserver.v2.api.SFSApi.joinRoom(SFSApi.java:990)
> My Property file is:
> log4j.appender.fileAppender.filter.1=org.apache.log4j.varia.StringMatchFilter
> log4j.appender.fileAppender.filter.1.stringToMatch=FORCE_UPDATE
> log4j.appender.fileAppender.filter.1.acceptOnMatch=false
> log4j.appender.fileAppender.filter.2=org.apache.log4j.varia.StringMatchFilter
> log4j.appender.fileAppender.filter.2.stringToMatch=REGULAR_UPDATE
> log4j.appender.fileAppender.filter.2.acceptOnMatch=false
> log4j.appender.fileAppender.filter.3=org.apache.log4j.varia.StringMatchFilter
> log4j.appender.fileAppender.filter.3.stringToMatch=Room%20is%20full
> log4j.appender.fileAppender.filter.3.acceptOnMatch=false



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-1875) Filtering Exceptions on Log4J 1.X

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-1875.
-
Resolution: Invalid

This Jira is for Log4J 2 issues only.

> Filtering Exceptions on Log4J 1.X
> -
>
> Key: LOG4J2-1875
> URL: https://issues.apache.org/jira/browse/LOG4J2-1875
> Project: Log4j 2
>  Issue Type: Request
>Reporter: Mert Saygı
>
> Hello there,
> I want to filter some exceptions with Log4J 1.X then i resolved my problem 
> via adding additional library that named log4j-extras-1.2.17.jar in my 
> project. I cannot change log4j.properties to log4j.xml or i cannot upgrade 
> log4j 1.x to log4j 2.x due to my project framework capacities (SmartfoxServer 
> 2X)
> I can filter exceptions that contains FORCE_UPDATE and REGULAR_UPDATE on 
> their message, but i cannot filter exceptions that contains "Room is full" on 
> their message. I tried many combination. I wonder working principle Log4J 
> StringMatchFilter but first, i have to find a solution my problem quickly. Do 
> you know any filter in this library or way to filter exceptions that contains 
> "Room is full" text? Below is my excepiton and filters.
> Best regards.
> My Exception is:
> 07 Apr 2017 | 11:45:26,499 | ERROR | SFSWorker:Ext:1 | Extensions | | 
> EXCEPTION
> com.smartfoxserver.v2.exceptions.SFSJoinRoomException: Join Error - Room is 
> full: 19, Zone: { Zone: Batak } - Can't add User: ( User Name: 
> d354e22339937548abb52ec442eb4eb4, Id: 3, Priv: 0, Sess: 88.253.243.151:33453 )
> at com.smartfoxserver.v2.api.SFSApi.joinRoom(SFSApi.java:990)
> My Property file is:
> log4j.appender.fileAppender.filter.1=org.apache.log4j.varia.StringMatchFilter
> log4j.appender.fileAppender.filter.1.stringToMatch=FORCE_UPDATE
> log4j.appender.fileAppender.filter.1.acceptOnMatch=false
> log4j.appender.fileAppender.filter.2=org.apache.log4j.varia.StringMatchFilter
> log4j.appender.fileAppender.filter.2.stringToMatch=REGULAR_UPDATE
> log4j.appender.fileAppender.filter.2.acceptOnMatch=false
> log4j.appender.fileAppender.filter.3=org.apache.log4j.varia.StringMatchFilter
> log4j.appender.fileAppender.filter.3.stringToMatch=Room%20is%20full
> log4j.appender.fileAppender.filter.3.acceptOnMatch=false



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [14/14] logging-log4j2 git commit: Update BOM

[Ralph Goers]

Yes, that is the repo.  Initially, all it needs is a parent pom that references 
the module you created. We can move other stuff in later. It will need a web 
site of some kind but we can also worry about that later.

Ralph

> On Apr 10, 2017, at 9:11 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> Is it this repo? git://git.apache.org/logging-log4j-tools.git 
> <http://git.apache.org/logging-log4j-tools.git>
> 
> It is currently empty (except two text files). I don't feel confident to do 
> the initial setup of the repository.
> 
> On Mon, Apr 10, 2017 at 5:48 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> I created a new git repo for log4j2-tools.  We should not create any more 
> modules if we can avoid it.
> 
> Ralph
> 
>> On Apr 10, 2017, at 7:28 AM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> 
>> I guess this is a matter of preference but we already have a lot of modules.
>> Having one for all standalone applications makes it easier for our users to 
>> find things.
>> 
>> On Mon, Apr 10, 2017 at 11:24 PM, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> Wouldn't it be better to have one for server and another for the other tools?
>> 
>> On Mon, Apr 10, 2017 at 4:23 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> I thought we were going to name this module log4j-tools instead of 
>> log4j-server, so it can host all our standalone apps?
>> 
>> On Mon, Apr 10, 2017 at 11:11 PM, <mi...@apache.org 
>> <mailto:mi...@apache.org>> wrote:
>> Update BOM
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo>
>> Commit: 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6>
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6>
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6>
>> 
>> Branch: refs/heads/master
>> Commit: fea17ad6bdc47825ec5b58b9df9e031936182d79
>> Parents: 1051081
>> Author: Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>>
>> Authored: Mon Apr 10 16:11:24 2017 +0200
>> Committer: Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>>
>> Committed: Mon Apr 10 16:11:24 2017 +0200
>> 
>> --
>>  log4j-bom/pom.xml | 6 ++
>>  1 file changed, 6 insertions(+)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml
>>  
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml>
>> --
>> diff --git a/log4j-bom/pom.xml b/log4j-bom/pom.xml
>> index 920f6a0..382f16e 100644
>> --- a/log4j-bom/pom.xml
>> +++ b/log4j-bom/pom.xml
>> @@ -96,6 +96,12 @@
>>  log4j-iostreams
>>  ${project.version}
>>
>> +  
>> +  
>> +org.apache.logging.log4j
>> +log4j-server
>> +${project.version}
>> +  
>>
>>
>>  org.apache.logging.log4j
>> 
>> 
>> 
>> 
>> 
>> -- 
>>  
>> 
>> Mikael Ståldal
>> Senior software developer 
>> 
>> Magine TV
>> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
>> <http://www.magine.com/>
>> 
>> Privileged and/or Confidential Information may be contained in this message. 
>> If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not 
>> copy or deliver this message to anyone. In such case, 
>> you should destroy this message and kindly notify the sender by reply email. 
>>   
>> 
> 
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> <http://www.magine.com/>
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Re: [14/14] logging-log4j2 git commit: Update BOM

[Ralph Goers]

Maybe, but if it is large enough I would just migrate it from svn to its own 
git repo.

Ralph

> On Apr 10, 2017, at 9:05 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> Is this where a Chainsaw refresh would live?
> 
> Gary
> 
> On Apr 10, 2017 9:01 AM, "Ralph Goers" <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> I’m fine with that. I just don’t want more modules in the main project.
> 
> Ralph
> 
>> On Apr 10, 2017, at 8:56 AM, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> 
>> The whole point of this is to get the server components out of log4j-core, 
>> so we need to create a new module. Maybe this new module can be moved to 
>> log4j2-tools repo.
>> 
>> On Mon, Apr 10, 2017 at 5:48 PM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> I created a new git repo for log4j2-tools.  We should not create any more 
>> modules if we can avoid it.
>> 
>> Ralph
>> 
>>> On Apr 10, 2017, at 7:28 AM, Remko Popma <remko.po...@gmail.com 
>>> <mailto:remko.po...@gmail.com>> wrote:
>>> 
>>> I guess this is a matter of preference but we already have a lot of modules.
>>> Having one for all standalone applications makes it easier for our users to 
>>> find things.
>>> 
>>> On Mon, Apr 10, 2017 at 11:24 PM, Mikael Ståldal <mikael.stal...@magine.com 
>>> <mailto:mikael.stal...@magine.com>> wrote:
>>> Wouldn't it be better to have one for server and another for the other 
>>> tools?
>>> 
>>> On Mon, Apr 10, 2017 at 4:23 PM, Remko Popma <remko.po...@gmail.com 
>>> <mailto:remko.po...@gmail.com>> wrote:
>>> I thought we were going to name this module log4j-tools instead of 
>>> log4j-server, so it can host all our standalone apps?
>>> 
>>> On Mon, Apr 10, 2017 at 11:11 PM, <mi...@apache.org 
>>> <mailto:mi...@apache.org>> wrote:
>>> Update BOM
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo 
>>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo>
>>> Commit: 
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6 
>>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6>
>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6 
>>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6>
>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6 
>>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6>
>>> 
>>> Branch: refs/heads/master
>>> Commit: fea17ad6bdc47825ec5b58b9df9e031936182d79
>>> Parents: 1051081
>>> Author: Mikael Ståldal <mikael.stal...@magine.com 
>>> <mailto:mikael.stal...@magine.com>>
>>> Authored: Mon Apr 10 16:11:24 2017 +0200
>>> Committer: Mikael Ståldal <mikael.stal...@magine.com 
>>> <mailto:mikael.stal...@magine.com>>
>>> Committed: Mon Apr 10 16:11:24 2017 +0200
>>> 
>>> --
>>>  log4j-bom/pom.xml | 6 ++
>>>  1 file changed, 6 insertions(+)
>>> --
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml
>>>  
>>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml>
>>> --
>>> diff --git a/log4j-bom/pom.xml b/log4j-bom/pom.xml
>>> index 920f6a0..382f16e 100644
>>> --- a/log4j-bom/pom.xml
>>> +++ b/log4j-bom/pom.xml
>>> @@ -96,6 +96,12 @@
>>>  log4j-iostreams
>>>  ${project.version}
>>>
>>> +  
>>> +  
>>> +org.apache.logging.log4j
>>> +log4j-server
>>> +${project.version}
>>> +  
>>>
>>>
>>>  org.apache.logging.log4j
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>>  
>>> 
>>> Mikael Ståldal
>>> Senior software developer 
>>> 
>>> Magine TV
>>> mikael.stal...@magine.com <mailt

Re: [14/14] logging-log4j2 git commit: Update BOM

[Ralph Goers]

I’m fine with that. I just don’t want more modules in the main project.

Ralph

> On Apr 10, 2017, at 8:56 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> The whole point of this is to get the server components out of log4j-core, so 
> we need to create a new module. Maybe this new module can be moved to 
> log4j2-tools repo.
> 
> On Mon, Apr 10, 2017 at 5:48 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> I created a new git repo for log4j2-tools.  We should not create any more 
> modules if we can avoid it.
> 
> Ralph
> 
>> On Apr 10, 2017, at 7:28 AM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> 
>> I guess this is a matter of preference but we already have a lot of modules.
>> Having one for all standalone applications makes it easier for our users to 
>> find things.
>> 
>> On Mon, Apr 10, 2017 at 11:24 PM, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> Wouldn't it be better to have one for server and another for the other tools?
>> 
>> On Mon, Apr 10, 2017 at 4:23 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> I thought we were going to name this module log4j-tools instead of 
>> log4j-server, so it can host all our standalone apps?
>> 
>> On Mon, Apr 10, 2017 at 11:11 PM, <mi...@apache.org 
>> <mailto:mi...@apache.org>> wrote:
>> Update BOM
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo>
>> Commit: 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6>
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6>
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6 
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6>
>> 
>> Branch: refs/heads/master
>> Commit: fea17ad6bdc47825ec5b58b9df9e031936182d79
>> Parents: 1051081
>> Author: Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>>
>> Authored: Mon Apr 10 16:11:24 2017 +0200
>> Committer: Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>>
>> Committed: Mon Apr 10 16:11:24 2017 +0200
>> 
>> --
>>  log4j-bom/pom.xml | 6 ++
>>  1 file changed, 6 insertions(+)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml
>>  
>> <http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml>
>> --
>> diff --git a/log4j-bom/pom.xml b/log4j-bom/pom.xml
>> index 920f6a0..382f16e 100644
>> --- a/log4j-bom/pom.xml
>> +++ b/log4j-bom/pom.xml
>> @@ -96,6 +96,12 @@
>>  log4j-iostreams
>>  ${project.version}
>>
>> +  
>> +  
>> +org.apache.logging.log4j
>> +log4j-server
>> +${project.version}
>> +  
>>
>>
>>  org.apache.logging.log4j
>> 
>> 
>> 
>> 
>> 
>> -- 
>>  
>> 
>> Mikael Ståldal
>> Senior software developer 
>> 
>> Magine TV
>> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
>> <http://www.magine.com/>
>> 
>> Privileged and/or Confidential Information may be contained in this message. 
>> If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not 
>> copy or deliver this message to anyone. In such case, 
>> you should destroy this message and kindly notify the sender by reply email. 
>>   
>> 
> 
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> <http://www.magine.com/>
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Re: [14/14] logging-log4j2 git commit: Update BOM

[Ralph Goers]

I created a new git repo for log4j2-tools.  We should not create any more 
modules if we can avoid it.

Ralph

> On Apr 10, 2017, at 7:28 AM, Remko Popma  wrote:
> 
> I guess this is a matter of preference but we already have a lot of modules.
> Having one for all standalone applications makes it easier for our users to 
> find things.
> 
> On Mon, Apr 10, 2017 at 11:24 PM, Mikael Ståldal  > wrote:
> Wouldn't it be better to have one for server and another for the other tools?
> 
> On Mon, Apr 10, 2017 at 4:23 PM, Remko Popma  > wrote:
> I thought we were going to name this module log4j-tools instead of 
> log4j-server, so it can host all our standalone apps?
> 
> On Mon, Apr 10, 2017 at 11:11 PM,  > wrote:
> Update BOM
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo 
> 
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/fea17ad6 
> 
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/fea17ad6 
> 
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/fea17ad6 
> 
> 
> Branch: refs/heads/master
> Commit: fea17ad6bdc47825ec5b58b9df9e031936182d79
> Parents: 1051081
> Author: Mikael Ståldal  >
> Authored: Mon Apr 10 16:11:24 2017 +0200
> Committer: Mikael Ståldal  >
> Committed: Mon Apr 10 16:11:24 2017 +0200
> 
> --
>  log4j-bom/pom.xml | 6 ++
>  1 file changed, 6 insertions(+)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/fea17ad6/log4j-bom/pom.xml
>  
> 
> --
> diff --git a/log4j-bom/pom.xml b/log4j-bom/pom.xml
> index 920f6a0..382f16e 100644
> --- a/log4j-bom/pom.xml
> +++ b/log4j-bom/pom.xml
> @@ -96,6 +96,12 @@
>  log4j-iostreams
>  ${project.version}
>
> +  
> +  
> +org.apache.logging.log4j
> +log4j-server
> +${project.version}
> +  
>
>
>  org.apache.logging.log4j
> 
> 
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com 
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> 
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  
> 

Log4j logo

[Ralph Goers]

BTW - When I have been doing releases I believe I have always chosen ones where 
the “cup” and “steam” varied in color but everything else stays the same. For 
some reason I just don’t like the look of the others. I would prefer if we 
could continue doing that as it give consistency to the logo.  At some point we 
also may start reusing logo images, although it isn’t that hard to create new 
ones.

Ralph


> On Apr 9, 2017, at 12:02 PM, Matt Sicker <boa...@gmail.com> wrote:
> 
> I used the 2.8.2 logo in the site commit to svn, but the site zip 
> distribution has the 2.8.1 logo since that was the release artifact 
> technically. If you don't see the new logo on the site, it's probably a 
> caching issue.
> 
> On 9 April 2017 at 13:52, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Thanks, but you used the 2.8.1 logo instead of 2.8.2.
> 
> Oh darn, I just noticed the web site wasn’t updated either.  I guess I will 
> have to fix that.
> 
> Ralph
> 
>> On Apr 8, 2017, at 4:36 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> 
>> Blogged: https://blogs.apache.org/logging/entry/log4j-2-8-2-released 
>> <https://blogs.apache.org/logging/entry/log4j-2-8-2-released>
>> 
> 
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Re: [ANN] Log4j 2.8.2 released

[Ralph Goers]

Yup - it updated after I cleared my cache.

Ralph

> On Apr 9, 2017, at 12:02 PM, Matt Sicker <boa...@gmail.com> wrote:
> 
> I used the 2.8.2 logo in the site commit to svn, but the site zip 
> distribution has the 2.8.1 logo since that was the release artifact 
> technically. If you don't see the new logo on the site, it's probably a 
> caching issue.
> 
> On 9 April 2017 at 13:52, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Thanks, but you used the 2.8.1 logo instead of 2.8.2.
> 
> Oh darn, I just noticed the web site wasn’t updated either.  I guess I will 
> have to fix that.
> 
> Ralph
> 
>> On Apr 8, 2017, at 4:36 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> 
>> Blogged: https://blogs.apache.org/logging/entry/log4j-2-8-2-released 
>> <https://blogs.apache.org/logging/entry/log4j-2-8-2-released>
>> 
> 
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Re: [ANN] Log4j 2.8.2 released

[Ralph Goers]

Thanks, but you used the 2.8.1 logo instead of 2.8.2.

Oh darn, I just noticed the web site wasn’t updated either.  I guess I will 
have to fix that.

Ralph

> On Apr 8, 2017, at 4:36 PM, Remko Popma  wrote:
> 
> Blogged: https://blogs.apache.org/logging/entry/log4j-2-8-2-released 
> 
> 

Re: Yet another logging facade

[Ralph Goers]

See 
http://stackoverflow.com/questions/41633278/can-we-use-all-features-of-log4j2-if-we-use-it-along-with-slf4j-api/41635246#41635246
 
<http://stackoverflow.com/questions/41633278/can-we-use-all-features-of-log4j2-if-we-use-it-along-with-slf4j-api/41635246#41635246>.
 Note that item 10 on this list was recently fixed.

Ralph


> On Apr 7, 2017, at 12:04 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> I just took a look at the list. I don’t see the response that points to 
> bugzilla.
> 
> In your comment you mentioned that Log4j provides an api but you didn’t list 
> the reasons why it is better. Remko posted a stack overflow post that has 10 
> reasons why it is better.  But more importantly, users have been asking for 
> enhancements to the SLF4J API for quite a while. Eventually the API is going 
> to have to be enhanced. How is OSGi going to accommodate for that?
> 
> Ralph
> 
>> On Apr 7, 2017, at 9:40 AM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> I got a response on the mailing list. There's a public bugzilla we can 
>> comment on apparently which is linked in the PDF.
>> 
>> On 6 April 2017 at 20:02, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> I'm not sure where they develop the standards, but there's an osgi-dev 
>> mailing list (where I found this posted today): 
>> https://www.osgi.org/community/mail-lists/ 
>> <https://www.osgi.org/community/mail-lists/>
>> 
>> I don't see Apache on this list despite being the foundation behind most of 
>> the open source OSGi projects out there: 
>> https://www.osgi.org/about-us/members/ 
>> <https://www.osgi.org/about-us/members/>
>> 
>> However, there are many companies on that list who directly contribute to 
>> said Apache projects.
>> 
>> I can't find any info on their site about how to offer feedback. This is 
>> just as (if not more) convoluted than the JCP.
>> 
>> On 6 April 2017 at 19:41, Gary Gregory <garydgreg...@gmail.com 
>> <mailto:garydgreg...@gmail.com>> wrote:
>> A quick review of the document appears to have SLF4J as a requirement. Shame 
>> about that. 
>> 
>> Gary
>> 
>> On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> Where does one comment on these?
>> 
>> The problem is that they mention Java 8 support, but SLF4J doesn’t take 
>> advantage of any Java 8 features yet. No support for Lamda’s.  From what I 
>> am seeing the next release will support running in Java 9 and will leverage 
>> StackWalker and support Java modules but Ceki hasn’t mentioned if he is 
>> going to add to the API to support things users have been asking for.
>> 
>> I’d hate to see them base their standard on what was then the current 
>> release of SLF4J and then for it to be enhanced and they are stuck with a 
>> limited API.
>> 
>> I wonder how much input, if any, Ceki had in this.  
>> 
>> As a side note, he also changed the binding mechanism and I am not sure if 
>> it is backward compatible, soI have a feeling log4j-slf4j-impl will need 
>> changes to support that version. 
>> 
>> Ralph
>> 
>> 
>>> On Apr 6, 2017, at 4:00 PM, Remko Popma <remko.po...@gmail.com 
>>> <mailto:remko.po...@gmail.com>> wrote:
>>> 
>>> Good find. I noticed that the document points to Apache Sling and says 
>>> "uses the most common parts today used for logging: SLF4J for clients and 
>>> logback for processing."  Seems like Sling decided that in 2013 and never 
>>> looked back. Which is fine, but I believe Log4j2 has changed the landscape 
>>> the last 4 years. 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Apr 7, 2017, at 6:08, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>>> OSGi is looking at updating their logging API:
>>>> 
>>>> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
>>>>  
>>>> <https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf>
>>>> 
>>>> We might want to provide feedback.
>>>> 
>>>> -- 
>>>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | 
>> ggreg...@apache

Re: Yet another logging facade

[Ralph Goers]

I just took a look at the list. I don’t see the response that points to 
bugzilla.

In your comment you mentioned that Log4j provides an api but you didn’t list 
the reasons why it is better. Remko posted a stack overflow post that has 10 
reasons why it is better.  But more importantly, users have been asking for 
enhancements to the SLF4J API for quite a while. Eventually the API is going to 
have to be enhanced. How is OSGi going to accommodate for that?

Ralph

> On Apr 7, 2017, at 9:40 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> I got a response on the mailing list. There's a public bugzilla we can 
> comment on apparently which is linked in the PDF.
> 
> On 6 April 2017 at 20:02, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> I'm not sure where they develop the standards, but there's an osgi-dev 
> mailing list (where I found this posted today): 
> https://www.osgi.org/community/mail-lists/ 
> <https://www.osgi.org/community/mail-lists/>
> 
> I don't see Apache on this list despite being the foundation behind most of 
> the open source OSGi projects out there: 
> https://www.osgi.org/about-us/members/ 
> <https://www.osgi.org/about-us/members/>
> 
> However, there are many companies on that list who directly contribute to 
> said Apache projects.
> 
> I can't find any info on their site about how to offer feedback. This is just 
> as (if not more) convoluted than the JCP.
> 
> On 6 April 2017 at 19:41, Gary Gregory <garydgreg...@gmail.com 
> <mailto:garydgreg...@gmail.com>> wrote:
> A quick review of the document appears to have SLF4J as a requirement. Shame 
> about that. 
> 
> Gary
> 
> On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Where does one comment on these?
> 
> The problem is that they mention Java 8 support, but SLF4J doesn’t take 
> advantage of any Java 8 features yet. No support for Lamda’s.  From what I am 
> seeing the next release will support running in Java 9 and will leverage 
> StackWalker and support Java modules but Ceki hasn’t mentioned if he is going 
> to add to the API to support things users have been asking for.
> 
> I’d hate to see them base their standard on what was then the current release 
> of SLF4J and then for it to be enhanced and they are stuck with a limited API.
> 
> I wonder how much input, if any, Ceki had in this.  
> 
> As a side note, he also changed the binding mechanism and I am not sure if it 
> is backward compatible, soI have a feeling log4j-slf4j-impl will need changes 
> to support that version. 
> 
> Ralph
> 
> 
>> On Apr 6, 2017, at 4:00 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> 
>> Good find. I noticed that the document points to Apache Sling and says "uses 
>> the most common parts today used for logging: SLF4J for clients and logback 
>> for processing."  Seems like Sling decided that in 2013 and never looked 
>> back. Which is fine, but I believe Log4j2 has changed the landscape the last 
>> 4 years. 
>> 
>> Sent from my iPhone
>> 
>> On Apr 7, 2017, at 6:08, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>>> OSGi is looking at updating their logging API:
>>> 
>>> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
>>>  
>>> <https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf>
>>> 
>>> We might want to provide feedback.
>>> 
>>> -- 
>>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | 
> ggreg...@apache.org  <mailto:ggreg...@apache.org>
> Java Persistence with Hibernate, Second Edition 
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>   
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
> JUnit in Action, Second Edition 
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
>   
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
> Spring Batch in Action 
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>   
> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> 
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Re: [qos.ch-announce] Release of SLF4J version 1.8.0-alpha0

[Ralph Goers]

We will have to modify log4j-slf4j-impl to support the new binding mechanism. I 
know it uses service loader but I haven’t looked at the details. I looked at 
service loader when I created the binding between our api and core but decided 
not to use it because I wanted to also include the logic to match API versions. 
So what we have is something similar to service loader but it doesn’t use it.

Ralph

> On Apr 7, 2017, at 8:07 AM, Matt Sicker  wrote:
> 
> So how shall we go about handling this?
> 
> -- Forwarded message --
> From: QOS.ch annoucements >
> Date: 7 April 2017 at 05:46
> Subject: [qos.ch-announce] Release of SLF4J version 1.8.0-alpha0
> To: annou...@qos.ch 
> 
> 
> 
> Java 9 modularization
> =
> 
> I  am  pleased  to  announce SLF4J  1.8.0-alpha0,  a  modularized
> version of  slf4j compatible  with Java 9  and in  particular its
> Java Platform Module System (JSR 376), a.k.a project Jigsaw.
> 
> Although there are  no client facing API  changes in 1.8.0-alpha0
> release, the static binding mechanism has been abandoned in favor
> of java.util.ServiceLoader introduced in  Java 6. It follows that
> slf4j-api  now requires  Java 6.  Just as  importantly, slf4j-api
> version 1.8.x  will no  longer search for  the StaticLoggerBinder
> class.
> 
> Instead of  "bindings" now slf4j-api looks  for "providers" which
> ship   withslf4j-nop-1.8.x.jar,   slf4j-simple-1.8.x.jar   or
> slf4j-jdk14-1.8.x.jar.
> 
> Given that in some environments, it is not possible to modify the
> version  of  slf4j-api,  slf4j  1.8.x  "providers"  also  act  as
> 1.7.x/1.6.x "bindings".
> 
> For   example,  having   slf4j-api-1.8.x.jar  and
> slf4j-simple-1.7.x.jar on  the class path will  NOT work, whereas
> having  slf4j-api-1.7.x.jar  and  slf4j-simple-1.8.x.jar  on  the
> class path will work fine.
> 
> In other words:
> 
> slf4j-api-1.8.x.jar + slf4j-simple-1.7.x.jar ==> "No SLF4J
> providers found" warning
> 
> whereas:
> 
> slf4j-api-1.7.x.jar + slf4j-simple-1.8.x.jar ==> OK
> 
> 
> Download
> 
> 
> The relevant artifacts can be obtained via the Maven central
> repository.
> 
> OSGi changes
> 
> 
> While  we expect  the changes  introduced in  SLF4J 1.8.x  to be
> rather   transparent   to   users,   given   JPMS   restrictions,
> implementations had to be moved from the org.slf4.impl package to
> packages  specific  to  each  provider.  Consequently,  the  OSGi
> declarations in MANIFEST.MF files had  to be modified.  Our tests
> indicate  that   SLF4J  version  1.8.x  should   work  fine  with
> OSGi. However, more in depth testing  is in order. We are looking
> for volunteers for such tests.
> 
> 
> The slf4j-log4j12 module
> 
> 
> Due to technical reasons,  slf4j-log4j12 could not be modularized
> in  this alpha0  release. However,  we expect  the problem  to be
> solved in future 1.8.x releases.
> 
> 
> Announcement mailing list
> =
> 
> You can receive SLF4J related announcements by subscribing to the
> SLF4J announce mailing list. To subscribe to QOS.ch announce list,
> please visit the following URL.
> 
>http://www.qos.ch/mailman/listinfo/announce 
> 
> 
> You may also receive announcements via twitter:
> 
>https://twitter.com/qos_ch 
> 
> Enjoy,
> 
> -- 
> Ceki Gülcü
> ___
> announce mailing list
> annou...@qos.ch 
> http://mailman.qos.ch/mailman/listinfo/announce 
> 
> 
> 
> -- 
> Matt Sicker >

Re: Yet another logging facade

[Ralph Goers]

Where does one comment on these?

The problem is that they mention Java 8 support, but SLF4J doesn’t take 
advantage of any Java 8 features yet. No support for Lamda’s.  From what I am 
seeing the next release will support running in Java 9 and will leverage 
StackWalker and support Java modules but Ceki hasn’t mentioned if he is going 
to add to the API to support things users have been asking for.

I’d hate to see them base their standard on what was then the current release 
of SLF4J and then for it to be enhanced and they are stuck with a limited API.

I wonder how much input, if any, Ceki had in this.  

As a side note, he also changed the binding mechanism and I am not sure if it 
is backward compatible, soI have a feeling log4j-slf4j-impl will need changes 
to support that version. 

Ralph


> On Apr 6, 2017, at 4:00 PM, Remko Popma  wrote:
> 
> Good find. I noticed that the document points to Apache Sling and says "uses 
> the most common parts today used for logging: SLF4J for clients and logback 
> for processing."  Seems like Sling decided that in 2013 and never looked 
> back. Which is fine, but I believe Log4j2 has changed the landscape the last 
> 4 years. 
> 
> Sent from my iPhone
> 
> On Apr 7, 2017, at 6:08, Matt Sicker  > wrote:
> 
>> OSGi is looking at updating their logging API:
>> 
>> https://github.com/osgi/design/blob/master/rfcs/rfc0219/rfc-0219-LogService-Update.pdf
>>  
>> 
>> 
>> We might want to provide feedback.
>> 
>> -- 
>> Matt Sicker >

Re: Syslog

[Ralph Goers]

Let me rephrase. 
http://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender 
<http://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender> 
describes exactly what it does - write either using the BSD Syslog format or 
the RFC 5424 format. A user who wants to write to syslog is most likely going 
to look at that appender and use it. The SyslogAppender uses the two layouts to 
accomplish this. The fact that the two layouts are also available for people to 
use is incidental.  

Are you proposing that somehow the two layouts should not be available for 
user’s to use?

Ralph

> On Apr 5, 2017, at 7:01 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> Why?
> 
> Ralph
> 
>> On Apr 5, 2017, at 6:56 AM, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> 
>> I see. But couldn't it be a bit confusing for users to have both?
>> 
>> On Wed, Apr 5, 2017 at 3:54 PM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> I’m not sure I understand the question. Have you looked at the code?  The 
>> syslog appender is nothing more than the SocketAppender hardwired to use one 
>> of those two layouts. However, there is nothing preventing someone from 
>> using those Layouts with a different appender.
>> 
>> Ralph
>> 
>> 
>> 
>>> On Apr 5, 2017, at 3:57 AM, Mikael Ståldal <mikael.stal...@magine.com 
>>> <mailto:mikael.stal...@magine.com>> wrote:
>>> 
>>> Why do we have both SyslogAppender and SyslogLayout/RFC5424Layout?
>>> 
>>> -- 
>>>  
>>> 
>>> Mikael Ståldal
>>> Senior software developer 
>>> 
>>> Magine TV
>>> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
>>> <http://www.magine.com/>
>>> 
>>> Privileged and/or Confidential Information may be contained in this 
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may not 
>>> copy or deliver this message to anyone. In such case, 
>>> you should destroy this message and kindly notify the sender by reply 
>>> email.   
>> 
>> 
>> 
>> 
>> -- 
>>  
>> 
>> Mikael Ståldal
>> Senior software developer 
>> 
>> Magine TV
>> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
>> <http://www.magine.com/>
>> 
>> Privileged and/or Confidential Information may be contained in this message. 
>> If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not 
>> copy or deliver this message to anyone. In such case, 
>> you should destroy this message and kindly notify the sender by reply email. 
>>   
> 

Re: Syslog

[Ralph Goers]

Why?

Ralph

> On Apr 5, 2017, at 6:56 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> I see. But couldn't it be a bit confusing for users to have both?
> 
> On Wed, Apr 5, 2017 at 3:54 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> I’m not sure I understand the question. Have you looked at the code?  The 
> syslog appender is nothing more than the SocketAppender hardwired to use one 
> of those two layouts. However, there is nothing preventing someone from using 
> those Layouts with a different appender.
> 
> Ralph
> 
> 
> 
>> On Apr 5, 2017, at 3:57 AM, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> 
>> Why do we have both SyslogAppender and SyslogLayout/RFC5424Layout?
>> 
>> -- 
>>  
>> 
>> Mikael Ståldal
>> Senior software developer 
>> 
>> Magine TV
>> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
>> <http://www.magine.com/>
>> 
>> Privileged and/or Confidential Information may be contained in this message. 
>> If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not 
>> copy or deliver this message to anyone. In such case, 
>> you should destroy this message and kindly notify the sender by reply email. 
>>   
> 
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> <http://www.magine.com/>
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Re: Syslog

[Ralph Goers]

I’m not sure I understand the question. Have you looked at the code?  The 
syslog appender is nothing more than the SocketAppender hardwired to use one of 
those two layouts. However, there is nothing preventing someone from using 
those Layouts with a different appender.

Ralph


> On Apr 5, 2017, at 3:57 AM, Mikael Ståldal  wrote:
> 
> Why do we have both SyslogAppender and SyslogLayout/RFC5424Layout?
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com 
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> 
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Re: MessageLayout

[Ralph Goers]

Again, if you use an async logger you will lose whatever is in the memory 
buffer when the server stops or crashes. If you log directly to Flume you are 
guaranteed that the audit event is written when the logging call returns and 
your application can count on that.

The only thing you really need to be aware of is that in an HA configuration it 
is possible to end up with multiple instances of the event in the final 
repository so you need to make sure your events include a unique key that can 
be used to remove duplicates.

Ralph

> On Apr 3, 2017, at 8:40 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> Thanks Matt. With the Flume appender, do I still need to use an async logger 
> to get the best perf?
> 
> Gary
> 
> On Mon, Apr 3, 2017 at 8:31 PM, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> Clarifications: other than the file appenders, the flume appender is probably 
> the most reliable appender.
> 
> And for the direct appender config, that's also with fully async loggers. 
> I've been considering putting together a small blog post about the most 
> efficient log4j2.xml configurations.
> 
> On 3 April 2017 at 22:01, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> The Flume appender can persist messages within the same process to files 
> before sending them to other agents. I don't think any other appender can 
> guarantee that.
> 
> Personally, I've been using direct console appenders lately and using graylog 
> to slurp stdout on docker containers, but I'm not the one who set all that 
> up. Either way, the most reliable way to log things outside of files is Flume.
> 
> On 3 April 2017 at 19:45, Gary Gregory <garydgreg...@gmail.com 
> <mailto:garydgreg...@gmail.com>> wrote:
> Wait a sec. A JMS provider can guarantee message delivery. How can events be 
> lost once they are in the provider? Are you saying that using an async logger 
> is 'unsafe' because the events in the ring buffer go away if the JVM goes 
> down?
> 
> Ideally I want to publish and forget, with the publish part asynchronous, 
> call the API, and it returns right away.
> 
> Is there no way to do that with our JMS Appender?
> 
> Gary
> 
> On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> What’s the point though when all you have to do is specify the pattern layout 
> with “%m%ex{none}”?
> 
> How can you do auditing with the async logger? You may lose events with that.
> 
> Your use case is exactly why I wrote the FlumeAppender. It is very much like 
> JMS but a whole lot faster and guarantees events aren’t lost.
> 
> Ralph
> 
>> On Apr 3, 2017, at 5:03 PM, Gary Gregory <garydgreg...@gmail.com 
>> <mailto:garydgreg...@gmail.com>> wrote:
>> 
>> Right. I want to post to JMS message objects I've serialized to JSON. All I 
>> care about is the message.
>> 
>> I log these events to a specially named logger with a specially named 
>> marker. These are the only events that should be published to JMS (I use a 
>> filter and the one marker). I am in charge of the message format and it is 
>> consumed on the other JMS side by a specialized agent which I also control.
>> 
>> IOW, I am using the Log4j infrastructure as the simplest way to send custom 
>> messages over to JMS. These are not traditional logging events, rather a 
>> kind of auditing system. I leverage the Log4j async logger as well. No need 
>> to deal with the JMS API.
>> 
>> Gary
>> 
>> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> So, exceptions are swallowed and no newlines are rendered? Interesting. 
>> What's the use case?
>> 
>> Sent from my iPhone
>> 
>> On Apr 4, 2017, at 7:30, Gary Gregory <garydgreg...@gmail.com 
>> <mailto:garydgreg...@gmail.com>> wrote:
>> 
>>> Hi All,
>>> 
>>> I am considering a new layout called "MessageLayout" which would be 
>>> synonymous with:. Thoughts? 
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | 
>>> ggreg...@apache.org  <mailto:ggreg...@apache.org>
>>> Java Persistence with Hibernate, Second Edition 
>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>   
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>

Re: MessageLayout

[Ralph Goers]

No. JMS does not guarantee delivery in the way your would want. Sure, if the 
JMS service says it accepted the event then it is guaranteed, but if it doesn’t 
what are you going to do with the event? It is stuck in the client. You would 
have to invent some way to queue the events and then retry them later.

The Flume Appender writes the event into a channel in the client and then gives 
control back to you. From that point on delivery is guaranteed downstream. It 
uses a separate thread to pull from the channel and write to a downstream flume 
agent. That agent can use any of the sinks that Flume provides to write the 
data to Kafka, Hadoop, ElasticSearch, etc. or you can write a custom Sink to do 
whatever you want. I used Flume at my previous employer and am using it 
currently and I can tell you that it is extremely reliable and the throughput 
is pretty good.

Yes, logging asynchronously is unsafe because all in-flight events will be 
lost. That is fine for normal debug logs but is unacceptable for auditing. 
Again, because Flume writes to the file channel that won’t happen unless you 
disk is full.

If you use JMS then you have to handle the case where event delivery fails for 
whatever reason, or you have to require that your JMS service is 100% reliable.

Ralph

> On Apr 3, 2017, at 5:45 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> Wait a sec. A JMS provider can guarantee message delivery. How can events be 
> lost once they are in the provider? Are you saying that using an async logger 
> is 'unsafe' because the events in the ring buffer go away if the JVM goes 
> down?
> 
> Ideally I want to publish and forget, with the publish part asynchronous, 
> call the API, and it returns right away.
> 
> Is there no way to do that with our JMS Appender?
> 
> Gary
> 
> On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> What’s the point though when all you have to do is specify the pattern layout 
> with “%m%ex{none}”?
> 
> How can you do auditing with the async logger? You may lose events with that.
> 
> Your use case is exactly why I wrote the FlumeAppender. It is very much like 
> JMS but a whole lot faster and guarantees events aren’t lost.
> 
> Ralph
> 
>> On Apr 3, 2017, at 5:03 PM, Gary Gregory <garydgreg...@gmail.com 
>> <mailto:garydgreg...@gmail.com>> wrote:
>> 
>> Right. I want to post to JMS message objects I've serialized to JSON. All I 
>> care about is the message.
>> 
>> I log these events to a specially named logger with a specially named 
>> marker. These are the only events that should be published to JMS (I use a 
>> filter and the one marker). I am in charge of the message format and it is 
>> consumed on the other JMS side by a specialized agent which I also control.
>> 
>> IOW, I am using the Log4j infrastructure as the simplest way to send custom 
>> messages over to JMS. These are not traditional logging events, rather a 
>> kind of auditing system. I leverage the Log4j async logger as well. No need 
>> to deal with the JMS API.
>> 
>> Gary
>> 
>> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> So, exceptions are swallowed and no newlines are rendered? Interesting. 
>> What's the use case?
>> 
>> Sent from my iPhone
>> 
>> On Apr 4, 2017, at 7:30, Gary Gregory <garydgreg...@gmail.com 
>> <mailto:garydgreg...@gmail.com>> wrote:
>> 
>>> Hi All,
>>> 
>>> I am considering a new layout called "MessageLayout" which would be 
>>> synonymous with:. Thoughts? 
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | 
>>> ggreg...@apache.org  <mailto:ggreg...@apache.org>
>>> Java Persistence with Hibernate, Second Edition 
>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>   
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
>>> JUnit in Action, Second Edition 
>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>   
>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
>>> Spring Batch in Action 
>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7

Re: MessageLayout

[Ralph Goers]

What’s the point though when all you have to do is specify the pattern layout 
with “%m%ex{none}”?

How can you do auditing with the async logger? You may lose events with that.

Your use case is exactly why I wrote the FlumeAppender. It is very much like 
JMS but a whole lot faster and guarantees events aren’t lost.

Ralph

> On Apr 3, 2017, at 5:03 PM, Gary Gregory  wrote:
> 
> Right. I want to post to JMS message objects I've serialized to JSON. All I 
> care about is the message.
> 
> I log these events to a specially named logger with a specially named marker. 
> These are the only events that should be published to JMS (I use a filter and 
> the one marker). I am in charge of the message format and it is consumed on 
> the other JMS side by a specialized agent which I also control.
> 
> IOW, I am using the Log4j infrastructure as the simplest way to send custom 
> messages over to JMS. These are not traditional logging events, rather a kind 
> of auditing system. I leverage the Log4j async logger as well. No need to 
> deal with the JMS API.
> 
> Gary
> 
> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma  > wrote:
> So, exceptions are swallowed and no newlines are rendered? Interesting. 
> What's the use case?
> 
> Sent from my iPhone
> 
> On Apr 4, 2017, at 7:30, Gary Gregory  > wrote:
> 
>> Hi All,
>> 
>> I am considering a new layout called "MessageLayout" which would be 
>> synonymous with:. Thoughts? 
>> 
>> Gary
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>>   
>> 
>> JUnit in Action, Second Edition 
>> 
>>   
>> 
>> Spring Batch in Action 
>> 
>>   
>> 
>> Blog: http://garygregory.wordpress.com  
>> Home: http://garygregory.com/ 
>> Tweet! http://twitter.com/GaryGregory 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
>   
> 
> JUnit in Action, Second Edition 
> 
>   
> 
> Spring Batch in Action 
> 
>   
> 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 

Re: Scala

[Ralph Goers]

I believe Flume is using Sphinx, but I think that is still driving from Maven. 
I would look at some other Apache sites, find one you like and then figure out 
how they did it.

Ralph

> On Apr 3, 2017, at 7:11 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> We don't have to use maven-site-plugin to generate the Scala site. That's 
> just the easy way to do it in theory, though I find it cumbersome. If you 
> know of any better documentation generator that we could use there (or even 
> in log4j-core), please let us know!
> 
> On 3 April 2017 at 04:06, Mikael Ståldal <mikael.stal...@magine.com 
> <mailto:mikael.stal...@magine.com>> wrote:
> Using SBT would help to avoid having to duplicate the source code for each 
> Scala version. However, I'm not sure about how to do the Maven site stuff 
> with SBT.
> 
> On Sun, Apr 2, 2017 at 10:41 PM, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> I'm not too experienced with it, but now that the Scala APIs are in their own 
> repo, it might be easier to use SBT instead of Maven for it. Just a thought 
> for a future release.
> 
> On 2 April 2017 at 15:27, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> And don't mind the site commit I made earlier. That was from a snapshot, so I 
> have to commit it again anyways.
> 
> On 2 April 2017 at 15:25, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> No, I figured I'd do log4j-core first. Still working on that right now, had 
> to restart the build from the tag because a test randomly decided to fail at 
> the worst possible time.
> 
> On 2 April 2017 at 15:11, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Has a Scala release been performed? The site needs to be deployed before I 
> can modify the log4j page(s) to point to it.
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
> <mailto:log4j-dev-unsubscr...@logging.apache.org>
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
> <mailto:log4j-dev-h...@logging.apache.org>
> 
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> <http://www.magine.com/>
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Re: Deep Dive into Java 9’s Stack-Walking API

[Ralph Goers]

Where have you been?  I posted performance benchmarks based on that a week or 
two ago. See all my updates to LOG4J2-1359.

I have already implemented StackWalker support on branch java9NoMultiRelease. I 
started on a branch for LOG4J2-1359 but trouble with the Multi-Release jar made 
me rethink it so I reimplemented it on the new branch. Once I have support for 
modules I will be merging it back into the LOG4J2-1359 branch and looking for a 
code review. In the meantime you are free to look at the java9NoMultiRelease 
branch.

Ralph


> On Apr 2, 2017, at 10:03 PM, Gary Gregory  wrote:
> 
> FYI: https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/ 
> 
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
>   
> 
> JUnit in Action, Second Edition 
> 
>   
> 
> Spring Batch in Action 
> 
>   
> 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 

Re: Need a 2.8.2 logo

[Ralph Goers]

I created a logo and updated src/site/resources/images/logo.png.

Ralph

> On Apr 2, 2017, at 2:35 PM, Matt Sicker <boa...@gmail.com> wrote:
> 
> The download page is templated based on a couple properties in the root 
> pom.xml. I think I added that back when I did my first release. I did 
> remember to update that before making the RC.
> 
> On 2 April 2017 at 16:24, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Oh. I just saw the release vote email. You should have done this before you 
> ran the release build. It isn’t a showstopper though.
> 
> Ralph
> 
>> On Apr 2, 2017, at 2:22 PM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> 
>> I believe I follow the same process as Gary. In src/site/resources/logo you 
>> will find a bunch of logo’s that Gary generated. All the ones that have been 
>> used have a version numbered image. I just pick the next one I like and edit 
>> it in gimp and add the version number. 
>> 
>> If you are unable to do that I am sure I can find some time.
>> 
>> Also, if you are doing a release then make sure you change the download page 
>> where it has my name and key.  I wish there was a better way to do this but 
>> I am not aware that there is.
>> 
>> Ralph
>> 
>>> On Apr 2, 2017, at 1:45 PM, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>> The release instructions mention updating the logo, though I'm not a 
>>> graphics person anymore. Can someone make the updated logo? I'm taking care 
>>> of the rest of the release process right now.
>>> 
>>> -- 
>>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
>> 
> 
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Re: Need a 2.8.2 logo

[Ralph Goers]

Oh. I just saw the release vote email. You should have done this before you ran 
the release build. It isn’t a showstopper though.

Ralph

> On Apr 2, 2017, at 2:22 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> I believe I follow the same process as Gary. In src/site/resources/logo you 
> will find a bunch of logo’s that Gary generated. All the ones that have been 
> used have a version numbered image. I just pick the next one I like and edit 
> it in gimp and add the version number. 
> 
> If you are unable to do that I am sure I can find some time.
> 
> Also, if you are doing a release then make sure you change the download page 
> where it has my name and key.  I wish there was a better way to do this but I 
> am not aware that there is.
> 
> Ralph
> 
>> On Apr 2, 2017, at 1:45 PM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> The release instructions mention updating the logo, though I'm not a 
>> graphics person anymore. Can someone make the updated logo? I'm taking care 
>> of the rest of the release process right now.
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 

Re: Need a 2.8.2 logo

[Ralph Goers]

I believe I follow the same process as Gary. In src/site/resources/logo you 
will find a bunch of logo’s that Gary generated. All the ones that have been 
used have a version numbered image. I just pick the next one I like and edit it 
in gimp and add the version number. 

If you are unable to do that I am sure I can find some time.

Also, if you are doing a release then make sure you change the download page 
where it has my name and key.  I wish there was a better way to do this but I 
am not aware that there is.

Ralph

> On Apr 2, 2017, at 1:45 PM, Matt Sicker  wrote:
> 
> The release instructions mention updating the logo, though I'm not a graphics 
> person anymore. Can someone make the updated logo? I'm taking care of the 
> rest of the release process right now.
> 
> -- 
> Matt Sicker >

Scala

[Ralph Goers]

Has a Scala release been performed? The site needs to be deployed before I can 
modify the log4j page(s) to point to it.

Ralph

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Fwd: Slack Invites

[Ralph Goers]

I have created a logging channel on Slack for anyone who wants to use it.

Ralph


> Begin forwarded message:
> 
> From: "John D. Ament" 
> Subject: Slack Invites
> Date: March 29, 2017 at 6:54:53 AM MST
> To: "gene...@incubator.apache.org" 
> Reply-To: gene...@incubator.apache.org
> 
> All,
> 
> Based on the on-going discussions, I decided to move ahead with a single
> organization for Slack.  I've opened up registrations to all @apache.org
> email addresses.  To get set up, please use https://the-asf.slack.com/signup 
> to
> get your account up and running.
> 
> Happy Slacking!
> 
> John

[jira] [Resolved] (LOG4J2-1859) Add rolling date support to fileName, RollingRandomAccessFile

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-1859.
-
Resolution: Not A Problem

This is working as designed. The fileName is indeed a file name that never 
changes while the application is running.  If you do not want this behavior 
upgrade to the latest version of Log4j 2 and do not specify the fileName 
attribute.

> Add rolling date support to fileName, RollingRandomAccessFile
> -
>
> Key: LOG4J2-1859
> URL: https://issues.apache.org/jira/browse/LOG4J2-1859
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.6.2
> Environment: All
>Reporter: Danny Chen
>Priority: Minor
>
> We are currently using Log4j2 version 2.6.2.  Within our configuration, we 
> are using RollingRandomAccessFile. For the "filePattern", there is date 
> support and rolling date support.  But for "fileName", there is no date 
> rolling support.
> Example:
>  fileName="logs/app-${date:-MM-dd}.log" 
> filePattern="logs/$${date:-MM}/app-%d{MM-dd-}-%i.log.gz">
> With the above config, once the rolling is done on the next date, the current 
> log file is still the current date.  It seems as the current log file name is 
> always fixed.  There is no rolling to it.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

Matt,

Any update on this?

Ralph

> On Mar 21, 2017, at 10:27 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> Thanks Matt!
> 
> Ralph
> 
>> On Mar 21, 2017, at 10:15 AM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> No other opinions apparently. I suppose we'll go with the single list with 
>> bounce messages. I'll follow up with infra later today.
>> 
>> On 18 March 2017 at 13:12, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> OK. I guess I am fine with the bounce messages. Any other opinions?
>> 
>> Ralph
>> 
>>> On Mar 18, 2017, at 8:42 AM, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>> I got this response from Gavin:
>>> 
>>> Hi [~jvz] Sorry but I think I'm going to push back on that last request.
>>> 
>>> Merging the lists - no problem
>>> Merging all the subscribers - no problem
>>> Creating bounce messages directing people to use the merged target list - 
>>> no problem
>>> 
>>> People will know in advance this merger is going to take place, and if they 
>>> forget I think it'll take only one or two bounce messages to get the hint.
>>> 
>>> If you are :-
>>> 
>>> a) Happy with that - pick a date this can be done , let all lists users 
>>> know this is happening and the date then let me know.
>>> b) Not Happy with that - ping this ticket again and we'll escalate further.
>>> 
>>> Thanks
>>> 
>>> On 16 March 2017 at 22:23, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> Oh, I didn't realise I had a response on how to handle that. Let me follow 
>>> up with infra.
>>> 
>>> On 16 March 2017 at 21:46, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> Is there any follow-up to this?  
>>> 
>>> Ralph
>>> 
>>>> On Mar 12, 2017, at 9:30 PM, Ralph Goers <ralph.go...@dslextreme.com 
>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> 
>>>> 1. That seems fine to me.
>>>> 2. Is it possible to do both? I like the idea of annoying the sender but 
>>>> still allowing the email to be sent. It would cool if it could even add 
>>>> [list] to the start of the subject line.
>>>> 3. This is the main thing that needs to happen.
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>> 
>>>>> On Mar 12, 2017, at 7:49 PM, Matt Sicker <boa...@gmail.com 
>>>>> <mailto:boa...@gmail.com>> wrote:
>>>>> 
>>>>> Some things:
>>>>> 
>>>>> 1. Archives won't be merged.
>>>>> 2. Infra suggests it might be a better idea to have the old email 
>>>>> addresses respond with a canned reply saying that the lists have moved 
>>>>> over to dev@, though they can set it up all as aliases if we prefer.
>>>>> 3. Current subscribers from all dev lists would be automatically 
>>>>> subscribed to the combined list.
>>>>> 
>>>>> So, use aliases or have the old addresses bounce back and inform senders 
>>>>> to use the new list?
>>>>> 
>>>>> On 12 March 2017 at 18:31, Matt Sicker <boa...@gmail.com 
>>>>> <mailto:boa...@gmail.com>> wrote:
>>>>> Created a request, not sure if it's public: 
>>>>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651 
>>>>> <https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651>
>>>>> 
>>>>> On 12 March 2017 at 17:11, Ralph Goers <ralph.go...@dslextreme.com 
>>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>>> Yes,
>>>>> 
>>>>> If you could send the request to infra I would appreciate it.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On Mar 12, 2017, at 1:13 PM, Matt Sicker <boa...@gmail.com 
>>>>>> <mailto:boa...@gmail.com>> wrote:
>>>>>> 
>>>>>> The vote has been open for 5 days now. Based on the tallies and 
>>>>>> discussions, it sounds like we'd like to merge the dev lists but keep 
>>>>>> the user lists as is. 

[jira] [Assigned] (LOG4J2-1833) NullPointerException using fileName property of RollingFile Appender with DirectWriteRolloverStrategy

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers reassigned LOG4J2-1833:
---

Assignee: Ralph Goers

> NullPointerException using fileName property of RollingFile Appender with 
> DirectWriteRolloverStrategy
> -
>
> Key: LOG4J2-1833
> URL: https://issues.apache.org/jira/browse/LOG4J2-1833
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8.1
> Environment: Windows 7 64-bit JDK 8
>Reporter: Austin Huck
>Assignee: Ralph Goers
>Priority: Minor
>
> When using a {{RollingFileAppender}} with a {{DirectWriteRolloverStrategy}} 
> if the _fileName_ property of the appender is set, rollover fails with a 
> {{NullPointerException}}. If the _fileName_ attribute is not present logging 
> works as intended.
> Configuration that produces this error:
> {code:title=log4j2.xml|borderStyle=solid}
> 
> 
> 
> C:/logs
> 
> 
>   
> filePattern="${baseDir}/app-%d{-MM-dd'T'HH_mm_ss}.log">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> Stack Trace:
> {noformat}
> 2017-03-02 13:38:52,023 main ERROR An exception occurred processing Appender 
> RollingFile java.lang.NullPointerException: activeFileName
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RolloverDescriptionImpl.(RolloverDescriptionImpl.java:60)
>   at 
> org.apache.logging.log4j.core.appender.rolling.DirectWriteRolloverStrategy.rollover(DirectWriteRolloverStrategy.java:194)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:362)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:278)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:218)
>   at 
> org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:267)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:439)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:434)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:403)
>   at 
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
>   at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2091)
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1993)
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1852)
>   at org.apache.logging.slf4j.Log4jLogger.error(Log4jLogger.java:299)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1833) NullPointerException using fileName property of RollingFile Appender with DirectWriteRolloverStrategy

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15943496#comment-15943496
 ] 

Ralph Goers commented on LOG4J2-1833:
-

While this error needs to be fixed, the result of the fix is going to be that 
an error will be logged during configuration and the Appender will be disabled. 
The "real" fix is to not specify a fileName attribute as is documented.

> NullPointerException using fileName property of RollingFile Appender with 
> DirectWriteRolloverStrategy
> -
>
> Key: LOG4J2-1833
> URL: https://issues.apache.org/jira/browse/LOG4J2-1833
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8.1
> Environment: Windows 7 64-bit JDK 8
>Reporter: Austin Huck
>Priority: Minor
>
> When using a {{RollingFileAppender}} with a {{DirectWriteRolloverStrategy}} 
> if the _fileName_ property of the appender is set, rollover fails with a 
> {{NullPointerException}}. If the _fileName_ attribute is not present logging 
> works as intended.
> Configuration that produces this error:
> {code:title=log4j2.xml|borderStyle=solid}
> 
> 
> 
> C:/logs
> 
> 
>   
> filePattern="${baseDir}/app-%d{-MM-dd'T'HH_mm_ss}.log">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> Stack Trace:
> {noformat}
> 2017-03-02 13:38:52,023 main ERROR An exception occurred processing Appender 
> RollingFile java.lang.NullPointerException: activeFileName
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RolloverDescriptionImpl.(RolloverDescriptionImpl.java:60)
>   at 
> org.apache.logging.log4j.core.appender.rolling.DirectWriteRolloverStrategy.rollover(DirectWriteRolloverStrategy.java:194)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:362)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:278)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:218)
>   at 
> org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:267)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:439)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:434)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:403)
>   at 
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
>   at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2091)
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1993)
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1852)
>   at org.apache.logging.slf4j.Log4jLogger.error(Log4jLogger.java:299)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

Thanks Matt!

Ralph

> On Mar 21, 2017, at 10:15 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> No other opinions apparently. I suppose we'll go with the single list with 
> bounce messages. I'll follow up with infra later today.
> 
> On 18 March 2017 at 13:12, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> OK. I guess I am fine with the bounce messages. Any other opinions?
> 
> Ralph
> 
>> On Mar 18, 2017, at 8:42 AM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> I got this response from Gavin:
>> 
>> Hi [~jvz] Sorry but I think I'm going to push back on that last request.
>> 
>> Merging the lists - no problem
>> Merging all the subscribers - no problem
>> Creating bounce messages directing people to use the merged target list - no 
>> problem
>> 
>> People will know in advance this merger is going to take place, and if they 
>> forget I think it'll take only one or two bounce messages to get the hint.
>> 
>> If you are :-
>> 
>> a) Happy with that - pick a date this can be done , let all lists users know 
>> this is happening and the date then let me know.
>> b) Not Happy with that - ping this ticket again and we'll escalate further.
>> 
>> Thanks
>> 
>> On 16 March 2017 at 22:23, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> Oh, I didn't realise I had a response on how to handle that. Let me follow 
>> up with infra.
>> 
>> On 16 March 2017 at 21:46, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> Is there any follow-up to this?  
>> 
>> Ralph
>> 
>>> On Mar 12, 2017, at 9:30 PM, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> 
>>> 1. That seems fine to me.
>>> 2. Is it possible to do both? I like the idea of annoying the sender but 
>>> still allowing the email to be sent. It would cool if it could even add 
>>> [list] to the start of the subject line.
>>> 3. This is the main thing that needs to happen.
>>> 
>>> Ralph
>>> 
>>> 
>>> 
>>>> On Mar 12, 2017, at 7:49 PM, Matt Sicker <boa...@gmail.com 
>>>> <mailto:boa...@gmail.com>> wrote:
>>>> 
>>>> Some things:
>>>> 
>>>> 1. Archives won't be merged.
>>>> 2. Infra suggests it might be a better idea to have the old email 
>>>> addresses respond with a canned reply saying that the lists have moved 
>>>> over to dev@, though they can set it up all as aliases if we prefer.
>>>> 3. Current subscribers from all dev lists would be automatically 
>>>> subscribed to the combined list.
>>>> 
>>>> So, use aliases or have the old addresses bounce back and inform senders 
>>>> to use the new list?
>>>> 
>>>> On 12 March 2017 at 18:31, Matt Sicker <boa...@gmail.com 
>>>> <mailto:boa...@gmail.com>> wrote:
>>>> Created a request, not sure if it's public: 
>>>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651 
>>>> <https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651>
>>>> 
>>>> On 12 March 2017 at 17:11, Ralph Goers <ralph.go...@dslextreme.com 
>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> Yes,
>>>> 
>>>> If you could send the request to infra I would appreciate it.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Mar 12, 2017, at 1:13 PM, Matt Sicker <boa...@gmail.com 
>>>>> <mailto:boa...@gmail.com>> wrote:
>>>>> 
>>>>> The vote has been open for 5 days now. Based on the tallies and 
>>>>> discussions, it sounds like we'd like to merge the dev lists but keep the 
>>>>> user lists as is. Shall we move forward with combining them now?
>>>>> 
>>>>> On 10 March 2017 at 12:27, Dominik Psenner <dpsen...@gmail.com 
>>>>> <mailto:dpsen...@gmail.com>> wrote:
>>>>> Total agreement.
>>>>> 
>>>>> On 10 Mar 2017 6:26 p.m., "Ralph Goers" <ralph.go...@dslextreme.com 
>>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>>> This is exactly why we need one dev list. These last two responses 
>>>>> dropped

Re: Java 9 support

[Ralph Goers]

I opened https://issues.apache.org/jira/browse/FELIX-5527 
<https://issues.apache.org/jira/browse/FELIX-5527>. Apparently the problem is 
with bnd-tools who seem to be ignoring the problem because Java 9 isn’t final. 
Since OSGi bundles don’t or won’t have support for multi-release jars they will 
fall back to using the slower methods.  It is possible to address this by using 
something similar to how we load the binding between the Log4j API and the 
implementation, but I am reluctant to do this since Java 9 introduced something 
specifically for this purpose.

Ralph



> On Mar 16, 2017, at 7:55 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> OSGi and Jigsaw have considerable overlap in concepts, so I'm assuming there 
> will be integration efforts eventually. However, a friend went to JavaOne a 
> year or two ago, and the Jigsaw folk were very dismissive of OSGi in general 
> despite one of the leading OSGi spec leads being on the Jigsaw project.
> 
> On 16 March 2017 at 08:37, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Nevermind. I moved the dependency plugin after the bundle plugin so that the 
> classes are copied after the bundle plugin runs and all is well. I have no 
> idea how that will impact the OSGi bundle though. Then again, I have no idea 
> if OSGi will support multi-release jars.
> 
> Ralph
> 
>> On Mar 15, 2017, at 11:36 PM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> 
>> I have built the Java 9 code. Now I am copying the classes into the 
>> log4j-api jar. They have to be placed at META-INF/versions/9. However, when 
>> I do this I am getting an error from the Maven bundle plugin.
>> 
>> [INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
>> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT : 
>> Classes found in the wrong directory: 
>> {META-INF/versions/9/org/apache/logging/log4j/util/ReflectionUtil.class=org.apache.logging.log4j.util.ReflectionUtil,
>>  
>> META-INF/versions/9/org/apache/logging/log4j/util/ClassPredicate.class=org.apache.logging.log4j.util.ClassPredicate,
>>  
>> META-INF/versions/9/org/apache/logging/log4j/util/ClassNamePredicate.class=org.apache.logging.log4j.util.ClassNamePredicate}
>> [ERROR] Error(s) found in manifest configuration
>> 
>> Any idea on how to get around this?
>> 
>> Ralph
>> 
>> 
>> 
>> 
>> 
>>> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> 
>>> I don’t see a problem with it. What is released will still run fine on Java 
>>> 7. It will just have some Java 9 components in the jar.  The release is 
>>> scheduled for late July. I haven’t seen any indication that it will be 
>>> pushed again. I would rather be ready to take advantage of Java 9 on the 
>>> day it is released then be playing catch-up.
>>> 
>>> Ralph
>>> 
>>>> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.stal...@magine.com 
>>>> <mailto:mikael.stal...@magine.com>> wrote:
>>>> 
>>>> It would be bad to require Java 9 to build the main project as long as 
>>>> Java 9 is not released.
>>>> 
>>>> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.go...@dslextreme.com 
>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> I can’t change the JDK from JDK 1.7. The rest of the build must be 
>>>> compiled at Java 7 since that is what we support. I only want to compile 
>>>> the new classes with Java 9.
>>>> 
>>>> Using a profile is a very good solution. We would have to run the build 
>>>> twice but that would be OK.  I will give that a try.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boa...@gmail.com 
>>>>> <mailto:boa...@gmail.com>> wrote:
>>>>> 
>>>>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 
>>>>> versions. Since there's no official release of 9 yet, they don't seem to 
>>>>> have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>>>> 
>>>>> As for building this, the best solution I've seen so far basically 
>>>>> involves a bit of manual configuration using some inline ant tasks or 
>>>>> similar overly complicated nonsense which doesn't work well in any IDE to 
>>>>> d

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931946#comment-15931946
 ] 

Ralph Goers commented on LOG4J2-1359:
-

In the issue for the Maven bundle plugin it was suggested we use a "service" 
for the replaceable functionality, which I take to mean that the ServiceLoader 
should be used. I'll have to dwell on the issues in doing that.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931936#comment-15931936
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/19/17 8:27 PM:
--

Here are the results of the benchmarks. Overall, it seems that most of the 
tests are a bit slower in Java 9. Serializing an Event that has an Exception is 
a LOT slower, which is probably a result of the performance regression I 
already reported. However, getting the location information takes about 1/3 the 
time it did in Java 7. 

I don't understand the results of the serialization tests though. Although it 
is understandable that building a log event without an exception would be much 
faster than building one with one, I would have expected that building a 
serialized log event with location information would be about the same as 
building an event without location information + the time to get the location 
information. Instead, in Java 9 it is showing as slightly faster than getting 
the event without location information. I am thinking there must be something 
wrong with the test.

Java 7
{code}
Benchmark   
  Mode  Samples  Score  Error  Units
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithExceptionUsingBuilder  
  avgt5147.173 ±3.876  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutException   
  avgt5177.807 ±   18.619  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutExceptionUsingBuilder   
  avgt5146.371 ±9.554  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithException 
  avgt5  18450.541 ±  380.800  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutException
avgt5250.715 ±8.624  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutExceptionWithLocation
avgt5274.293 ±   35.927  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.getSourceLocationOfLogEvent  
  avgt5  19988.446 ± 1752.194  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.testBaseline 
  avgt5  0.391 ±0.028  ns/op
{code}

Java 9
{code}
Benchmark   
  Mode  Samples  Score  Error  Units
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithExceptionUsingBuilder  
  avgt5190.018 ±   28.264  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutException   
  avgt5228.393 ±   16.702  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutExceptionUsingBuilder   
  avgt5171.760 ±   26.799  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithException 
  avgt5  32257.972 ± 4868.261  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutException
avgt5285.204 ±   20.197  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutExceptionWithLocation
avgt5271.399 ±   28.883  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.getSourceLocationOfLogEvent  
  avgt5   6839.420 ± 1007.405  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.testBaseline 
  avgt5  0.402 ±0.009  ns/op
{code}


was (Author: ralph.go...@dslextreme.com):
Here are the results of the benchmarks. Overall, it seems that most of the 
tests are a bit slower in Java 9. Serializing an Event that has an Exception is 
a LOT slower, which is probably a result of the performance regression I 
already reported. However, getting the location information takes about 1/3 the 
time it did in Java 7. 

I don't understand the results of the serialization tests though. Although it 
is understandable that building a log event without an exception would be much 
faster than building one without one, I would have expected that building a 
serialized log event with location information would be about the same as 
building an event without location information + the time to get the location 
information. Instead, in Java 9 it is showing as slightly faster than getting 
the event without location information. I am thinking there must be something 
wrong with the test.

Java 7
{code}
Benchmark   
  Mode  Samples  Score  Error  Units
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithExceptionUsingBuilder  
  avgt

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931936#comment-15931936
 ] 

Ralph Goers commented on LOG4J2-1359:
-

Here are the results of the benchmarks. Overall, it seems that most of the 
tests are a bit slower in Java 9. Serializing an Event that has an Exception is 
a LOT slower, which is probably a result of the performance regression I 
already reported. However, getting the location information takes about 1/3 the 
time it did in Java 7. 

I don't understand the results of the serialization tests though. Although it 
is understandable that building a log event without an exception would be much 
faster than building one without one, I would have expected that building a 
serialized log event with location information would be about the same as 
building an event without location information + the time to get the location 
information. Instead, in Java 9 it is showing as slightly faster than getting 
the event without location information. I am thinking there must be something 
wrong with the test.

Java 7
{code}
Benchmark   
  Mode  Samples  Score  Error  Units
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithExceptionUsingBuilder  
  avgt5147.173 ±3.876  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutException   
  avgt5177.807 ±   18.619  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutExceptionUsingBuilder   
  avgt5146.371 ±9.554  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithException 
  avgt5  18450.541 ±  380.800  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutException
avgt5250.715 ±8.624  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutExceptionWithLocation
avgt5274.293 ±   35.927  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.getSourceLocationOfLogEvent  
  avgt5  19988.446 ± 1752.194  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.testBaseline 
  avgt5  0.391 ±0.028  ns/op
{code}

Java 9
{code}
Benchmark   
  Mode  Samples  Score  Error  Units
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithExceptionUsingBuilder  
  avgt5190.018 ±   28.264  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutException   
  avgt5228.393 ±   16.702  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createLogEventWithoutExceptionUsingBuilder   
  avgt5171.760 ±   26.799  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithException 
  avgt5  32257.972 ± 4868.261  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutException
avgt5285.204 ±   20.197  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.createSerializableLogEventProxyWithoutExceptionWithLocation
avgt5271.399 ±   28.883  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.getSourceLocationOfLogEvent  
  avgt5   6839.420 ± 1007.405  ns/op
o.a.l.l.p.j.Log4jLogEventBenchmark.testBaseline 
  avgt5  0.402 ±0.009  ns/op
{code}

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@

[jira] [Commented] (LOG4J2-1746) Add JDK9 build to Jenkins

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931827#comment-15931827
 ] 

Ralph Goers commented on LOG4J2-1746:
-

As part of implementing support for StackWalker a Jenkins Java 9 build needed 
to be created.

> Add JDK9 build to Jenkins
> -
>
> Key: LOG4J2-1746
> URL: https://issues.apache.org/jira/browse/LOG4J2-1746
> Project: Log4j 2
>  Issue Type: New Feature
> Environment: JDK9, builds.apache.org
>Reporter: Matt Sicker
>    Assignee: Ralph Goers
>
> Add a Jenkins job to build log4j via JDK9 such that it creates a 
> multi-release jar (LOG4J2-1745) that can be used in JDK7, JDK8, and JDK9. 
> This will aid in continuous integration testing and allow users to test 
> snapshots in a JDK9 environment as we implement issues from LOG4J2-1564 (Java 
> 9 epic).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1745) Add support for multi-release jars for JDK9+

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931825#comment-15931825
 ] 

Ralph Goers commented on LOG4J2-1745:
-

In order to implement support for StackWalker support for multi-release jars 
must be added.

> Add support for multi-release jars for JDK9+
> 
>
> Key: LOG4J2-1745
> URL: https://issues.apache.org/jira/browse/LOG4J2-1745
> Project: Log4j 2
>  Issue Type: New Feature
> Environment: JDK9 and future JDK releases
>Reporter: Matt Sicker
>    Assignee: Ralph Goers
>
> [JEP 238|http://openjdk.java.net/jeps/238] adds multi-release jars which 
> allow a jar to contain multiple versions of a class depending on which 
> version of the JVM/JDK is being used at runtime. This will help support for 
> new APIs in JDK9+ so that we don't need to rely on reflection to access newer 
> APIs dynamically. This is also useful in performance-critical sections (e.g., 
> LOG4J2-1359).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-1746) Add JDK9 build to Jenkins

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers reassigned LOG4J2-1746:
---

Assignee: Ralph Goers

> Add JDK9 build to Jenkins
> -
>
> Key: LOG4J2-1746
> URL: https://issues.apache.org/jira/browse/LOG4J2-1746
> Project: Log4j 2
>  Issue Type: New Feature
> Environment: JDK9, builds.apache.org
>Reporter: Matt Sicker
>    Assignee: Ralph Goers
>
> Add a Jenkins job to build log4j via JDK9 such that it creates a 
> multi-release jar (LOG4J2-1745) that can be used in JDK7, JDK8, and JDK9. 
> This will aid in continuous integration testing and allow users to test 
> snapshots in a JDK9 environment as we implement issues from LOG4J2-1564 (Java 
> 9 epic).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-1745) Add support for multi-release jars for JDK9+

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers reassigned LOG4J2-1745:
---

Assignee: Ralph Goers

> Add support for multi-release jars for JDK9+
> 
>
> Key: LOG4J2-1745
> URL: https://issues.apache.org/jira/browse/LOG4J2-1745
> Project: Log4j 2
>  Issue Type: New Feature
> Environment: JDK9 and future JDK releases
>Reporter: Matt Sicker
>    Assignee: Ralph Goers
>
> [JEP 238|http://openjdk.java.net/jeps/238] adds multi-release jars which 
> allow a jar to contain multiple versions of a class depending on which 
> version of the JVM/JDK is being used at runtime. This will help support for 
> new APIs in JDK9+ so that we don't need to rely on reflection to access newer 
> APIs dynamically. This is also useful in performance-critical sections (e.g., 
> LOG4J2-1359).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931455#comment-15931455
 ] 

Ralph Goers commented on LOG4J2-1359:
-

I have created branch LOG4J2-1359. To build Log4j you must install Java 9 and 
create a toolchains.xml that points to it. 

I have created a Jenkins job that verifies the build works in Jenkins 
(obviously). The only thing I don't like is that the toolchains.xml file has to 
be updated to point to the latest java 9 install. For some reason there is no 
symlink.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931455#comment-15931455
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/18/17 11:05 PM:
---

I have created branch LOG4J2-1359. To build Log4j you must install Java 9 and 
create a toolchains.xml that points to it. 

I have created a Jenkins job that verifies the build works in Jenkins 
(obviously). The only thing I don't like is that the toolchains.xml file has to 
be updated to point to the latest java 9 install. For some reason there is no 
symlink.

I still have to do some performance testing, but please take a look.


was (Author: ralph.go...@dslextreme.com):
I have created branch LOG4J2-1359. To build Log4j you must install Java 9 and 
create a toolchains.xml that points to it. 

I have created a Jenkins job that verifies the build works in Jenkins 
(obviously). The only thing I don't like is that the toolchains.xml file has to 
be updated to point to the latest java 9 install. For some reason there is no 
symlink.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

OK. I guess I am fine with the bounce messages. Any other opinions?

Ralph

> On Mar 18, 2017, at 8:42 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> I got this response from Gavin:
> 
> Hi [~jvz] Sorry but I think I'm going to push back on that last request.
> 
> Merging the lists - no problem
> Merging all the subscribers - no problem
> Creating bounce messages directing people to use the merged target list - no 
> problem
> 
> People will know in advance this merger is going to take place, and if they 
> forget I think it'll take only one or two bounce messages to get the hint.
> 
> If you are :-
> 
> a) Happy with that - pick a date this can be done , let all lists users know 
> this is happening and the date then let me know.
> b) Not Happy with that - ping this ticket again and we'll escalate further.
> 
> Thanks
> 
> On 16 March 2017 at 22:23, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> Oh, I didn't realise I had a response on how to handle that. Let me follow up 
> with infra.
> 
> On 16 March 2017 at 21:46, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Is there any follow-up to this?  
> 
> Ralph
> 
>> On Mar 12, 2017, at 9:30 PM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> 
>> 1. That seems fine to me.
>> 2. Is it possible to do both? I like the idea of annoying the sender but 
>> still allowing the email to be sent. It would cool if it could even add 
>> [list] to the start of the subject line.
>> 3. This is the main thing that needs to happen.
>> 
>> Ralph
>> 
>> 
>> 
>>> On Mar 12, 2017, at 7:49 PM, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>> Some things:
>>> 
>>> 1. Archives won't be merged.
>>> 2. Infra suggests it might be a better idea to have the old email addresses 
>>> respond with a canned reply saying that the lists have moved over to dev@, 
>>> though they can set it up all as aliases if we prefer.
>>> 3. Current subscribers from all dev lists would be automatically subscribed 
>>> to the combined list.
>>> 
>>> So, use aliases or have the old addresses bounce back and inform senders to 
>>> use the new list?
>>> 
>>> On 12 March 2017 at 18:31, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> Created a request, not sure if it's public: 
>>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651 
>>> <https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651>
>>> 
>>> On 12 March 2017 at 17:11, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> Yes,
>>> 
>>> If you could send the request to infra I would appreciate it.
>>> 
>>> Ralph
>>> 
>>>> On Mar 12, 2017, at 1:13 PM, Matt Sicker <boa...@gmail.com 
>>>> <mailto:boa...@gmail.com>> wrote:
>>>> 
>>>> The vote has been open for 5 days now. Based on the tallies and 
>>>> discussions, it sounds like we'd like to merge the dev lists but keep the 
>>>> user lists as is. Shall we move forward with combining them now?
>>>> 
>>>> On 10 March 2017 at 12:27, Dominik Psenner <dpsen...@gmail.com 
>>>> <mailto:dpsen...@gmail.com>> wrote:
>>>> Total agreement.
>>>> 
>>>> On 10 Mar 2017 6:26 p.m., "Ralph Goers" <ralph.go...@dslextreme.com 
>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> This is exactly why we need one dev list. These last two responses dropped 
>>>> the other lists.  This is a horrible way to have discussions that affect 
>>>> all the sub projects.
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>>> On Mar 10, 2017, at 9:11 AM, Matt Sicker <boa...@gmail.com 
>>>>> <mailto:boa...@gmail.com>> wrote:
>>>>> 
>>>>> I'd love to see more unified configurations in all the subprojects. Gary 
>>>>> mentioned that as an idea for log4cxx as that would make it useful for 
>>>>> his use case where they're using both Java and C++ in various projects.
>>>>> 
>>>>> While the programming languages in use here (Java, .NET, PHP, and C++) 
>>>>> aren't really compatible with each ot

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

Is there any follow-up to this?  

Ralph

> On Mar 12, 2017, at 9:30 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> 1. That seems fine to me.
> 2. Is it possible to do both? I like the idea of annoying the sender but 
> still allowing the email to be sent. It would cool if it could even add 
> [list] to the start of the subject line.
> 3. This is the main thing that needs to happen.
> 
> Ralph
> 
> 
> 
>> On Mar 12, 2017, at 7:49 PM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> Some things:
>> 
>> 1. Archives won't be merged.
>> 2. Infra suggests it might be a better idea to have the old email addresses 
>> respond with a canned reply saying that the lists have moved over to dev@, 
>> though they can set it up all as aliases if we prefer.
>> 3. Current subscribers from all dev lists would be automatically subscribed 
>> to the combined list.
>> 
>> So, use aliases or have the old addresses bounce back and inform senders to 
>> use the new list?
>> 
>> On 12 March 2017 at 18:31, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> Created a request, not sure if it's public: 
>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651 
>> <https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651>
>> 
>> On 12 March 2017 at 17:11, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> Yes,
>> 
>> If you could send the request to infra I would appreciate it.
>> 
>> Ralph
>> 
>>> On Mar 12, 2017, at 1:13 PM, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>> The vote has been open for 5 days now. Based on the tallies and 
>>> discussions, it sounds like we'd like to merge the dev lists but keep the 
>>> user lists as is. Shall we move forward with combining them now?
>>> 
>>> On 10 March 2017 at 12:27, Dominik Psenner <dpsen...@gmail.com 
>>> <mailto:dpsen...@gmail.com>> wrote:
>>> Total agreement.
>>> 
>>> On 10 Mar 2017 6:26 p.m., "Ralph Goers" <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> This is exactly why we need one dev list. These last two responses dropped 
>>> the other lists.  This is a horrible way to have discussions that affect 
>>> all the sub projects.
>>> 
>>> Ralph
>>> 
>>> 
>>>> On Mar 10, 2017, at 9:11 AM, Matt Sicker <boa...@gmail.com 
>>>> <mailto:boa...@gmail.com>> wrote:
>>>> 
>>>> I'd love to see more unified configurations in all the subprojects. Gary 
>>>> mentioned that as an idea for log4cxx as that would make it useful for his 
>>>> use case where they're using both Java and C++ in various projects.
>>>> 
>>>> While the programming languages in use here (Java, .NET, PHP, and C++) 
>>>> aren't really compatible with each other, having similar architectures and 
>>>> plugin systems could help a bit in this regard. Having more inclusive 
>>>> conversations about this would be great.
>>>> 
>>>> On 10 March 2017 at 04:29, Mikael Ståldal <mikael.stal...@magine.com 
>>>> <mailto:mikael.stal...@magine.com>> wrote:
>>>> I think that a vast majority of our users only uses one of the languages 
>>>> we support, and therefore only are interested in one of the subprojects.
>>>> 
>>>> On Fri, Mar 10, 2017 at 11:23 AM, Dominik Psenner <dpsen...@gmail.com 
>>>> <mailto:dpsen...@gmail.com>> wrote:
>>>> We had once the discussion that we wanted all Apache Logging projects to 
>>>> become very similar in their usage, starting with the same or a very 
>>>> similar configuration. Given that we should aim towards one Apache Logging 
>>>> specification and several Apache Logging specification implementations in 
>>>> the form of Apache Logging subprojects. That means all the devs for all 
>>>> subprojects have to talk more. To me this is a good reasons to merge the 
>>>> dev mailing lists. Further I don't see why the same use case should not 
>>>> apply to the user mailing lists, too. Those mailing lists see very low 
>>>> traffic but all of them need a larger audience. Just quoting the last few 
>>>> messages of two user mailing lists I follow:
>>>&g

Re: Java 9 support

[Ralph Goers]

Nevermind. I moved the dependency plugin after the bundle plugin so that the 
classes are copied after the bundle plugin runs and all is well. I have no idea 
how that will impact the OSGi bundle though. Then again, I have no idea if OSGi 
will support multi-release jars.

Ralph

> On Mar 15, 2017, at 11:36 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> I have built the Java 9 code. Now I am copying the classes into the log4j-api 
> jar. They have to be placed at META-INF/versions/9. However, when I do this I 
> am getting an error from the Maven bundle plugin.
> 
> [INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT : 
> Classes found in the wrong directory: 
> {META-INF/versions/9/org/apache/logging/log4j/util/ReflectionUtil.class=org.apache.logging.log4j.util.ReflectionUtil,
>  
> META-INF/versions/9/org/apache/logging/log4j/util/ClassPredicate.class=org.apache.logging.log4j.util.ClassPredicate,
>  
> META-INF/versions/9/org/apache/logging/log4j/util/ClassNamePredicate.class=org.apache.logging.log4j.util.ClassNamePredicate}
> [ERROR] Error(s) found in manifest configuration
> 
> Any idea on how to get around this?
> 
> Ralph
> 
> 
> 
> 
> 
>> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> 
>> I don’t see a problem with it. What is released will still run fine on Java 
>> 7. It will just have some Java 9 components in the jar.  The release is 
>> scheduled for late July. I haven’t seen any indication that it will be 
>> pushed again. I would rather be ready to take advantage of Java 9 on the day 
>> it is released then be playing catch-up.
>> 
>> Ralph
>> 
>>> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.stal...@magine.com 
>>> <mailto:mikael.stal...@magine.com>> wrote:
>>> 
>>> It would be bad to require Java 9 to build the main project as long as Java 
>>> 9 is not released.
>>> 
>>> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> I can’t change the JDK from JDK 1.7. The rest of the build must be compiled 
>>> at Java 7 since that is what we support. I only want to compile the new 
>>> classes with Java 9.
>>> 
>>> Using a profile is a very good solution. We would have to run the build 
>>> twice but that would be OK.  I will give that a try.
>>> 
>>> Ralph
>>> 
>>>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boa...@gmail.com 
>>>> <mailto:boa...@gmail.com>> wrote:
>>>> 
>>>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 
>>>> versions. Since there's no official release of 9 yet, they don't seem to 
>>>> have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>>> 
>>>> As for building this, the best solution I've seen so far basically 
>>>> involves a bit of manual configuration using some inline ant tasks or 
>>>> similar overly complicated nonsense which doesn't work well in any IDE to 
>>>> date. It may be worth investigating the existing maven plugin ecosystem 
>>>> and seeing if we need a custom plugin developed for this. Could be a 
>>>> useful feature addition to maven-compiler-plugin, though I haven't tried 
>>>> contributing to Maven yet.
>>>> 
>>>> Using Maven profiles would help with this so that we can still build most 
>>>> of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to 
>>>> install JDK 9 on all their development machines while it's still in beta.
>>>> 
>>>> On 15 March 2017 at 10:07, Ralph Goers <ralph.go...@dslextreme.com 
>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> I know how to implement the StackWalker code but I don’t quite know how to 
>>>> get it into the build. The main build needs to keep using Java 7 but of 
>>>> course the StackWalker stuff needs to be compiled with Java 9. 
>>>> Technically, I know how I could do that except I have no idea how it would 
>>>> work in Jenkins. It would also mean that everyone would be required to 
>>>> have Java 9 installed in order to do the build.
>>>> 
>>>> An alternate approach would be to have the Java 9 specific classes in a 
>>>> separate repo with its own build. It would have to be “released” 

Re: Java 9 support

[Ralph Goers]

I have built the Java 9 code. Now I am copying the classes into the log4j-api 
jar. They have to be placed at META-INF/versions/9. However, when I do this I 
am getting an error from the Maven bundle plugin.

[INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
[ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT : 
Classes found in the wrong directory: 
{META-INF/versions/9/org/apache/logging/log4j/util/ReflectionUtil.class=org.apache.logging.log4j.util.ReflectionUtil,
 
META-INF/versions/9/org/apache/logging/log4j/util/ClassPredicate.class=org.apache.logging.log4j.util.ClassPredicate,
 
META-INF/versions/9/org/apache/logging/log4j/util/ClassNamePredicate.class=org.apache.logging.log4j.util.ClassNamePredicate}
[ERROR] Error(s) found in manifest configuration

Any idea on how to get around this?

Ralph





> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> I don’t see a problem with it. What is released will still run fine on Java 
> 7. It will just have some Java 9 components in the jar.  The release is 
> scheduled for late July. I haven’t seen any indication that it will be pushed 
> again. I would rather be ready to take advantage of Java 9 on the day it is 
> released then be playing catch-up.
> 
> Ralph
> 
>> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> 
>> It would be bad to require Java 9 to build the main project as long as Java 
>> 9 is not released.
>> 
>> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> I can’t change the JDK from JDK 1.7. The rest of the build must be compiled 
>> at Java 7 since that is what we support. I only want to compile the new 
>> classes with Java 9.
>> 
>> Using a profile is a very good solution. We would have to run the build 
>> twice but that would be OK.  I will give that a try.
>> 
>> Ralph
>> 
>>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 
>>> versions. Since there's no official release of 9 yet, they don't seem to 
>>> have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>> 
>>> As for building this, the best solution I've seen so far basically involves 
>>> a bit of manual configuration using some inline ant tasks or similar overly 
>>> complicated nonsense which doesn't work well in any IDE to date. It may be 
>>> worth investigating the existing maven plugin ecosystem and seeing if we 
>>> need a custom plugin developed for this. Could be a useful feature addition 
>>> to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
>>> 
>>> Using Maven profiles would help with this so that we can still build most 
>>> of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to 
>>> install JDK 9 on all their development machines while it's still in beta.
>>> 
>>> On 15 March 2017 at 10:07, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> I know how to implement the StackWalker code but I don’t quite know how to 
>>> get it into the build. The main build needs to keep using Java 7 but of 
>>> course the StackWalker stuff needs to be compiled with Java 9. Technically, 
>>> I know how I could do that except I have no idea how it would work in 
>>> Jenkins. It would also mean that everyone would be required to have Java 9 
>>> installed in order to do the build.
>>> 
>>> An alternate approach would be to have the Java 9 specific classes in a 
>>> separate repo with its own build. It would have to be “released” but we 
>>> really wouldn’t need or want to release those jars to Maven Central as they 
>>> would only be needed in the Log4j build - the classes would be copied into 
>>> the Log4j jar.
>>> 
>>> If any of you know we can set a Jenkins variable to point to the latest 
>>> Java 9 version that could solve the problem.
>>> 
>>> Ralph
>>> 
>>> -
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
>>> <mailto:log4j-dev-unsubscr...@logging.apache.org>
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
>>> <mailto:log4j-dev-h...@logging.ap

Re: Java 9 support

[Ralph Goers]

I don’t see a problem with it. What is released will still run fine on Java 7. 
It will just have some Java 9 components in the jar.  The release is scheduled 
for late July. I haven’t seen any indication that it will be pushed again. I 
would rather be ready to take advantage of Java 9 on the day it is released 
then be playing catch-up.

Ralph

> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> It would be bad to require Java 9 to build the main project as long as Java 9 
> is not released.
> 
> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> I can’t change the JDK from JDK 1.7. The rest of the build must be compiled 
> at Java 7 since that is what we support. I only want to compile the new 
> classes with Java 9.
> 
> Using a profile is a very good solution. We would have to run the build twice 
> but that would be OK.  I will give that a try.
> 
> Ralph
> 
>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 versions. 
>> Since there's no official release of 9 yet, they don't seem to have a "JDK 9 
>> (latest)" profile set up on Jenkins yet.
>> 
>> As for building this, the best solution I've seen so far basically involves 
>> a bit of manual configuration using some inline ant tasks or similar overly 
>> complicated nonsense which doesn't work well in any IDE to date. It may be 
>> worth investigating the existing maven plugin ecosystem and seeing if we 
>> need a custom plugin developed for this. Could be a useful feature addition 
>> to maven-compiler-plugin, though I haven't tried contributing to Maven yet.
>> 
>> Using Maven profiles would help with this so that we can still build most of 
>> the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to install 
>> JDK 9 on all their development machines while it's still in beta.
>> 
>> On 15 March 2017 at 10:07, Ralph Goers <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> I know how to implement the StackWalker code but I don’t quite know how to 
>> get it into the build. The main build needs to keep using Java 7 but of 
>> course the StackWalker stuff needs to be compiled with Java 9. Technically, 
>> I know how I could do that except I have no idea how it would work in 
>> Jenkins. It would also mean that everyone would be required to have Java 9 
>> installed in order to do the build.
>> 
>> An alternate approach would be to have the Java 9 specific classes in a 
>> separate repo with its own build. It would have to be “released” but we 
>> really wouldn’t need or want to release those jars to Maven Central as they 
>> would only be needed in the Log4j build - the classes would be copied into 
>> the Log4j jar.
>> 
>> If any of you know we can set a Jenkins variable to point to the latest Java 
>> 9 version that could solve the problem.
>> 
>> Ralph
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
>> <mailto:log4j-dev-unsubscr...@logging.apache.org>
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
>> <mailto:log4j-dev-h...@logging.apache.org>
>> 
>> 
>> 
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> <http://www.magine.com/>
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Re: Java 9 support

[Ralph Goers]

I can’t change the JDK from JDK 1.7. The rest of the build must be compiled at 
Java 7 since that is what we support. I only want to compile the new classes 
with Java 9.

Using a profile is a very good solution. We would have to run the build twice 
but that would be OK.  I will give that a try.

Ralph

> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9 versions. 
> Since there's no official release of 9 yet, they don't seem to have a "JDK 9 
> (latest)" profile set up on Jenkins yet.
> 
> As for building this, the best solution I've seen so far basically involves a 
> bit of manual configuration using some inline ant tasks or similar overly 
> complicated nonsense which doesn't work well in any IDE to date. It may be 
> worth investigating the existing maven plugin ecosystem and seeing if we need 
> a custom plugin developed for this. Could be a useful feature addition to 
> maven-compiler-plugin, though I haven't tried contributing to Maven yet.
> 
> Using Maven profiles would help with this so that we can still build most of 
> the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to install 
> JDK 9 on all their development machines while it's still in beta.
> 
> On 15 March 2017 at 10:07, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> I know how to implement the StackWalker code but I don’t quite know how to 
> get it into the build. The main build needs to keep using Java 7 but of 
> course the StackWalker stuff needs to be compiled with Java 9. Technically, I 
> know how I could do that except I have no idea how it would work in Jenkins. 
> It would also mean that everyone would be required to have Java 9 installed 
> in order to do the build.
> 
> An alternate approach would be to have the Java 9 specific classes in a 
> separate repo with its own build. It would have to be “released” but we 
> really wouldn’t need or want to release those jars to Maven Central as they 
> would only be needed in the Log4j build - the classes would be copied into 
> the Log4j jar.
> 
> If any of you know we can set a Jenkins variable to point to the latest Java 
> 9 version that could solve the problem.
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
> <mailto:log4j-dev-unsubscr...@logging.apache.org>
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
> <mailto:log4j-dev-h...@logging.apache.org>
> 
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

Java 9 support

[Ralph Goers]

I know how to implement the StackWalker code but I don’t quite know how to get 
it into the build. The main build needs to keep using Java 7 but of course the 
StackWalker stuff needs to be compiled with Java 9. Technically, I know how I 
could do that except I have no idea how it would work in Jenkins. It would also 
mean that everyone would be required to have Java 9 installed in order to do 
the build.

An alternate approach would be to have the Java 9 specific classes in a 
separate repo with its own build. It would have to be “released” but we really 
wouldn’t need or want to release those jars to Maven Central as they would only 
be needed in the Log4j build - the classes would be copied into the Log4j jar.

If any of you know we can set a Jenkins variable to point to the latest Java 9 
version that could solve the problem.

Ralph

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926313#comment-15926313
 ] 

Ralph Goers commented on LOG4J2-1849:
-

Neither is Arizona so I wouldn't see the problem either.

> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests 
> failed:
> {noformat}
> Failed tests:
>   FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119 
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
>   FixedDateFormatTest.testFormatLongCharArrayInt:196 
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but 
> was:<0[2]:00:07,930>
>   FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but 
> was:<2[2]:59:54,091>
>   FixedDateFormatTest.testFormatLong_goingBackInTime:178 
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but 
> was:<2[2]:59:54,072>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924922#comment-15924922
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/14/17 8:27 PM:
--

It would be a direct replacement for the method in ReflectionUtil and 
calcLocation in Log4jLogEvent. 

The MDCFilter benchmark shows that a logging operation that rejects the event 
based on something in the MDC takes about 50 ns. With stackWalkerGetImmediate 
taking over 1 ms it would be an intolerable performance hit to add it in 
AbstractLogger.  At roughly 2 ms though, this isn't much of an impact if you 
are logging to a file or a socket.


was (Author: ralph.go...@dslextreme.com):
It would be a direct replacement for the method in ReflectionUtil and 
calcLocation in Log4jLogEvent.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924922#comment-15924922
 ] 

Ralph Goers commented on LOG4J2-1359:
-

It would be a direct replacement for the method in ReflectionUtil and 
calcLocation in Log4jLogEvent.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15923621#comment-15923621
 ] 

Ralph Goers commented on LOG4J2-1359:
-

I have modified the test that locates the caller class and added a test to 
locate the caller's StackTraceElement using StackWalker using the same 
algorithm Log4j uses. The performance of locating the caller's Class is greatly 
improved from the numbers above and is now faster than using 
Reflection.getCallerClass(). Locating the caller's StackTraceElement is also 
much faster with StackWalker than walking the Throwable. 

I should point out that I tried various methods to locate the caller's class 
and StackTraceElement and finally settled on using the filter method as 
dropWhile() and reduce() were much slower.

{code}
Benchmark  (limit)  
(skip)  Mode  Cnt   Score   Error  Units
StackWalkerGetCallerClass.securityManager  N/A  
   N/A  avgt   20   1.478 ± 0.013  us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate  N/A  
   N/A  avgt   20   1.185 ± 0.012  us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A  
   N/A  avgt   20   2.335 ± 0.017  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1  
   N/A  avgt   20   2.397 ± 0.043  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2  
   N/A  avgt   20   2.424 ± 0.027  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4  
   N/A  avgt   20   2.757 ± 0.028  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6  
   N/A  avgt   20   3.045 ± 0.031  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8  
   N/A  avgt   20   7.804 ± 0.247  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10  
   N/A  avgt   20   7.711 ± 0.062  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12  
   N/A  avgt   20   7.984 ± 0.038  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14  
   N/A  avgt   20   8.537 ± 0.342  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16  
   N/A  avgt   20  13.232 ± 0.142  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1  
   N/A  avgt   20   2.640 ± 0.049  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2  
   N/A  avgt   20   2.514 ± 0.014  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4  
   N/A  avgt   20   2.749 ± 0.179  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6  
   N/A  avgt   20   2.627 ± 0.015  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8  
   N/A  avgt   20   3.368 ± 0.028  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   10  
   N/A  avgt   20   4.156 ± 0.033  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   12  
   N/A  avgt   20   4.857 ± 0.093  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   14  
   N/A  avgt   20   5.461 ± 0.065  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   16  
   N/A  avgt   20   6.104 ± 0.088  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 1  avgt   20  12.613 ± 0.046  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 2  avgt   20  12.705 ± 0.156  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 4  avgt   20  12.484 ± 0.173  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 6  avgt   20  12.275 ± 0.063  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 8  avgt   20  12.552 ± 0.175  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
10  avgt   20  12.349 ± 0.167  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
12  avgt   20  12.564 ± 0.153  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
14  avgt   20  13.128 ± 0.476  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
16  avgt   20  13.246 ± 0.532  us/op
StackWalkerVsExceptionBenchmark.exceptionStackTraceN/A  
   N/A  avgt   20  28.558 ± 0.343  us/op
StackWalkerVsExceptionBenchmark.stackWalkerForEach N/A  
   N/A  avgt   20  12.873 ± 0.171  us/op
StackWalkerVsExceptionBenchmark.stackWalkerForEachRetainClass  N/A  
   N/A  avgt   20  12.828

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15923236#comment-15923236
 ] 

Ralph Goers commented on LOG4J2-1359:
-

https://bugs.openjdk.java.net/browse/JDK-8176593 has been created for the 
performance issue with Throwable.

I am working on the search performance test as the current method is forced to 
consume the whole stack. Also, it was recommended to move the creation of the 
StackWalker out of the test.  There was at least one place where this was done 
in the original tests and I will fix it there as well.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15907673#comment-15907673
 ] 

Ralph Goers commented on LOG4J2-1359:
-

Yes, I posted to the open jdk list and referenced this Jira issue and pointed 
them to my benchmark project. I have not heard anything yet. Of course, it 
could be possible that there is something wrong with the benchmark code.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906837#comment-15906837
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/13/17 5:22 AM:
--

I have copied the benchmarks from the sitepoint article and modified them 
slightly and added benchmarks for java 8. The project is at 
https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass. The results 
on my machine are below. The take-aways are:
1. Walking the Throwable StackTraceElements is significantly faster in Java 8 
than Java 9, so my memory is correct.
2. Using StackWalker to get the StackTraceElements is almost twice as slow as 
walking the Throwable in Java 8.
3. Using StackWalker to search for the caller's class is about twice as slow as 
sun.reflect.Reflection.getCallerClass() was.
4. sun.reflect.Reflection.getCallerClass is about 10 times faster than using 
StackWalker.getCallerClass to obtain the Class object of the immediate caller.

In short it appears that the performance of StackWalker means that we are going 
to want to avoid using it.

Java 8 1.8.0_121:
{code}
BenchmarkMode  Cnt   Score   Error  
Units
ExceptionBenchmark.exceptionStackTrace   avgt   20  19.260 ± 0.385  
us/op
StackWalkerGetCallerClass.exceptionGetImmediate  avgt   20   0.132 ± 0.001  
us/op
StackWalkerGetCallerClass.reflectionSearch   avgt   20   3.703 ± 0.048  
us/op
StackWalkerGetCallerClass.securityManageravgt   20   0.905 ± 0.007  
us/op
{code}

Java 9-ea+160:
{code}
Benchmark  (limit)  
(skip)  Mode  Cnt   Score   Error  Units
StackWalkerGetCallerClass.securityManager  N/A  
   N/A  avgt   20   1.554 ± 0.089  us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate  N/A  
   N/A  avgt   20   1.178 ± 0.013  us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A  
   N/A  avgt   20   5.969 ± 0.055  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1  
   N/A  avgt   20   2.331 ± 0.015  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2  
   N/A  avgt   20   2.384 ± 0.017  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4  
   N/A  avgt   20   2.617 ± 0.021  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6  
   N/A  avgt   20   2.799 ± 0.025  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8  
   N/A  avgt   20   7.082 ± 0.056  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10  
   N/A  avgt   20   7.093 ± 0.122  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12  
   N/A  avgt   20   7.297 ± 0.039  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14  
   N/A  avgt   20   7.477 ± 0.061  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16  
   N/A  avgt   20  11.789 ± 0.079  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1  
   N/A  avgt   20   2.290 ± 0.016  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2  
   N/A  avgt   20   2.253 ± 0.020  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4  
   N/A  avgt   20   2.481 ± 0.082  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6  
   N/A  avgt   20   2.442 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8  
   N/A  avgt   20   3.151 ± 0.036  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   10  
   N/A  avgt   20   3.854 ± 0.040  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   12  
   N/A  avgt   20   4.554 ± 0.055  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   14  
   N/A  avgt   20   5.139 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   16  
   N/A  avgt   20   5.846 ± 0.085  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 1  avgt   20  12.020 ± 0.087  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 2  avgt   20  11.995 ± 0.061  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 4  avgt   20  12.273 ± 0.180  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 6  avgt   20  12.076 ± 0.122  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 8  avgt   20  12.143 ± 0.130  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906837#comment-15906837
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/13/17 5:21 AM:
--

I have copied the benchmarks from the sitepoint article and modified them 
slightly and added benchmarks for java 8. The project is at 
https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass. The results 
on my machine are below. The take-aways are:
1. Walking the Throwable StackTraceElements is significantly faster in Java 8 
than Java 9, so my memory is correct.
2. Using StackWalker to get the StackTraceElements is almost twice as slow as 
walking the Throwable in Java 8.
3. Using StackWalker to search for the caller's class is about twice as slow as 
sun.reflect.Reflection.getCallerClass() was.
4. sun.reflect.Reflection.getCallerClass is about 10 times faster than using 
StackWalker.getCallerClass to obtain the Class object of the immediate caller.

In short it appears that the performance of StackWalker means that we are going 
to want to avoid using it.

Java 8 1.8.0_65-b17:
{code}
BenchmarkMode  Cnt   Score   Error  
Units
ExceptionBenchmark.exceptionStackTrace   avgt   20  19.260 ± 0.385  
us/op
StackWalkerGetCallerClass.exceptionGetImmediate  avgt   20   0.132 ± 0.001  
us/op
StackWalkerGetCallerClass.reflectionSearch   avgt   20   3.703 ± 0.048  
us/op
StackWalkerGetCallerClass.securityManageravgt   20   0.905 ± 0.007  
us/op
{code}

Java 9-ea+160:
{code}
Benchmark  (limit)  
(skip)  Mode  Cnt   Score   Error  Units
StackWalkerGetCallerClass.securityManager  N/A  
   N/A  avgt   20   1.554 ± 0.089  us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate  N/A  
   N/A  avgt   20   1.178 ± 0.013  us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A  
   N/A  avgt   20   5.969 ± 0.055  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1  
   N/A  avgt   20   2.331 ± 0.015  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2  
   N/A  avgt   20   2.384 ± 0.017  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4  
   N/A  avgt   20   2.617 ± 0.021  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6  
   N/A  avgt   20   2.799 ± 0.025  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8  
   N/A  avgt   20   7.082 ± 0.056  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10  
   N/A  avgt   20   7.093 ± 0.122  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12  
   N/A  avgt   20   7.297 ± 0.039  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14  
   N/A  avgt   20   7.477 ± 0.061  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16  
   N/A  avgt   20  11.789 ± 0.079  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1  
   N/A  avgt   20   2.290 ± 0.016  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2  
   N/A  avgt   20   2.253 ± 0.020  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4  
   N/A  avgt   20   2.481 ± 0.082  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6  
   N/A  avgt   20   2.442 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8  
   N/A  avgt   20   3.151 ± 0.036  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   10  
   N/A  avgt   20   3.854 ± 0.040  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   12  
   N/A  avgt   20   4.554 ± 0.055  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   14  
   N/A  avgt   20   5.139 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   16  
   N/A  avgt   20   5.846 ± 0.085  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 1  avgt   20  12.020 ± 0.087  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 2  avgt   20  11.995 ± 0.061  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 4  avgt   20  12.273 ± 0.180  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 6  avgt   20  12.076 ± 0.122  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 8  avgt   20  12.143 ± 0.130  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906837#comment-15906837
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/13/17 5:12 AM:
--

I have copied the benchmarks from the sitepoint article and modified them 
slightly and added benchmarks for java 8. The project is at 
https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass. The results 
on my machine are below. The take-aways are:
1. Walking the Throwable StackTraceElements is significantly faster in Java 8 
than Java 9, so my memory is correct.
2. Using StackWalker to get the StackTraceElements is almost twice as slow as 
walking the Throwable in Java 8.
3. Using StackWalker to search for the caller's class is about twice as slow as 
sun.reflect.Reflection.getCallerClass() was.
4. sun.reflect.Reflection.getCallerClass is about 10 times faster than using 
StackWalker.getCallerClass to obtain the Class object of the immediate caller.

In short it appears that the performance of StackWalker means that we are going 
to want to avoid using it.

Java 8 1.8.0_65-b17:
{code}
BenchmarkMode  Cnt   Score   Error  
Units
ExceptionBenchmark.exceptionStackTrace   avgt   20  19.796 ± 0.405  
us/op
StackWalkerGetCallerClass.exceptionGetImmediate  avgt   20   0.135 ± 0.002  
us/op
StackWalkerGetCallerClass.reflectionSearch   avgt   20   3.844 ± 0.057  
us/op
StackWalkerGetCallerClass.securityManageravgt   20   0.949 ± 0.013  
us/op
{code}

Java 9-ea+160:
{code}
Benchmark  (limit)  
(skip)  Mode  Cnt   Score   Error  Units
StackWalkerGetCallerClass.securityManager  N/A  
   N/A  avgt   20   1.554 ± 0.089  us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate  N/A  
   N/A  avgt   20   1.178 ± 0.013  us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A  
   N/A  avgt   20   5.969 ± 0.055  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1  
   N/A  avgt   20   2.331 ± 0.015  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2  
   N/A  avgt   20   2.384 ± 0.017  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4  
   N/A  avgt   20   2.617 ± 0.021  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6  
   N/A  avgt   20   2.799 ± 0.025  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8  
   N/A  avgt   20   7.082 ± 0.056  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10  
   N/A  avgt   20   7.093 ± 0.122  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12  
   N/A  avgt   20   7.297 ± 0.039  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14  
   N/A  avgt   20   7.477 ± 0.061  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16  
   N/A  avgt   20  11.789 ± 0.079  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1  
   N/A  avgt   20   2.290 ± 0.016  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2  
   N/A  avgt   20   2.253 ± 0.020  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4  
   N/A  avgt   20   2.481 ± 0.082  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6  
   N/A  avgt   20   2.442 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8  
   N/A  avgt   20   3.151 ± 0.036  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   10  
   N/A  avgt   20   3.854 ± 0.040  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   12  
   N/A  avgt   20   4.554 ± 0.055  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   14  
   N/A  avgt   20   5.139 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   16  
   N/A  avgt   20   5.846 ± 0.085  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 1  avgt   20  12.020 ± 0.087  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 2  avgt   20  11.995 ± 0.061  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 4  avgt   20  12.273 ± 0.180  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 6  avgt   20  12.076 ± 0.122  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 8  avgt   20  12.143 ± 0.130  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906837#comment-15906837
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/13/17 5:10 AM:
--

I have copied the benchmarks from the sitepoint article and modified them 
slightly and added benchmarks for java 8. The project is at 
https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass. The results 
on my machine are below. The take-aways are:
1. Walking the Throwable StackTraceElements is significantly faster in Java 8 
than Java 9, so my memory is correct.
2. Using StackWalker to get the StackTraceElements is almost twice as slow as 
walking the Throwable in Java 8.
3. Using StackWalker to search for the caller's class is about twice as slow as 
sun.reflect.Reflection.getCallerClass() was.
4. sun.reflect.Reflection.getCallerClass is about 10 times faster than using 
StackWalker.getCallerClass to obtain the Class object of the immediate caller.

In short it appears that the performance of StackWalker means that we are going 
to want to avoid using it.

Java 8:
{code}
BenchmarkMode  Cnt   Score   Error  
Units
ExceptionBenchmark.exceptionStackTrace   avgt   20  19.796 ± 0.405  
us/op
StackWalkerGetCallerClass.exceptionGetImmediate  avgt   20   0.135 ± 0.002  
us/op
StackWalkerGetCallerClass.reflectionSearch   avgt   20   3.844 ± 0.057  
us/op
StackWalkerGetCallerClass.securityManageravgt   20   0.949 ± 0.013  
us/op
{code}

Java 9-ea+160:
{code}
Benchmark  (limit)  
(skip)  Mode  Cnt   Score   Error  Units
StackWalkerGetCallerClass.securityManager  N/A  
   N/A  avgt   20   1.554 ± 0.089  us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate  N/A  
   N/A  avgt   20   1.178 ± 0.013  us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A  
   N/A  avgt   20   5.969 ± 0.055  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1  
   N/A  avgt   20   2.331 ± 0.015  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2  
   N/A  avgt   20   2.384 ± 0.017  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4  
   N/A  avgt   20   2.617 ± 0.021  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6  
   N/A  avgt   20   2.799 ± 0.025  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8  
   N/A  avgt   20   7.082 ± 0.056  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10  
   N/A  avgt   20   7.093 ± 0.122  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12  
   N/A  avgt   20   7.297 ± 0.039  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14  
   N/A  avgt   20   7.477 ± 0.061  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16  
   N/A  avgt   20  11.789 ± 0.079  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1  
   N/A  avgt   20   2.290 ± 0.016  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2  
   N/A  avgt   20   2.253 ± 0.020  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4  
   N/A  avgt   20   2.481 ± 0.082  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6  
   N/A  avgt   20   2.442 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8  
   N/A  avgt   20   3.151 ± 0.036  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   10  
   N/A  avgt   20   3.854 ± 0.040  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   12  
   N/A  avgt   20   4.554 ± 0.055  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   14  
   N/A  avgt   20   5.139 ± 0.060  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   16  
   N/A  avgt   20   5.846 ± 0.085  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 1  avgt   20  12.020 ± 0.087  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 2  avgt   20  11.995 ± 0.061  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 4  avgt   20  12.273 ± 0.180  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 6  avgt   20  12.076 ± 0.122  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 8  avgt   20  12.143 ± 0.130  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

1. That seems fine to me.
2. Is it possible to do both? I like the idea of annoying the sender but still 
allowing the email to be sent. It would cool if it could even add [list] to the 
start of the subject line.
3. This is the main thing that needs to happen.

Ralph



> On Mar 12, 2017, at 7:49 PM, Matt Sicker <boa...@gmail.com> wrote:
> 
> Some things:
> 
> 1. Archives won't be merged.
> 2. Infra suggests it might be a better idea to have the old email addresses 
> respond with a canned reply saying that the lists have moved over to dev@, 
> though they can set it up all as aliases if we prefer.
> 3. Current subscribers from all dev lists would be automatically subscribed 
> to the combined list.
> 
> So, use aliases or have the old addresses bounce back and inform senders to 
> use the new list?
> 
> On 12 March 2017 at 18:31, Matt Sicker <boa...@gmail.com 
> <mailto:boa...@gmail.com>> wrote:
> Created a request, not sure if it's public: 
> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651 
> <https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651>
> 
> On 12 March 2017 at 17:11, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> Yes,
> 
> If you could send the request to infra I would appreciate it.
> 
> Ralph
> 
>> On Mar 12, 2017, at 1:13 PM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> The vote has been open for 5 days now. Based on the tallies and discussions, 
>> it sounds like we'd like to merge the dev lists but keep the user lists as 
>> is. Shall we move forward with combining them now?
>> 
>> On 10 March 2017 at 12:27, Dominik Psenner <dpsen...@gmail.com 
>> <mailto:dpsen...@gmail.com>> wrote:
>> Total agreement.
>> 
>> On 10 Mar 2017 6:26 p.m., "Ralph Goers" <ralph.go...@dslextreme.com 
>> <mailto:ralph.go...@dslextreme.com>> wrote:
>> This is exactly why we need one dev list. These last two responses dropped 
>> the other lists.  This is a horrible way to have discussions that affect all 
>> the sub projects.
>> 
>> Ralph
>> 
>> 
>>> On Mar 10, 2017, at 9:11 AM, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>> I'd love to see more unified configurations in all the subprojects. Gary 
>>> mentioned that as an idea for log4cxx as that would make it useful for his 
>>> use case where they're using both Java and C++ in various projects.
>>> 
>>> While the programming languages in use here (Java, .NET, PHP, and C++) 
>>> aren't really compatible with each other, having similar architectures and 
>>> plugin systems could help a bit in this regard. Having more inclusive 
>>> conversations about this would be great.
>>> 
>>> On 10 March 2017 at 04:29, Mikael Ståldal <mikael.stal...@magine.com 
>>> <mailto:mikael.stal...@magine.com>> wrote:
>>> I think that a vast majority of our users only uses one of the languages we 
>>> support, and therefore only are interested in one of the subprojects.
>>> 
>>> On Fri, Mar 10, 2017 at 11:23 AM, Dominik Psenner <dpsen...@gmail.com 
>>> <mailto:dpsen...@gmail.com>> wrote:
>>> We had once the discussion that we wanted all Apache Logging projects to 
>>> become very similar in their usage, starting with the same or a very 
>>> similar configuration. Given that we should aim towards one Apache Logging 
>>> specification and several Apache Logging specification implementations in 
>>> the form of Apache Logging subprojects. That means all the devs for all 
>>> subprojects have to talk more. To me this is a good reasons to merge the 
>>> dev mailing lists. Further I don't see why the same use case should not 
>>> apply to the user mailing lists, too. Those mailing lists see very low 
>>> traffic but all of them need a larger audience. Just quoting the last few 
>>> messages of two user mailing lists I follow:
>>> 
>>> log4j-user: the last topic came in a week ago, the topic before that about 
>>> two weeks ago
>>> log4net-user: the last topic came in 24 hours ago and the topic before that 
>>> a month ago
>>> 
>>> Cheers
>>> 
>>> On 2017-03-09 19:24, Ralph Goers wrote:
>>>> We use general as mainly an announcement list for topics that might be of 
>>>> general interest to all logging projects. Generally, these are just 
>>>> release announcem

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906837#comment-15906837
 ] 

Ralph Goers commented on LOG4J2-1359:
-

I have copied the benchmarks from the sitepoint article and modified them 
slightly and added benchmarks for java 8. The project is at 
https://github.com/rgoers/stackwalker-vs-Reflection_getCallerClass. The results 
on my machine are below. The take-aways are:
1. Walking the Throwable StackTraceElements is significantly faster in Java 8 
than Java 9, so my memory is correct.
2. Using StackWalker to get the StackTraceElements is almost twice as slow as 
walking the Throwable in Java 8.
3. Using StackWalker to search for the caller's class is about twice as slow as 
sun.reflect.Reflection.getCallerClass() was.
4. sun.reflect.Reflection.getCallerClass is about 10 times faster than using 
StackWalker.getCallerClass to obtain the Class object of the immediate caller.

In short it appears that the performance of StackWalker means that we are going 
to want to avoid using it.

Java 8:
{code}
BenchmarkMode  Cnt   Score   Error  
Units
ExceptionBenchmark.exceptionStackTrace   avgt   20  19.796 ± 0.405  
us/op
StackWalkerGetCallerClass.exceptionGetImmediate  avgt   20   0.135 ± 0.002  
us/op
StackWalkerGetCallerClass.reflectionSearch   avgt   20   3.844 ± 0.057  
us/op
StackWalkerGetCallerClass.securityManageravgt   20   0.949 ± 0.013  
us/op
{code}

Java 9:
{code}
Benchmark  (limit)  
(skip)  Mode  Cnt   Score   Error  Units
StackWalkerGetCallerClass.securityManager  N/A  
   N/A  avgt   20   1.498 ± 0.014  us/op
StackWalkerGetCallerClass.stackwalkerGetImmediate  N/A  
   N/A  avgt   20   1.124 ± 0.009  us/op
StackWalkerGetCallerClass.stackwalkerSearchN/A  
   N/A  avgt   20   7.083 ± 0.723  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 1  
   N/A  avgt   20   2.640 ± 0.318  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 2  
   N/A  avgt   20   2.635 ± 0.214  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 4  
   N/A  avgt   20   2.779 ± 0.284  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 6  
   N/A  avgt   20   3.051 ± 0.274  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit 8  
   N/A  avgt   20   7.555 ± 0.902  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit10  
   N/A  avgt   20   7.824 ± 0.965  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit12  
   N/A  avgt   20  12.369 ± 6.191  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit14  
   N/A  avgt   20   8.861 ± 2.315  us/op
StackWalkerLimitBenchmark.stackWalkerStreamLimit16  
   N/A  avgt   20  13.643 ± 1.141  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit1  
   N/A  avgt   20   2.754 ± 0.367  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit2  
   N/A  avgt   20   2.669 ± 0.386  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit4  
   N/A  avgt   20   2.722 ± 0.274  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit6  
   N/A  avgt   20   2.812 ± 0.222  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit8  
   N/A  avgt   20   3.555 ± 0.532  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   10  
   N/A  avgt   20   4.259 ± 0.493  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   12  
   N/A  avgt   20   6.149 ± 5.423  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   14  
   N/A  avgt   20   5.707 ± 0.629  us/op
StackWalkerLimitWithEstimatedSizeBenchmark.stackWalkerStreamLimit   16  
   N/A  avgt   20   6.336 ± 0.928  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 1  avgt   20  13.079 ± 0.991  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 2  avgt   20  13.321 ± 1.130  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 4  avgt   20  13.379 ± 1.243  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 6  avgt   20  13.054 ± 1.193  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
 8  avgt   20  13.041 ± 0.764  us/op
StackWalkerSkipBenchmark.stackWalkerStreamSkip N/A  
10  avgt   20  13.359 ± 0.659  us/op

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

Yes,

If you could send the request to infra I would appreciate it.

Ralph

> On Mar 12, 2017, at 1:13 PM, Matt Sicker <boa...@gmail.com> wrote:
> 
> The vote has been open for 5 days now. Based on the tallies and discussions, 
> it sounds like we'd like to merge the dev lists but keep the user lists as 
> is. Shall we move forward with combining them now?
> 
> On 10 March 2017 at 12:27, Dominik Psenner <dpsen...@gmail.com 
> <mailto:dpsen...@gmail.com>> wrote:
> Total agreement.
> 
> On 10 Mar 2017 6:26 p.m., "Ralph Goers" <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> This is exactly why we need one dev list. These last two responses dropped 
> the other lists.  This is a horrible way to have discussions that affect all 
> the sub projects.
> 
> Ralph
> 
> 
>> On Mar 10, 2017, at 9:11 AM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> I'd love to see more unified configurations in all the subprojects. Gary 
>> mentioned that as an idea for log4cxx as that would make it useful for his 
>> use case where they're using both Java and C++ in various projects.
>> 
>> While the programming languages in use here (Java, .NET, PHP, and C++) 
>> aren't really compatible with each other, having similar architectures and 
>> plugin systems could help a bit in this regard. Having more inclusive 
>> conversations about this would be great.
>> 
>> On 10 March 2017 at 04:29, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> I think that a vast majority of our users only uses one of the languages we 
>> support, and therefore only are interested in one of the subprojects.
>> 
>> On Fri, Mar 10, 2017 at 11:23 AM, Dominik Psenner <dpsen...@gmail.com 
>> <mailto:dpsen...@gmail.com>> wrote:
>> We had once the discussion that we wanted all Apache Logging projects to 
>> become very similar in their usage, starting with the same or a very similar 
>> configuration. Given that we should aim towards one Apache Logging 
>> specification and several Apache Logging specification implementations in 
>> the form of Apache Logging subprojects. That means all the devs for all 
>> subprojects have to talk more. To me this is a good reasons to merge the dev 
>> mailing lists. Further I don't see why the same use case should not apply to 
>> the user mailing lists, too. Those mailing lists see very low traffic but 
>> all of them need a larger audience. Just quoting the last few messages of 
>> two user mailing lists I follow:
>> 
>> log4j-user: the last topic came in a week ago, the topic before that about 
>> two weeks ago
>> log4net-user: the last topic came in 24 hours ago and the topic before that 
>> a month ago
>> 
>> Cheers
>> 
>> On 2017-03-09 19:24, Ralph Goers wrote:
>>> We use general as mainly an announcement list for topics that might be of 
>>> general interest to all logging projects. Generally, these are just release 
>>> announcements.
>>> 
>>> Ralph
>>> 
>>>> On Mar 9, 2017, at 10:37 AM, Matt Sicker <boa...@gmail.com 
>>>> <mailto:boa...@gmail.com>> wrote:
>>>> 
>>>> Yeah, I agree that the user lists can remain separate as it doesn't cause 
>>>> any issues currently. The main idea here is whether we should merge the 
>>>> dev lists into one, or if we need a common dev list for all devs to 
>>>> subscribe to (general@ doesn't sound appropriate, but I don't know what 
>>>> that list is for).
>>>> 
>>>> On 9 March 2017 at 10:26, Ralph Goers <ralph.go...@dslextreme.com 
>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> You should note that while we consider all votes only PMC votes are 
>>>> “binding”. I don’t think that changes much however.
>>>> 
>>>> From a PMC perspective I have to say that keeping the user’s lists 
>>>> separate isn’t likely to be an issue as most of the things that would need 
>>>> to be discussed would be on a dev list anyway.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Mar 9, 2017, at 2:45 AM, Dominik Psenner <dpsen...@gmail.com 
>>>>> <mailto:dpsen...@gmail.com>> wrote:
>>>>> 
>>>>> The votes are way too scattered over the different mailing lists so that 
>>>>> I didn't even find my own vote. ;-) Therefore I'm trying to summarize the 
>>>>>

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906252#comment-15906252
 ] 

Ralph Goers commented on LOG4J2-1359:
-

Let's see if I can help.  First, I suggest you read 
https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/. Notice 
that when StackWalker::forEach is used to get the StackTraceElement containing 
the file name and line number it is actually slower than walking the Throwable, 
which is in contrast to Reflection.getCallerClass() where we get a performance 
boost. But also notice that the cost decreases with the number of stack frames 
that have to be retrieved. So the openjdk devs recommend using StackWalker's 
getCallerClass method. Of course, the only way to do that is to have the call 
be in the first Log4j method that is called. Then we would have to pass the 
retrieved StackFrame instead of the FQCN. IOW, we would not lazily resolve the 
location information. I have my doubts that can be done without unacceptable 
performance consequences.

Worse, I did some gross testing and it seemed that walking the Throwable was 
slower in Java 9 than in Java 8. However, the openjdk devs believe I did 
something wrong.  The only way to know is to test it.  I plan to do just that 
by starting with https://github.com/pingtimeout/stack-walker-benchmark and then 
creating a Java 8 version and a Java 9 version.

So yes, we can defer walking the stack but the cost of retrieving location 
information will probably be worse than it is pre-Java 9.

For a reference to the core-libs discussion see the thread that starts with 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040826.html.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906196#comment-15906196
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/11/17 12:59 PM:
---

I need to get back to this...

Java 9 provides multi-version support - we can provide one version of a class 
for pre-java9 and another for java9, but it requires the build be done with 
java 9, which I am reluctant to do.

Also, the openjdk devs recommend that the stack frame of the caller be 
captured, not walking the stack as we do now. But that would be a huge change 
and could negatively impact the performance of every logging call even if 
logging is disabled.


was (Author: ralph.go...@dslextreme.com):
I need to get back to this...

Java 9 provides multi-version support - we can provide one version of a class 
for pre-java9 and another for java9, but it requires the build be done with 
java 9, which I am reluctant to do.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906196#comment-15906196
 ] 

Ralph Goers commented on LOG4J2-1359:
-

I need to get back to this...

Java 9 provides multi-version support - we can provide one version of a class 
for pre-java9 and another for java9, but it requires the build be done with 
java 9, which I am reluctant to do.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

This is exactly why we need one dev list. These last two responses dropped the 
other lists.  This is a horrible way to have discussions that affect all the 
sub projects.

Ralph


> On Mar 10, 2017, at 9:11 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> I'd love to see more unified configurations in all the subprojects. Gary 
> mentioned that as an idea for log4cxx as that would make it useful for his 
> use case where they're using both Java and C++ in various projects.
> 
> While the programming languages in use here (Java, .NET, PHP, and C++) aren't 
> really compatible with each other, having similar architectures and plugin 
> systems could help a bit in this regard. Having more inclusive conversations 
> about this would be great.
> 
> On 10 March 2017 at 04:29, Mikael Ståldal <mikael.stal...@magine.com 
> <mailto:mikael.stal...@magine.com>> wrote:
> I think that a vast majority of our users only uses one of the languages we 
> support, and therefore only are interested in one of the subprojects.
> 
> On Fri, Mar 10, 2017 at 11:23 AM, Dominik Psenner <dpsen...@gmail.com 
> <mailto:dpsen...@gmail.com>> wrote:
> We had once the discussion that we wanted all Apache Logging projects to 
> become very similar in their usage, starting with the same or a very similar 
> configuration. Given that we should aim towards one Apache Logging 
> specification and several Apache Logging specification implementations in the 
> form of Apache Logging subprojects. That means all the devs for all 
> subprojects have to talk more. To me this is a good reasons to merge the dev 
> mailing lists. Further I don't see why the same use case should not apply to 
> the user mailing lists, too. Those mailing lists see very low traffic but all 
> of them need a larger audience. Just quoting the last few messages of two 
> user mailing lists I follow:
> 
> log4j-user: the last topic came in a week ago, the topic before that about 
> two weeks ago
> log4net-user: the last topic came in 24 hours ago and the topic before that a 
> month ago
> 
> Cheers
> 
> On 2017-03-09 19:24, Ralph Goers wrote:
>> We use general as mainly an announcement list for topics that might be of 
>> general interest to all logging projects. Generally, these are just release 
>> announcements.
>> 
>> Ralph
>> 
>>> On Mar 9, 2017, at 10:37 AM, Matt Sicker <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> 
>>> Yeah, I agree that the user lists can remain separate as it doesn't cause 
>>> any issues currently. The main idea here is whether we should merge the dev 
>>> lists into one, or if we need a common dev list for all devs to subscribe 
>>> to (general@ doesn't sound appropriate, but I don't know what that list is 
>>> for).
>>> 
>>> On 9 March 2017 at 10:26, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> You should note that while we consider all votes only PMC votes are 
>>> “binding”. I don’t think that changes much however.
>>> 
>>> From a PMC perspective I have to say that keeping the user’s lists separate 
>>> isn’t likely to be an issue as most of the things that would need to be 
>>> discussed would be on a dev list anyway.
>>> 
>>> Ralph
>>> 
>>>> On Mar 9, 2017, at 2:45 AM, Dominik Psenner <dpsen...@gmail.com 
>>>> <mailto:dpsen...@gmail.com>> wrote:
>>>> 
>>>> The votes are way too scattered over the different mailing lists so that I 
>>>> didn't even find my own vote. ;-) Therefore I'm trying to summarize the 
>>>> current state of the vote:
>>>> 
>>>> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
>>>> d...@logging.apache.org <mailto:d...@logging.apache.org>
>>>> Matt Sicker: +1
>>>> Ralph Goers: +1
>>>> Stefan Bodewig: +1
>>>> Sven Rautenverg: -1
>>>> Thorsten Schöning: -0
>>>> Ivan Habunek: -0
>>>> Dominik Psenner: +1
>>>> Remko Popma: +1
>>>> Mikael Ståldal: +0
>>>> 
>>>> Totals so far:
>>>> +1: 5
>>>> +0: 1
>>>> -0: 2
>>>> -1: 1
>>>> 
>>>> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
>>>> u...@logging.apache.org <mailto:u...@logging.apache.org>
>>>> 
>>>> Matt Sicker: -1
>>>> Ralph Goers: +1
>>>> Stefan Bodewig: -1
>>>> Sven Rautenverg: -1
>>>> Thors

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

We use general as mainly an announcement list for topics that might be of 
general interest to all logging projects. Generally, these are just release 
announcements.

Ralph

> On Mar 9, 2017, at 10:37 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> Yeah, I agree that the user lists can remain separate as it doesn't cause any 
> issues currently. The main idea here is whether we should merge the dev lists 
> into one, or if we need a common dev list for all devs to subscribe to 
> (general@ doesn't sound appropriate, but I don't know what that list is for).
> 
> On 9 March 2017 at 10:26, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> You should note that while we consider all votes only PMC votes are 
> “binding”. I don’t think that changes much however.
> 
> From a PMC perspective I have to say that keeping the user’s lists separate 
> isn’t likely to be an issue as most of the things that would need to be 
> discussed would be on a dev list anyway.
> 
> Ralph
> 
>> On Mar 9, 2017, at 2:45 AM, Dominik Psenner <dpsen...@gmail.com 
>> <mailto:dpsen...@gmail.com>> wrote:
>> 
>> The votes are way too scattered over the different mailing lists so that I 
>> didn't even find my own vote. ;-) Therefore I'm trying to summarize the 
>> current state of the vote:
>> 
>> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
>> d...@logging.apache.org <mailto:d...@logging.apache.org>
>> Matt Sicker: +1
>> Ralph Goers: +1
>> Stefan Bodewig: +1
>> Sven Rautenverg: -1
>> Thorsten Schöning: -0
>> Ivan Habunek: -0
>> Dominik Psenner: +1
>> Remko Popma: +1
>> Mikael Ståldal: +0
>> 
>> Totals so far:
>> +1: 5
>> +0: 1
>> -0: 2
>> -1: 1
>> 
>> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
>> u...@logging.apache.org <mailto:u...@logging.apache.org>
>> 
>> Matt Sicker: -1
>> Ralph Goers: +1
>> Stefan Bodewig: -1
>> Sven Rautenverg: -1
>> Thorsten Schöning: -0
>> Ivan Habunek: -0
>> Dominik Psenner: +1
>> Remko Popma: +1
>> Mikael Ståldal: -1
>> 
>> Totals so far:
>> +1: 3
>> +0: 0
>> -0: 2
>> -1: 4
>> Sorry to anyone who's vote is missing.
>> 
>> On 2017-03-08 05:20, Matt Sicker wrote:
>>> I may be missing some mailing lists considering I just subscribed to half 
>>> of them less than five minutes ago.
>>> 
>>> This is a vote to merge the various Apache Logging Services mailing lists. 
>>> The proposal is to combine them as follows:
>>> 
>>> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
>>> d...@logging.apache.org <mailto:d...@logging.apache.org>
>>> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
>>> u...@logging.apache.org <mailto:u...@logging.apache.org>
>>> 
>>> commits@ and private@ remain the same as before.
>>> 
>>> The proposal would also suggest that the old emails become aliases for the 
>>> combined email names so as not to lose any future emails. To distinguish 
>>> between projects, a subject tag can be added such as:
>>> 
>>> [java]
>>> [net]
>>> [cxx]
>>> [php]
>>> 
>>> Though I wouldn't think such a tag is required, though it should help in 
>>> gaining the attention of the appropriate audience.
>>> 
>>> Voting:
>>> 
>>> +1: Yes, combine the mailing lists!
>>> +0: Go ahead, don't care that much.
>>> -0: Don't like it, but not vetoing it.
>>> -1: No, don't do that! I have a better idea!
>>> 
>>> This vote follows the same "lazy consensus" (at least 3 +1 binding, no 
>>> -1/vetoes) we use for general releases and whatnot. The vote will be open 
>>> for at least 72 hours.
>>> 
>>> -- 
>>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
>> 
> 
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>

[Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

You should note that while we consider all votes only PMC votes are “binding”. 
I don’t think that changes much however.

From a PMC perspective I have to say that keeping the user’s lists separate 
isn’t likely to be an issue as most of the things that would need to be 
discussed would be on a dev list anyway.

Ralph

> On Mar 9, 2017, at 2:45 AM, Dominik Psenner <dpsen...@gmail.com> wrote:
> 
> The votes are way too scattered over the different mailing lists so that I 
> didn't even find my own vote. ;-) Therefore I'm trying to summarize the 
> current state of the vote:
> 
> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
> d...@logging.apache.org <mailto:d...@logging.apache.org>
> Matt Sicker: +1
> Ralph Goers: +1
> Stefan Bodewig: +1
> Sven Rautenverg: -1
> Thorsten Schöning: -0
> Ivan Habunek: -0
> Dominik Psenner: +1
> Remko Popma: +1
> Mikael Ståldal: +0
> 
> Totals so far:
> +1: 5
> +0: 1
> -0: 2
> -1: 1
> 
> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
> u...@logging.apache.org <mailto:u...@logging.apache.org>
> 
> Matt Sicker: -1
> Ralph Goers: +1
> Stefan Bodewig: -1
> Sven Rautenverg: -1
> Thorsten Schöning: -0
> Ivan Habunek: -0
> Dominik Psenner: +1
> Remko Popma: +1
> Mikael Ståldal: -1
> 
> Totals so far:
> +1: 3
> +0: 0
> -0: 2
> -1: 4
> Sorry to anyone who's vote is missing.
> 
> On 2017-03-08 05:20, Matt Sicker wrote:
>> I may be missing some mailing lists considering I just subscribed to half of 
>> them less than five minutes ago.
>> 
>> This is a vote to merge the various Apache Logging Services mailing lists. 
>> The proposal is to combine them as follows:
>> 
>> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
>> d...@logging.apache.org <mailto:d...@logging.apache.org>
>> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
>> u...@logging.apache.org <mailto:u...@logging.apache.org>
>> 
>> commits@ and private@ remain the same as before.
>> 
>> The proposal would also suggest that the old emails become aliases for the 
>> combined email names so as not to lose any future emails. To distinguish 
>> between projects, a subject tag can be added such as:
>> 
>> [java]
>> [net]
>> [cxx]
>> [php]
>> 
>> Though I wouldn't think such a tag is required, though it should help in 
>> gaining the attention of the appropriate audience.
>> 
>> Voting:
>> 
>> +1: Yes, combine the mailing lists!
>> +0: Go ahead, don't care that much.
>> -0: Don't like it, but not vetoing it.
>> -1: No, don't do that! I have a better idea!
>> 
>> This vote follows the same "lazy consensus" (at least 3 +1 binding, no 
>> -1/vetoes) we use for general releases and whatnot. The vote will be open 
>> for at least 72 hours.
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 

Re: Roadmap for log4j-api-scala 11.0

[Ralph Goers]

The distribution zip and tarball contain all the artifacts that are being 
released - i.e. the jars.  The Log4j distribution includes all the jars from 
all the sub projects. Obviously, the Scala distribution will only contain the 
Scala jars.  So the assembly xml file needs to be modified to only include what 
is being released.  The distribution source and zip are what the ASF actually 
considers to be the release.  The source distribution should just be an exact 
copy of the source tree. It needs to have the NOTICE.txt, LICENSE.txt and 
should have a README.md and any other text files you want people to be able 
review when looking at the repo on GitHub. You can copy most of these files 
from the Log4j root directory. The NOTICE.txt file should be modified to remove 
the things that don’t apply to the Scala project (I believe that is the last 3 
items).

Ralph

> On Mar 9, 2017, at 8:59 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> I am a bit lost here.
> 
> On Thu, Mar 9, 2017 at 4:56 PM, Mikael Ståldal <mikael.stal...@magine.com 
> <mailto:mikael.stal...@magine.com>> wrote:
> Change to what?
> 
> On Thu, Mar 9, 2017 at 4:32 PM, Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>> wrote:
> The instructions for what will be in the zip and tar balls will have to 
> change.
> 
> Ralph
> 
>> On Mar 9, 2017, at 8:01 AM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> 
>> If you have time before the weekend, you could try copying over the 
>> log4j-distribution section from the main pom files. The "release" maven 
>> profile should activate it I believe, so you should see the generated zips 
>> and tarballs.
>> 
>> On 9 March 2017 at 03:01, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> Nice! Tell me if there is anything I can do to help out.
>> 
>> On Thu, Mar 9, 2017 at 5:07 AM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> We've established that this will need to be released before we can 
>> officially remove the equivalent modules from the main log4j repository (and 
>> release cycle). Since the artifacts are no longer tied directly to 
>> log4j-api/core, we've also agreed that it makes sense to version it 
>> separately as well. The latest releases are 2.8.1, so the next version 
>> number proposed is 11.0. I dig the Spinal Tap reference, so let's go for it.
>> 
>> I know that the source and binary distributions assemblies need to be ported 
>> over in order to properly create a release candidate. The site is pretty 
>> bare bones, and Ralph has mentioned that he should be able to take care of 
>> integrating it into the main site. Otherwise, I'll be ready to start a 
>> release candidate hopefully by this weekend.
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
>> 
>> 
>> 
>> -- 
>>  
>> 
>> Mikael Ståldal
>> Senior software developer 
>> 
>> Magine TV
>> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
>> <http://www.magine.com/>
>> 
>> Privileged and/or Confidential Information may be contained in this message. 
>> If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not 
>> copy or deliver this message to anyone. In such case, 
>> you should destroy this message and kindly notify the sender by reply email. 
>>   
>> 
>> 
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> 
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> <http://www.magine.com/>
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> <http://www.magine.com/>
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Re: Roadmap for log4j-api-scala 11.0

[Ralph Goers]

The instructions for what will be in the zip and tar balls will have to change.

Ralph

> On Mar 9, 2017, at 8:01 AM, Matt Sicker  wrote:
> 
> If you have time before the weekend, you could try copying over the 
> log4j-distribution section from the main pom files. The "release" maven 
> profile should activate it I believe, so you should see the generated zips 
> and tarballs.
> 
> On 9 March 2017 at 03:01, Mikael Ståldal  > wrote:
> Nice! Tell me if there is anything I can do to help out.
> 
> On Thu, Mar 9, 2017 at 5:07 AM, Matt Sicker  > wrote:
> We've established that this will need to be released before we can officially 
> remove the equivalent modules from the main log4j repository (and release 
> cycle). Since the artifacts are no longer tied directly to log4j-api/core, 
> we've also agreed that it makes sense to version it separately as well. The 
> latest releases are 2.8.1, so the next version number proposed is 11.0. I dig 
> the Spinal Tap reference, so let's go for it.
> 
> I know that the source and binary distributions assemblies need to be ported 
> over in order to properly create a release candidate. The site is pretty bare 
> bones, and Ralph has mentioned that he should be able to take care of 
> integrating it into the main site. Otherwise, I'll be ready to start a 
> release candidate hopefully by this weekend.
> 
> -- 
> Matt Sicker >
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com 
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> 
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  
> 
> 
> 
> -- 
> Matt Sicker >

[jira] [Commented] (LOG4J2-1841) Problems with consequences after LOG4J2-248

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903224#comment-15903224
 ] 

Ralph Goers commented on LOG4J2-1841:
-

Yes, this sounds pretty serous to me too.

> Problems with consequences after LOG4J2-248
> ---
>
> Key: LOG4J2-1841
> URL: https://issues.apache.org/jira/browse/LOG4J2-1841
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Boot
>Affects Versions: 2.8
> Environment: Linux, Tomcat, WebApps
>Reporter: Seweryn Habdank-Wojewodzki
>
> Situation till Log4j v. 2.5 (including it):
> 1. One instance of embedded Jetty (programatically started) WITHOUT 
> definition of the log4j.configurationFile variable.
> 2. WAR deployed on within this concrete instance of the embedded Jetty.
> 3. WAR internally contains own log4j2.xml file. So every Log4j instance, 
> which is global for the WebApp, but local for the Jetty, will search and use 
> configuration in own class path.
> Works in the way that every Web-App got own Log4j configuration and will 
> operate according to own definitions (appenders, layouts, loggers).
> In the Log4j v. 2.6 and later in the same setup we are observing the 
> following:
> Log4j in the applications are reporting problem that config file (log4j2.xml) 
> is not visible. Thus we got message, that Log4j will switch to backup mode 
> which will write only ERRORs in the console.
> We debuged that issue and found that change made in:
> https://issues.apache.org/jira/browse/LOG4J2-248
> seems to be the main reason.
> We cannot asses if this change was made only with respect to some PMD warning 
> or it has as well some design considerations in background.
> The consequence is that Web Server instance shall define 
> log4j.configurationFile variable, but also it means ALL WebApps will use one 
> single configuration, what makes definitely problem, as all WebApps providers 
> must agree on ONE configuration including appenders configuration, message 
> Layout and so on.
> Consider this report and provide solution (or workaround) or maybe just 
> reasonable comment for the given system setup, please :-).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: [VOTE] Combine the project user and dev mailing lists into user@ and dev@

[Ralph Goers]

+1

Note that generally a -1 is a veto only on code commits. On everything else it 
just means you are against the proposal. However, we generally strive for 
consensus so great weight is given to binding votes that are opposed.

Ralph

> On Mar 7, 2017, at 9:23 PM, Matt Sicker  wrote:
> 
> This is my +1.
> 
> If this is the incorrect voting format and we need to do a 2/3 majority 
> instead, please veto this and let me know. This situation is not spelled out 
> in the bylaws.
> 
> On 7 March 2017 at 22:20, Matt Sicker  > wrote:
> I may be missing some mailing lists considering I just subscribed to half of 
> them less than five minutes ago.
> 
> This is a vote to merge the various Apache Logging Services mailing lists. 
> The proposal is to combine them as follows:
> 
> log4j-dev@, log4php-dev@, log4net-dev@, log4cxx-dev@ -> 
> d...@logging.apache.org 
> log4j-user@, log4php-user@, log4net-user@, log4cxx-user@, general@ -> 
> u...@logging.apache.org 
> 
> commits@ and private@ remain the same as before.
> 
> The proposal would also suggest that the old emails become aliases for the 
> combined email names so as not to lose any future emails. To distinguish 
> between projects, a subject tag can be added such as:
> 
> [java]
> [net]
> [cxx]
> [php]
> 
> Though I wouldn't think such a tag is required, though it should help in 
> gaining the attention of the appropriate audience.
> 
> Voting:
> 
> +1: Yes, combine the mailing lists!
> +0: Go ahead, don't care that much.
> -0: Don't like it, but not vetoing it.
> -1: No, don't do that! I have a better idea!
> 
> This vote follows the same "lazy consensus" (at least 3 +1 binding, no 
> -1/vetoes) we use for general releases and whatnot. The vote will be open for 
> at least 72 hours.
> 
> -- 
> Matt Sicker >
> 
> 
> 
> -- 
> Matt Sicker >

Re: Roadmap for 2.8.1

[Ralph Goers]

Yes. Scala should be released asap and the site manually modified to point to 
it. We would then modify the log4j source to permanently point there.

Ralph

> On Mar 7, 2017, at 10:09 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> Ralph pointed out that we can't make a release of the main repo without the 
> scala modules until there is a release of the scala modules on their own. 
> Otherwise, there'd be a regression in the main repo by removing modules that 
> were there before.
> 
> On 7 March 2017 at 10:54, Remko Popma <remko.po...@gmail.com 
> <mailto:remko.po...@gmail.com>> wrote:
> No objection from me to release log4j-scala. 
> 
> Do you have a versioning scheme that lets log4j-scala and log4j upgrade 
> independently?
> 
> Sent from my iPhone
> 
> On Mar 8, 2017, at 1:42, Mikael Ståldal <mikael.stal...@magine.com 
> <mailto:mikael.stal...@magine.com>> wrote:
> 
>> Can we release log4j-scala now? Or to we have to wait for the next release 
>> of main repo with Scala modules removed? Should we remove the Scala modules 
>> from main repo now?
>> 
>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <boa...@gmail.com 
>> <mailto:boa...@gmail.com>> wrote:
>> The Scala language versions is already done the same standard way everyone 
>> implements Scala libraries (hence the strange naming scheme we already 
>> have). I'd imagine that the versions can be completely decoupled by 
>> specifying a minimum Log4j API version it requires (though should generally 
>> be whatever the latest was at release) and bumping its own version as new 
>> features or bugfixes are added. I'd like to see that follow semantic 
>> versioning properly, too.
>> 
>> On 3 March 2017 at 06:15, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> I guess the idea is that releases of Log4j 2 and log4j-scala should be 
>> independent in both ways, right?
>> 
>> I think I have coordination between log4j-scala and Scala language covered 
>> already.
>> 
>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <remko.po...@gmail.com 
>> <mailto:remko.po...@gmail.com>> wrote:
>> Mikael, you probably need to plan your versioning scheme to handle any 
>> combination of the following:
>> * log4j 2 releases: do you want to do a release for the log4j-scala modules 
>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that 
>> once they are decoupled, the log4j-scala modules won't be released 
>> automatically with log4j anymore, someone needs to do the work for a 
>> log4j-scala release separately. 
>> * Scala releases: how do you want to sync up with Scala language versions? 
>> (I guess include major Scala version in the log4j-scala module version)
>> * log4j-scala module versions: enhancements to these modules, independent of 
>> the above 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.stal...@magine.com 
>> <mailto:mikael.stal...@magine.com>> wrote:
>> 
>>> I would like to keep package and artifact names, and bump version to 11.0.
>>> 
>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boa...@gmail.com 
>>> <mailto:boa...@gmail.com>> wrote:
>>> If you change artifact ids, it's generally a good idea to change packages, 
>>> too. I've had issues in the past with Feign for instance because they 
>>> changed groupId/artifactId at one point but kept the same API, so I had two 
>>> copies on the classpath until I found out there was a duplicate and 
>>> excluded them (though admittedly not a problem in OSGi environments :P).
>>> 
>>> On 1 March 2017 at 07:47, Ralph Goers <ralph.go...@dslextreme.com 
>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>> You can do that, but that will probably confuse users too. I would suggest 
>>> changing the artifactId and then start at either 1.0 or 2.0.
>>> 
>>> Ralph
>>> 
>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mikael.stal...@magine.com 
>>>> <mailto:mikael.stal...@magine.com>> wrote:
>>>> 
>>>> OK, but then at least we have to start with a version > 2.8.
>>>> 
>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.go...@dslextreme.com 
>>>> <mailto:ralph.go...@dslextreme.com>> wrote:
>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>> 
>>>> Ralph
>>>> 
>>>> On Mar 1,

Re: Performance page for next release.

[Ralph Goers]

I am most concerned with the two things that have been most impacted - the 
FileAppenderBenchmark and the MarkerFilterBenchmark.

Ralph

> On Mar 3, 2017, at 2:20 PM, Remko Popma <remko.po...@gmail.com> wrote:
> 
> Yes but only the JMH benchmarks. Is that acceptable?
> 
> The latency tests and the non-JMH Async Logger tests are too involved... 
> 
> One thing to bear in mind, we carefully documented the versions of the 
> libraries we compared against with our benchmark results. The fact that newer 
> versions of these libraries are now available does not invalidate those 
> results. It just means that our performance page is not up to date with the 
> latest version. We can try to stay up to date but in my opinion it's okay to 
> let some time elapse if we're busy with other things. 
> 
> Anyway, if just the JMH tests are ok, I'll try to do this in the next month. 
> 
> Remko 
> 
> Sent from my iPhone
> 
>> On Mar 3, 2017, at 17:24, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> 
>> Remko, 
>> 
>> Would it be possible for you to update the performance page for the next 
>> release? I am uncomfortable with some of the results because I know they 
>> have changed since 2.6.  
>> 
>> Ralph
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 
> 



-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1836) API Version is incorrect

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers closed LOG4J2-1836.
---

> API Version is incorrect
> 
>
> Key: LOG4J2-1836
> URL: https://issues.apache.org/jira/browse/LOG4J2-1836
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core
>Affects Versions: 2.6, 2.6.1, 2.6.2, 2.7, 2.8, 2.8.1
>    Reporter: Ralph Goers
> Fix For: 2.8.2
>
>
> ProviderUtil in Log4j API is supposed to list the versions of the API that 
> are all compatible with each other from a binding point of view. These 
> versions are not supposed to be modified with each Log4j release but only 
> when a change to the API is made so that implementations can know whether 
> they are compatible with the API.
> Likewise, each implemenation (such as Log4j core) is supposed to declare what 
> version of the API it requires. Again, this is not implemented with each 
> release but only when core is modified to require changes in the API.
> The API changed significantly in releases prior to 2.6 but these values were 
> never modified. Since 2.6 very little has changed in the API. 
> To fix this issue the API needs to say the only compatible version is 2.6 and 
> log4j-core must declare that it requires version 2.6.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-1836) API Version is incorrect

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-1836.
-
   Resolution: Fixed
Fix Version/s: 2.8.2

> API Version is incorrect
> 
>
> Key: LOG4J2-1836
> URL: https://issues.apache.org/jira/browse/LOG4J2-1836
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core
>Affects Versions: 2.6, 2.6.1, 2.6.2, 2.7, 2.8, 2.8.1
>    Reporter: Ralph Goers
> Fix For: 2.8.2
>
>
> ProviderUtil in Log4j API is supposed to list the versions of the API that 
> are all compatible with each other from a binding point of view. These 
> versions are not supposed to be modified with each Log4j release but only 
> when a change to the API is made so that implementations can know whether 
> they are compatible with the API.
> Likewise, each implemenation (such as Log4j core) is supposed to declare what 
> version of the API it requires. Again, this is not implemented with each 
> release but only when core is modified to require changes in the API.
> The API changed significantly in releases prior to 2.6 but these values were 
> never modified. Since 2.6 very little has changed in the API. 
> To fix this issue the API needs to say the only compatible version is 2.6 and 
> log4j-core must declare that it requires version 2.6.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Log4j-provider.properties API version

[Ralph Goers]

I created LOG4J2-1836 to address this.

Ralph

> On Mar 3, 2017, at 12:01 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> Likewise, I suspect that ProviderUtil should only list 2.6.0 as a compatible 
> version since the implementation must be at that level or higher.
> 
> Ralph
> 
>> On Mar 3, 2017, at 11:58 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> 
>> The Log4jAPIVersion in log4j-provider.properties in log4j-core says it 
>> supports the 2.1.0 API.  Is that actually correct? I suspect that if you try 
>> to use the log4j 2.1 API jar with the log4j 2.8.1 core jar there will be 
>> problems.  Doesn’t Log4j core require a Log4j API jar that is at least at 
>> the 2.6 version?
>> 
>> Ralph
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 
> 



-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1836) API Version is incorrect

[Ralph Goers (JIRA)]

Ralph Goers created LOG4J2-1836:
---

 Summary: API Version is incorrect
 Key: LOG4J2-1836
 URL: https://issues.apache.org/jira/browse/LOG4J2-1836
 Project: Log4j 2
  Issue Type: Bug
  Components: API, Core
Affects Versions: 2.8.1, 2.8, 2.7, 2.6.2, 2.6.1, 2.6
Reporter: Ralph Goers


ProviderUtil in Log4j API is supposed to list the versions of the API that are 
all compatible with each other from a binding point of view. These versions are 
not supposed to be modified with each Log4j release but only when a change to 
the API is made so that implementations can know whether they are compatible 
with the API.

Likewise, each implemenation (such as Log4j core) is supposed to declare what 
version of the API it requires. Again, this is not implemented with each 
release but only when core is modified to require changes in the API.

The API changed significantly in releases prior to 2.6 but these values were 
never modified. Since 2.6 very little has changed in the API. 

To fix this issue the API needs to say the only compatible version is 2.6 and 
log4j-core must declare that it requires version 2.6.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1381) Documentation for LoggerNameLevelRewritePolicy is wrong

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1381:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Documentation for LoggerNameLevelRewritePolicy is wrong
> ---
>
> Key: LOG4J2-1381
> URL: https://issues.apache.org/jira/browse/LOG4J2-1381
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
> Fix For: 2.8.2
>
>
> The docs for [LoggerNameLevelRewritePolicy 
> |http://logging.apache.org/log4j/2.x/manual/appenders.html#RewriteAppender] 
> are wrong:
> * property {{loggerName}} (both in the parameter table and in the example 
> configuration): looking at the code, this should be {{logger}} instead.
> * property {{LevelPair}} (in the parameter table) should be {{KeyValuePair}} 
> instead. The example configuration is correct here.
>  (Or should the code be modified to match the docs instead?)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1229) Error creating logger

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1229:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Error creating logger
> -
>
> Key: LOG4J2-1229
> URL: https://issues.apache.org/jira/browse/LOG4J2-1229
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.4.1, 2.5
> Environment: Ubuntu 14.04
>Reporter: Dmitriy Dumanskiy
> Fix For: 2.8.2
>
>
> I have a lot of VMs where everything is fine. But on some of them  I get 
> below stack trace. I have a feeling it somehow related with access rights. 
> Here is stack trace :
> {code}
> 2015-12-21 08:05:06,036 AsyncLogger-1 ERROR Unable to invoke factory method 
> in class class org.apache.logging.log4j.core.appender.RollingFileAppender for 
> element RollingFile. java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:136)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:813)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:753)
> at 
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.createAppender(RoutingAppender.java:152)
> at 
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.getControl(RoutingAppender.java:136)
> at 
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.append(RoutingAppender.java:110)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:152)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:125)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:116)
> at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:390)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:378)
> at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:362)
> at 
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:79)
> at 
> org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:385)
> at 
> org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:103)
> at 
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:43)
> at 
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:28)
> at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: ManagerFactory 
> [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory@346629f5]
>  unable to create manager for [/data//1_v4.csv] with data 
> [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$FactoryData@6d48f4b0]
> at 
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:73)
> at 
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:61)
> at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.getFileManager(RollingFileManager.java:79)
> at 
> org.apache.logging.log4j.core.appender.RollingFileAppender.createAppender(RollingFileAppender.java:193)
> ... 25 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1498) [Java 9] fix dependency on old JDK versioning scheme

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1498:

Fix Version/s: (was: 2.8.1)
   2.8.2

> [Java 9] fix dependency on old JDK versioning scheme
> 
>
> Key: LOG4J2-1498
> URL: https://issues.apache.org/jira/browse/LOG4J2-1498
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Layouts
>Affects Versions: 2.6.2
>Reporter: Remko Popma
> Fix For: 2.8.2
>
>
> AbstractStringLayout currently has this code:
> {code}
> // LOG4J2-1151: If the built-in JDK 8 encoders are available we should 
> use them.
> private static boolean isPreJava8() {
> final String version = System.getProperty("java.version");
> final String[] parts = version.split("\\.");
> try {
> final int major = Integer.parseInt(parts[1]);
> return major < 8;
> } catch (final Exception ex) {
> return true;
> }
> }
> {code}
> With Java 9, this will not work correctly. (Impact is very small, but 
> anyway...)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-915) Wrong timestamp of filename when SizeBasedTriggering and TimeBasedTrigger used simultaniously with RollingFileAppender

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-915:
---
Fix Version/s: (was: 2.8.1)
   2.8.2

> Wrong timestamp of filename when SizeBasedTriggering and TimeBasedTrigger 
> used simultaniously with RollingFileAppender
> --
>
> Key: LOG4J2-915
> URL: https://issues.apache.org/jira/browse/LOG4J2-915
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1
>Reporter: Daniel Stuckert
> Fix For: 2.8.2
>
> Attachments: JIRA_915.diff
>
>
> When using the SizedBasedTrigger and TimeBasedTrigger simultaniously the 
> timestamp for the filename generated by the SizeBasedTrigger is not the 
> current time but the next timestamp calculated by the TimeBasedTrigger.
> The bug can be reproduced with the sample configuration in the manual.
> Likely cause of the problem is that the TimeBasedTrigger sets the time of the 
> next rollover and the SizeBasedTrigger uses the set time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1576) Better automated backwards compatibility checking

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1576:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Better automated backwards compatibility checking
> -
>
> Key: LOG4J2-1576
> URL: https://issues.apache.org/jira/browse/LOG4J2-1576
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Remko Popma
> Fix For: 2.8.2
>
>
> I have trouble running Clirr on a machine that only has Java 8 (ran into the 
> "Invalid byte tag in constant pool" problem) so I started to look at 
> alternatives. These two seem promising:
> * [javacmp|https://siom79.github.io/japicmp/]
> * [Revapi|http://revapi.org/]
> h4. Revapi Configuration
> More docs are [here|http://revapi.org/getting-started.html]. Very quick:
> $\{root}/pom.xml
> {code}
> 
>   org.revapi
>   revapi-maven-plugin
>   0.5.1
>   
> 
>   org.revapi
>   revapi-java
>   0.10.1
> 
>   
>   
>   
>   
> 
>   api-check
>   check
> 
>   
> 
> {code}
> $\{root}/log4j-api/pom.xml and $\{root}/log4j-core/pom.xml
> {code}
> 
>   org.revapi
>   revapi-maven-plugin
>   0.5.1
>   
> 
>   ${project.groupId}:${project.artifactId}:2.6.2
> 
> 
>   
> ${project.groupId}:${project.artifactId}:${project.version}
> 
>   
>   
> 
>   api-check
>   check
> 
>   
> 
> {code}
> $\{root}/log4j-bom/pom.xml
> {code}
> 
> org.revapi
> revapi-maven-plugin
> 0.5.1
> 
>   
> org.revapi
> revapi-java
> 0.10.1
>   
> 
> 
> {code}
> h4. Revapi Maven Plugin
> Docs are [here|http://revapi.org/modules/revapi-maven-plugin/index.html]. 
> After running {{mvn revapi:check}}, it finds a lot. There is a mechanism to 
> suppress findings in a fine-grained way.
> {noformat}
> [ERROR] java.class.removed: class 
> org.apache.logging.log4j.core.async.DaemonThreadFactory: Class was removed.
> [ERROR] java.field.constantValueChanged: field 
> org.apache.logging.log4j.core.layout.PatternLayout.TTCC_CONVERSION_PATTERN: 
> Constant field changed value from '%r [%t] %p %c %x - %m%n' to '%r [%t] %p %c 
> %notEmpty{%x }- %m%n'.
> [ERROR] java.field.removed: field 
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.LOGGER:
>  Field removed from class.
> [ERROR] java.field.removed: field 
> org.apache.logging.log4j.core.util.Constants.UTF_8: Field removed from class.
> [ERROR] java.generics.formalTypeParameterAdded: class 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder: A new formal 
> type parameter added to element: 'B extends 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.generics.formalTypeParameterAdded: method 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder 
> org.apache.logging.log4j.core.appender.ConsoleAppender::newBuilder(): A new 
> formal type parameter added to element: 'B extends 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.method.addedToInterface: method boolean 
> org.apache.logging.log4j.core.LifeCycle::stop(long, 
> java.util.concurrent.TimeUnit): Method was added to an interface.
> [ERROR] java.method.addedToInterface: method java.lang.String 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::toXmlConfiguration(): 
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.core.LoggerContext 
> org.apache.logging.log4j.core.config.Configuration::getLoggerContext(): 
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::setDestination(java.lang.String):
>  Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.spi.ContextData 
> org.apache.logging.log4j.core.LogEvent::getContextData(): Method was added to 
> an interface.
> [ERROR] java.method.addedToInterface: method void 
> org.apache.logging.log4j.core.config.builder.api.Configuration

[jira] [Updated] (LOG4J2-1341) (GC) Avoid allocating temporary objects in Pattern Converters for PatternLayout

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1341:

Fix Version/s: (was: 2.8.1)
   2.8.2

> (GC) Avoid allocating temporary objects in Pattern Converters for 
> PatternLayout
> ---
>
> Key: LOG4J2-1341
> URL: https://issues.apache.org/jira/browse/LOG4J2-1341
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Pattern Converters
>Affects Versions: 2.5
>Reporter: Remko Popma
> Fix For: 2.8.2
>
>
> *To do*
> The following pattern converters can be modified to avoid creating temporary 
> objects in their {{format}} method:
> * -all done-
> *Investigate*
> The following pattern converters may be difficult to modify since they rely 
> on JDK components that create temporary objects:
> * (-) ExtendedThrowablePatternConverter
> * (-) RegexReplacementConverter
> * (-) RootThrowablePatternConverter
> * (-) ThrowablePatternConverter
> * (-) UuidPatternConverter
> * (-) ClassNamePatternConverter (location information requires creating 
> StackTraceElements)
> * (-) FileLocationPatternConverter
> * (-) FullLocationPatternConverter
> * (-) LineLocationPatternConverter
> * (-) MethodLocationPatternConverter
> *Done*
> The following pattern converters already do not allocate temporary objects in 
> their format method:
> * (/) AbstractStyleNameConverter (since 2.8)
> * (/) HighlightConverter (since 2.7, thanks to Richard Zschech)
> * (/) StyleConverter (since 2.7, thanks to Richard Zschech)
> * (/) DatePatternConverter
> * (/) EqualsIgnoreCaseReplacementConverter (since 2.8)
> * (/) EqualsReplacementConverter (since 2.8)
> * (/) EncodingPatternConverter (since 2.8)
> * (/) IntegerPatternConverter (since 2.8)
> * (/) LevelPatternConverter
> * (/) LineSeparatorPatternConverter
> * (/) LiteralPatternConverter (unless literal contains '${')
> * (/) LoggerPatternConverter
> * (/) MapPatternConverter (since 2.8 - note that constructing a MapMessage is 
> not garbage-free)
> * (/) MarkerPatternConverter (since 2.8)
> * (/) MarkerSimpleNamePatternConverter
> * (/) MaxLengthConverter (since 2.8)
> * (/) MdcPatternConverter (since 2.7)
> * (/) MessagePatternConverter (unless a Jansi or HTML renderer is configured 
> or message has '${' lookups)
> * (/) NamePatternConverter
> * (/) NanoTimePatternConverter
> * (/) NdcPatternConverter (since 2.8 ContextStack implementations implement 
> the StringBuilderFormattable interface - note that the ThreadContext stack is 
> cloned for each log event and is not garbage-free)
> * (/) RelativeTimePatternConverter (since 2.8)
> * (/) SequenceNumberPatternConverter (since 2.8)
> * (/) ThreadIdPatternConverter
> * (/) ThreadNamePatternConverter
> * (/) ThreadPriorityPatternConverter
> * (/) VariablesNotEmptyReplacementConverter (since 2.8)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1812) Improve error message when log4j 2 configuration file not found

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1812:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Improve error message when log4j 2 configuration file not found
> ---
>
> Key: LOG4J2-1812
> URL: https://issues.apache.org/jira/browse/LOG4J2-1812
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7, 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.2
>
>
> When configuration fails because no Log4j 2 configuration file is found, the 
> following message is logged to the console at ERROR level: 
> {code}
> No log4j2 configuration file found. Using default configuration: logging only 
> errors to the console.
> {code}
> We should be able to improve this. One idea is to add this:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only 
> errors to the console. Set system property 
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show 
> Log4j2 internal initialization logging.
> {code}
> Another idea is to dump the contents of the StatusLogger ring buffer to the 
> console.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1086) SizeBasedTriggeringPolicy is not working properly

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1086:

Fix Version/s: (was: 2.8.1)
   2.8.2

> SizeBasedTriggeringPolicy is not working properly
> -
>
> Key: LOG4J2-1086
> URL: https://issues.apache.org/jira/browse/LOG4J2-1086
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.3, 2.4.1
> Environment: Windows 7 OS Websphere 8.5.5.6
>Reporter: Sharat
>Assignee: Ralph Goers
>Priority: Minor
>  Labels: features
> Fix For: 2.8.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> {code}
> 
> 
>  
>  filePattern="/logs/test-%i.log"> 
>
>   %d %-5p %class{36} (%M:%L) 
> -%msg%xEx%n 
>
>
>   
>   
>
>
>
>
>
>
>   
>   
>  
> 
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1477) @NonNull support (for @NonNullByDefault or similar)

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1477:

Fix Version/s: (was: 2.8.1)
   2.8.2

> @NonNull support (for @NonNullByDefault or similar)
> ---
>
> Key: LOG4J2-1477
> URL: https://issues.apache.org/jira/browse/LOG4J2-1477
> Project: Log4j 2
>  Issue Type: Wish
>  Components: API
>Affects Versions: 2.6.2
> Environment: any
>Reporter: Bojan Antonović
> Fix For: 2.8.2
>
>
> Eclipse (and other tools) offer non-null checks by annotation processing.
> One of the possibilities to enable this is to add the annotation 
> @org.eclipse.jdt.annotation.NonNullByDefault in your package-info.java file.
> Example:
> @org.eclipse.jdt.annotation.NonNullByDefault
> package foo;
> A frequent problem is reported when using a logger:
> private static final Logger LOGGER = LogManager.getLogger(Bla.class);
> for which Eclipse says:
> Null type safety (type annotations): The expression of type 'Logger' needs 
> unchecked conversion to conform to '@NonNull Logger' Bla.java  (...)
> This can by bypassed by putting a @SuppressWarnings("null") over the 
> expression, but this has to be done in every class, and may be the *only* 
> line of code with this workaround.
> Problems:
> - There are other annotations for non-null (javax.annotation.Nonnull) and 
> many other frameworks, like the Checker Framework.
> - I don't want to be a judge which one to choose.
> - Deeper support may require a dependency on Java 8.
> - If you want to do it framework wide, this can be a huge task.
> - As some tools are not mature (IMHO), it will need experiments.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1246) PatternLayout %date conversion pattern should render time zone designator for ISO-ISO8601

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1246:

Fix Version/s: (was: 2.8.1)
   2.8.2

> PatternLayout %date conversion pattern should render time zone designator for 
> ISO-ISO8601
> -
>
> Key: LOG4J2-1246
> URL: https://issues.apache.org/jira/browse/LOG4J2-1246
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.4.1, 2.5
>Reporter: Daniel Marcotte
> Fix For: 2.8.2
>
>
> Hi there!
> There might be a small issue with the Pattern Converters regarding Timezone 
> management: 
> http://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout
> Right now, these patterns:
> * {{"%d\{ISO8601_BASIC\}}}
> * {{%d\{ISO8601_BASIC\}\{UTC\}}}
> Give the same results:
> * {{20160104T204256,048}}
> * {{20160104T204256,048}}
> However, with a deeper look at the ISO-8601 standards, the second one with 
> {{"\{UTC\}"}} should properly add the Timezone at the end of the timestamp.
> Reference: https://en.wikipedia.org/wiki/ISO_8601#Times
> {quote}
> *UTC*
> If the time is in UTC, add a Z directly after the time without a space. Z is 
> the zone designator for the zero UTC offset. "09:30 UTC" is therefore 
> represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or 
> "144515Z".
> UTC time is also known as 'Zulu' time, since 'Zulu' is the NATO phonetic 
> alphabet word for 'Z'.
> *Examples*
> Z
> ±hh:mm
> ±hhmm
> ±hh
> {quote}
> As of ISO-8601, the results should be one of the following (configurable?):
> * {{20160104T204256,048Z}}
> * {{20160104T204256,048+00:00}}
> * {{20160104T204256,048+}}
> * {{20160104T204256,048+00}}
> Another reference: 
> http://stackoverflow.com/questions/833102/wheres-the-datetime-z-format-specifier



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1261) Replace usage of deprecated LMAX Disruptor APIs

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1261:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Replace usage of deprecated LMAX Disruptor APIs
> ---
>
> Key: LOG4J2-1261
> URL: https://issues.apache.org/jira/browse/LOG4J2-1261
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Remko Popma
> Fix For: 2.8.2
>
> Attachments: LOG4J2_1261_changes_to_use_new_Disruptor_API.patch
>
>
> We get the following compiler warning due to our usage for deprecated LMAX 
> Disruptor APIs:
> {noformat}
> [WARN] 
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[88,20]
>  [deprecation] 
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in 
> Disruptor has been deprecated
> [WARN]   where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[88,20]
>  [deprecation] 
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in 
> Disruptor has been deprecated
> [WARN]   where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[93,17]
>  [deprecation] handleExceptionsWith(ExceptionHandler) in Disruptor 
> has been deprecated
> [WARN]   where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[165,20]
>  [deprecation] 
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in 
> Disruptor has been deprecated
> [WARN]   where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[165,20]
>  [deprecation] 
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in 
> Disruptor has been deprecated
> [WARN]   where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[169,17]
>  [deprecation] handleExceptionsWith(ExceptionHandler) in Disruptor 
> has been deprecated
> [WARN]   where T is a type-variable:
> T extends Object declared in class Disruptor
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1395) Add "direct" option to ConsoleAppender for increased performance

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1395:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Add "direct" option to ConsoleAppender for increased performance
> 
>
> Key: LOG4J2-1395
> URL: https://issues.apache.org/jira/browse/LOG4J2-1395
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.5, 2.6, 2.6.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.8.2
>
> Attachments: app.zip, ggregory-hardware.txt
>
>
> The ConsoleAppender is much slower than the FileAppender.
> It would be nice to improve the performance of the ConsoleAppender.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1410) Add new LiteTimeoutBlockingWaitStrategy for Async Loggers

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1410:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Add new LiteTimeoutBlockingWaitStrategy for Async Loggers
> -
>
> Key: LOG4J2-1410
> URL: https://issues.apache.org/jira/browse/LOG4J2-1410
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.2
>
>
> Discussion on the Mechanical Sympathy mailing list [brought to 
> light|https://groups.google.com/d/msg/mechanical-sympathy/klefjRqlpQE/0wpjUkE9AwAJ]
>  an interesting aspect of using the Disruptor under light loads: if the 
> background thread has no work to do because the queue is empty, it will 
> block, and await a signal that more work has been put onto the queue.
> Sending this signal is done in the application thread when a new log event is 
> enqueued. This is done by obtaining the shared Lock and calling 
> Condition.signal(). Now, if multiple application threads try to do this 
> signalling at the same time, one of them will be suspended by the OS. This 
> may be costly, and unnecessary, because waking up the background thread twice 
> is wasteful.
> The Disruptor contains the 
> [LiteBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/LiteBlockingWaitStrategy.java]
>  for this.
> Log4j uses the 
> [TimeoutBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/TimeoutBlockingWaitStrategy.java]
>  by default since we had a report of a deadlock with BlockingWaitStrategy on 
> Solaris (LOG4J2-1221).
> This ticket proposes to create a custom wait strategy that combines 
> LiteBlockingWaitStrategy with TimeoutBlockingWaitStrategy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1603) Redo hashCode() and equals() methods in org.apache.logging.log4j.core.net.ssl classes.

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1603:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Redo hashCode() and equals() methods in org.apache.logging.log4j.core.net.ssl 
> classes.
> --
>
> Key: LOG4J2-1603
> URL: https://issues.apache.org/jira/browse/LOG4J2-1603
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8.2
>
>
> We have a few FindBugs warnings about {{hashCode()}} and {{equals(Object)}} 
> methods in the package {{org.apache.logging.log4j.core.net.ssl}} classes.
> The first problem is that not all classes implement these method where some 
> of the code expects it to like an {{equals()}} method calling another 
> {{equals()}} method but there is not one and the behavior of 
> {{Object.equals()}} kicks in.
> This change make it obvious where there are still issues: the behavior 
> described above will only happen when the code path ends up in a JRE class 
> which itself depends on {{Object.equals()}}, so you still get a FindBugs 
> warning about that but it is no longer a warning about a class in our code. 
> We can revisit how to best implement {{equals()}} for those classes later.
> It is possible that the warning is a false positive since the JRE could be 
> using a subclass of the class FindBugs complains about.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1521) StringIndexOutOfBoundsException thrown when rolling logs

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1521:

Fix Version/s: (was: 2.8.1)
   2.8.2

> StringIndexOutOfBoundsException thrown when rolling logs
> 
>
> Key: LOG4J2-1521
> URL: https://issues.apache.org/jira/browse/LOG4J2-1521
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
> Environment: Windows 10 Pro 64-bit (10.0, Build 14393) 
> (14393.rs1_release.160715-1616)
> java version "1.8.0_73"
> Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
>Reporter: Johno Crawford
> Fix For: 2.8.2
>
>
> When prototyping with log4j I ran into an issue with rolling log files.
> {noformat}
> 2016-08-16 08:26:25,304 main ERROR An exception occurred processing Appender 
> TABLE1-appender java.lang.StringIndexOutOfBoundsException: String index out 
> of range: -1
>   at 
> java.lang.AbstractStringBuilder.setCharAt(AbstractStringBuilder.java:380)
>   at java.lang.StringBuilder.setCharAt(StringBuilder.java:76)
>   at 
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter$PaddedNumberField.appendTo(FastDatePrinter.java:895)
>   at 
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter$PaddedNumberField.appendTo(FastDatePrinter.java:880)
>   at 
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter.applyRules(FastDatePrinter.java:479)
>   at 
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter.format(FastDatePrinter.java:454)
>   at 
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter.format(FastDatePrinter.java:442)
>   at 
> org.apache.logging.log4j.core.util.datetime.FastDateFormat.format(FastDateFormat.java:427)
>   at 
> org.apache.logging.log4j.core.pattern.DatePatternConverter$PatternFormatter.formatToBuffer(DatePatternConverter.java:70)
>   at 
> org.apache.logging.log4j.core.pattern.DatePatternConverter.formatWithoutAllocation(DatePatternConverter.java:259)
>   at 
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:251)
>   at 
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:238)
>   at 
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:290)
>   at 
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:299)
>   at 
> org.apache.logging.log4j.core.appender.rolling.PatternProcessor.formatFileName(PatternProcessor.java:248)
>   at 
> org.apache.logging.log4j.core.appender.rolling.PatternProcessor.formatFileName(PatternProcessor.java:233)
>   at 
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.purgeAscending(DefaultRolloverStrategy.java:323)
>   at 
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.purge(DefaultRolloverStrategy.java:306)
>   at 
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.rollover(DefaultRolloverStrategy.java:524)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:220)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:155)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:150)
>   at 
> org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:85)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:155)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:128)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:119)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:390)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:375)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:349)
>   at 
> org.apache.logging.lo

[jira] [Updated] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1760:

Fix Version/s: (was: 2.8.1)
   2.8.2

> AsyncAppender with LinkedTransferQueue.offer()
> --
>
> Key: LOG4J2-1760
> URL: https://issues.apache.org/jira/browse/LOG4J2-1760
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.7
>Reporter: Addison Walterson
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.8.2
>
>
> I suggest that the AsyncAppender can use a LinkedTransferQueue for which 
> offer() is used to enqueue messages because tryTransfer() only succeeds if 
> the receiving thread waits for a message which means that the queue has 
> length 0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1013) Log4j2 Main Arguments Lookup by name doesn't work

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers updated LOG4J2-1013:

Fix Version/s: (was: 2.8.1)
   2.8.2

> Log4j2 Main Arguments Lookup by name doesn't work
> -
>
> Key: LOG4J2-1013
> URL: https://issues.apache.org/jira/browse/LOG4J2-1013
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core, Lookups
>Affects Versions: 2.2
> Environment: Windows 7 x64 Ultimate and Java 8U31 x64. Project 
> created using Eclipse.
>Reporter: Ioan Mihaila
>Priority: Critical
> Fix For: 2.8.2
>
> Attachments: 
> LOG4J2_1013_select_underlying_StrLookup_before_stripping_off_potential_default_values.patch
>
>
> Accessing Main Arguments by using index based look up works : $\{main:0}
> Accessing Main Arguments by using name based look up doesn't work : 
> $\{main:--file}
> When trying to access by name it doesn't retrieve the argument but retrieves 
> "-file".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org