date:20170202

[jira] [Updated] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()

2017-02-02 Thread Gary Gregory (JIRA)


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

Gary Gregory updated LOG4J2-1807:
-
Summary: [core] Add and implement LogEvent.toImmutable()  (was: [core] Add 
and implement LogEvent.asImmutable())

> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {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

Re: RollingAppenderSizeTest failures

2017-02-02 Thread Apache

OK. I will have to fire up a Windows VM and test it as it doesn’t fail on my 
Mac or in Linux.

Ralph

> On Feb 2, 2017, at 7:17 PM, Remko Popma  wrote:
> 
> I'm seeing the same thing on my Windows pc. 
> 
> Sent from my iPhone
> 
> On Feb 3, 2017, at 10:01, Gary Gregory  > wrote:
> 
>> I get:
>> 
>> Tests in error:
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
>> target\rolli...
>> 
>> Tests run: 1879, Failures: 0, Errors: 10, Skipped: 30
>> 
>> using:
>> 
>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
>> 2015-11-10T08:41:47-08:00)
>> Maven home: C:\Java\apache-maven-3.3.9\bin\..
>> Java version: 1.7.0_80, vendor: Oracle Corporation
>> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
>> 
>> Anyone else?
>> 
>> -- 
>> 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: RollingAppenderSizeTest failures

2017-02-02 Thread Remko Popma

I'm seeing the same thing on my Windows pc. 

Sent from my iPhone

> On Feb 3, 2017, at 10:01, Gary Gregory  wrote:
> 
> I get:
> 
> Tests in error:
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem 
> target\rolli...
> 
> Tests run: 1879, Failures: 0, Errors: 10, Skipped: 30
> 
> using:
> 
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T08:41:47-08:00)
> Maven home: C:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> 
> Anyone else?
> 
> -- 
> 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] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma commented on LOG4J2-1807:
-

Yes that should be fine. The LogEvent interface regularly changes when we add 
more features. 

(Perhaps we should put a javadoc note on that interface to that effect.)

> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {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

Re: RollingAppenderSizeTest failures

2017-02-02 Thread Gary Gregory

Git bisec says:

*a0f4f4db5e8e88e56eaa148d81c2ba91df606e2a is the first bad commit*
commit a0f4f4db5e8e88e56eaa148d81c2ba91df606e2a
Author: Ralph Goers 
Date:   Tue Jan 24 14:48:34 2017 -0700

Use an ExecutorService to verify shutdown of the async threads

:04 04 ad3cb23efafeaab2f7e934e249c8e53ff7dcf86f
056bbb158f43602fb2a4e8c74c5bcff29e5e5fe5 M  log4j-core
bisect run success


I'm not sure what needs to be reverted or changed but there you have it (I
have to get back to a customer issue now).

If you want to do this yourself you can run:

git bisect start HEAD log4j-2.7

(I was not sure how far back to go so I picked 2.7. It turns out I could
have used 2.8. Then in a script called ..\run.cmd I have:

call mvn clean
call mvn -DskipTests -pl log4j-api install
mvn -Dtest=RollingAppenderSizeTest -pl log4j-core test

and run:

git bisect run ..\run.cmd

which gives you the output at the start of this message.

Gary


On Thu, Feb 2, 2017 at 5:01 PM, Gary Gregory  wrote:

> I get:
>
> Tests in error:
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>   RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
> target\rolli...
>
> Tests run: 1879, Failures: 0, Errors: 10, Skipped: 30
>
> using:
>
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: C:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
>
> Anyone else?
>
> --
> 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

[jira] [Updated] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()

2017-02-02 Thread Gary Gregory (JIRA)


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

Gary Gregory updated LOG4J2-1807:
-
Attachment: logging-log4j2.patch

> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {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

RollingAppenderSizeTest failures

2017-02-02 Thread Gary Gregory

I get:

Tests in error:
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...
  RollingAppenderSizeTest.cleanup:115->cleanFolder:189 ╗ FileSystem
target\rolli...

Tests run: 1879, Failures: 0, Errors: 10, Skipped: 30

using:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T08:41:47-08:00)
Maven home: C:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

Anyone else?

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

Jenkins build became unstable: Log4j 2.x #2645

2017-02-02 Thread Apache Jenkins Server

See 


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

[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()

2017-02-02 Thread Gary Gregory (JIRA)


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

Gary Gregory commented on LOG4J2-1807:
--

Sure, we can do {{toImmutable()}}.

Are we ok with adding a method to the Core LogEvent interface?

I have a patch coming today.

> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {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

Re: SyslogAppender parameter name change

2017-02-02 Thread Gary Gregory

Darn, I apologize for that one.

Gary

On Thu, Feb 2, 2017 at 4:09 PM, Remko Popma  wrote:

> Sorry for that and thanks for letting us know!
>
> I wonder if parameter names can have aliases so we can support both the
> old and the new name without causing users inconvenience. If possible we
> should address this for 2.8.1.
>
> Remko
>
> Sent from my iPhone
>
> On Feb 3, 2017, at 4:13, Sam Beroz  wrote:
>
> The reconnectionDelayMillis parameter was renamed
> to reconnectDelayMillis. After updating to release 2.8 I noticed that I was
> getting the following error:
>
> ERROR Syslog contains an invalid element or attribute
> "reconnectionDelayMillis"
>
>
> It appears that change was part of this commit:
>
> commit ed828be67a23ee3513cafc9d2fd0ff16a26c7013
> Author: Gary Gregory 
> Date:   Mon Nov 14 15:11:47 2016 -0800
>
> [LOG4J2-1709]
>
> Add a Builder to SyslogAppender and deprecate
> SyslogAppender.createAppender().
>
>
>
> The documentation (https://logging.apache.org/lo
> g4j/2.x/manual/appenders.html#SyslogAppender) still has the parameter
> listed as "reconnectionDelayMillis" but the code is now obviously looking
> for "reconnectDelayMillis". I'm going to change my config to use the new
> name, but I thought I'd point out the disconnect as it had me confused for
> a bit. Thanks - Sam
>
>


-- 
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: SyslogAppender parameter name change

2017-02-02 Thread Remko Popma

Sorry for that and thanks for letting us know!

I wonder if parameter names can have aliases so we can support both the old and 
the new name without causing users inconvenience. If possible we should address 
this for 2.8.1. 

Remko 

Sent from my iPhone

> On Feb 3, 2017, at 4:13, Sam Beroz  wrote:
> 
> The reconnectionDelayMillis parameter was renamed to reconnectDelayMillis. 
> After updating to release 2.8 I noticed that I was getting the following 
> error:
> 
> ERROR Syslog contains an invalid element or attribute 
> "reconnectionDelayMillis"
> 
> It appears that change was part of this commit:
> 
> commit ed828be67a23ee3513cafc9d2fd0ff16a26c7013
> Author: Gary Gregory 
> Date:   Mon Nov 14 15:11:47 2016 -0800
> 
> [LOG4J2-1709]
> 
> Add a Builder to SyslogAppender and deprecate
> SyslogAppender.createAppender().
> 
> 
> The documentation 
> (https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender) 
> still has the parameter listed as "reconnectionDelayMillis" but the code is 
> now obviously looking for "reconnectDelayMillis". I'm going to change my 
> config to use the new name, but I thought I'd point out the disconnect as it 
> had me confused for a bit. Thanks - Sam

[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma commented on LOG4J2-1807:
-

Should it be {{toImmutable}} since the convention is that {{asSomething}} 
provides a "something" _view_ that changes when the underlying value is 
changed, whereas {{toSomething}} transforms an object  into something 
independent from the original value?

> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {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-1807) [core] Add and implement LogEvent.asImmutable()

2017-02-02 Thread Gary Gregory (JIRA)


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

Gary Gregory updated LOG4J2-1807:
-
Description: 
[core] Add and implement LogEvent.asImmutable()
{code:java}
/**
 * Returns an immutable version of this log event, which MAY BE a copy of 
this event.
 *  
 * @return an immutable version of this log event
 */
LogEvent asImmutable();
{code}

  was:
[core] Add and implement LogEvent.asImmutable()
{code:java}
/**
 * Returns an immutable version of this log event, which MAY BE a copy if 
this event.
 *  
 * @return an immutable version of this log event
 */
LogEvent asImmutable();
{code}


> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
>  * Returns an immutable version of this log event, which MAY BE a copy of 
> this event.
>  *  
>  * @return an immutable version of this log event
>  */
> LogEvent asImmutable();
> {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] [Created] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()

2017-02-02 Thread Gary Gregory (JIRA)

Gary Gregory created LOG4J2-1807:


 Summary: [core] Add and implement LogEvent.asImmutable()
 Key: LOG4J2-1807
 URL: https://issues.apache.org/jira/browse/LOG4J2-1807
 Project: Log4j 2
  Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory


[core] Add and implement LogEvent.asImmutable()
{code:java}
/**
 * Returns an immutable version of this log event, which MAY BE a copy if 
this event.
 *  
 * @return an immutable version of this log event
 */
LogEvent asImmutable();
{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

Re: Use of the manual change log

2017-02-02 Thread Mikael Ståldal

It is a bit confusing that "update" in changes.xml translates to "Changes"
in release notes. Why is it so?

On Jan 28, 2017 1:16 AM, "Remko Popma"  wrote:

> When you say change, you mean update? (I thought there were only 4
> categories: add, fix, update and delete.)
>
>  I don't mind using the update category for improvements in the future,
> just that the difference between new feature and improvement is sometimes
> not clear-cut.
>
> Sent from my iPhone
>
> On Jan 28, 2017, at 3:58, Apache  wrote:
>
> I wouldn’t call making GelfLayout independent of Jackson a new feature
> since it wouldn’t affect the external behavior other than the dependencies.
> I would have marked it as a change. I would have done the same with all the
> “Avoid allocating temporary objects” issues. The way I look at it, is if it
> is something that is really new, such as an additional parameter or new
> external or internal component, then it belongs as a new feature. If it
> fixes a reported bug then it is a fix. Pretty much everything else is a
> change.
>
> Ralph
>
> On Jan 27, 2017, at 11:20 AM, Matt Sicker  wrote:
>
> I was looking over the changelog for 2.8 and noticed some things in the
> "Fixed Bugs" section that sound like they'd be more appropriate in the "New
> features" section such as:
>
> * Added Builder classes (e.g., GelfLayout)
> * Make GelfLayout independent of Jackson (that is totally a new feature!)
> * Added CleanableThreadContextMap (not only is it a new feature, it's a
> new log4j-api class!)
> * Any new options added to plugins (e.g., disableAnsi in PatternLayout)
> * Configurable JVM shutdown hook timeout
> * Garbage-free changes (unless you consider garbage objects to be a bug
> now?)
>
> Also, this isn't such a big deal, but when we do more than two dependency
> version upgrades within a single release, it might be clearer to combine
> them into a single ticket (e.g., Jackson makes a bit more releases than we
> do, so we usually end up with multiple Jackson upgrade tickets in the
> changelog which isn't very helpful to a user).
>
> --
> Matt Sicker 
>
>
>

SyslogAppender parameter name change

2017-02-02 Thread Sam Beroz

The reconnectionDelayMillis parameter was renamed to reconnectDelayMillis.
After updating to release 2.8 I noticed that I was getting the following
error:

ERROR Syslog contains an invalid element or attribute
"reconnectionDelayMillis"


It appears that change was part of this commit:

commit ed828be67a23ee3513cafc9d2fd0ff16a26c7013
Author: Gary Gregory 
Date:   Mon Nov 14 15:11:47 2016 -0800

[LOG4J2-1709]

Add a Builder to SyslogAppender and deprecate
SyslogAppender.createAppender().



The documentation (https://logging.apache.org/lo
g4j/2.x/manual/appenders.html#SyslogAppender) still has the parameter
listed as "reconnectionDelayMillis" but the code is now obviously looking
for "reconnectDelayMillis". I'm going to change my config to use the new
name, but I thought I'd point out the disconnect as it had me confused for
a bit. Thanks - Sam

Re: Opinions or guidelines on what each logging level is for?

2017-02-02 Thread Apache

Here it is. As I recall I borrowed this from several sources but I cannot 
recall what they were.

Message levels
Log4j defines five levels of logging messages, ranging from TRACE to FATAL. The 
guidelines for their use are very vague and in the grand UNIX tradition mix 
severity of the message with its granularity. The following summary defines the 
basic rules on when to use a specific level, who the target audience is and how 
any message of the specified level will be interpreted.
Note that all events with level INFO or higher present an API-like contract of 
the system from the integration point-of-view: if they change, third-party 
systems such as monitoring may need to be updated to work correctly with the 
new system release. The message text on these levels should be understandable 
to people with networking and systems administration background, so any 
language assuming knowledge of programming in general, or Java in particular, 
should be avoided if at all possible.
Messages on DEBUG and higher present are part of interface contract with 
support entities, e.g. if they are changed operator and troubleshooting 
manuals, as well as knowledge-base systems may need to be updated to correctly 
interpret the information conveyed. On the DEBUG level, messages may assume a 
slight level of familiarity with general programming concepts. Terminology 
specific to any programming language should be avoided if possible.
FATAL
This should generally only be used for recording a failure that prevents the 
system starting, i.e. the system is completely unusable. It is also possible 
that errors during operation will also render the system unusable, but 
typically these will be identified as java.lang.Error instances (such as an 
OutOfMemoryError), and hence we will not likely catch them, since catching 
Throwable should only be done in very special cases.
ERROR
Records that something went wrong, i.e. some sort of failure occurred, and 
either:
The system was not able to recover from the error, or
The system was able to recover, but at the expense of losing some information 
or failing to honour a request.
This should be immediately brought to the attention of an operator. Or to 
rephrase it, if your error does not need immediate investigation by an 
operator, then it isn’t an error.
To permit monitoring tools to watch the log files for ERRORs and WARNings is 
crucial that:
These get logged
Sufficient information is provided to identify the cause of the problem
The logging is done in a standard way, which lends itself to automatic 
monitoring.
For example, if the error is caused by a configuration failure, the 
configuration filename should be provided (especially if you have more than one 
file, yuck), as well as the property causing the problem.
WARN
A WARN message records that something in the system was not as expected. It is 
not an error, i.e. it is not preventing correct operation of the system or any 
part of it, but it is still an indicator that something is wrong with the 
system that the operator should be aware of, and may wish to investigate. This 
level may be used for errors in user-supplied information.
INFO
INFO priority messages are intended to show what’s going on in the system, at a 
broad-brush level. INFO messages do not indicate that something’s amiss (use 
WARN or ERROR for that), and the system should be able to run at full speed in 
production with INFO level logging. The following types of message are probably 
appropriate at INFO level:  successfully initialised 
 transaction started, member: , amount: 
  transaction completed, txNo: , 
member: , amount: , result: 
DEBUG
DEBUG messages are intended to help isolate a problem in a running system, by 
showing the code that is executed, and the context information used during that 
execution. In many cases, it is that context information that is most 
important, so you should take pains to make the context as useful as possible. 
For example, the message ‘doTransaction() started’ says nothing about which 
merchant the transaction is for, the type of transaction, the amount, or 
anything else that might help us to relate this to a transaction that failed. 
Using Log4J’s ThreadContext there is a common mechanism provided for 
thread-based (effectively request-based) context (things like session IDs, 
transaction IDs etc.), so if some of the context in your message should be 
common to all log messages for this request, set it in the context (and make 
sure your PatternLayout can display it). In normal operation, a production 
system would not be expected to run at DEBUG level. However, if there is an 
occasional problem being experienced, DEBUG logging may be enabled for an 
extended period, so it’s important that the overhead of this is not too high 
(up to 25% is perhaps OK).
TRACE
This is the fine-grained diagnostic level, serving for events which indicate 
internal state transitions in full detail. Events on this level are not

[jira] [Commented] (LOG4J2-1756) Adds xmlns in schema and some other tags

2017-02-02 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LOG4J2-1756:
-

Commit 5b93c1e2fd1e0a0efeb7f74bad84864c714e9f8a in logging-log4j2's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=5b93c1e ]

LOG4J2-1756 Commit to close github pull request.

This closes #53


> Adds xmlns in schema and some other tags 
> -
>
> Key: LOG4J2-1756
> URL: https://issues.apache.org/jira/browse/LOG4J2-1756
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8
>
>
> Adds xmlns in schema and some tags. See 
> https://github.com/apache/logging-log4j2/pull/53



--
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-1806) Fix javadoc for DefaultRolloverStrategy::purgeAscending

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma closed LOG4J2-1806.
---
Resolution: Fixed

Fixed in master in commit 12f91eb.

> Fix javadoc for DefaultRolloverStrategy::purgeAscending
> ---
>
> Key: LOG4J2-1806
> URL: https://issues.apache.org/jira/browse/LOG4J2-1806
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> See https://github.com/apache/logging-log4j2/pull/41



--
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-1806) Fix javadoc for DefaultRolloverStrategy::purgeAscending

2017-02-02 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LOG4J2-1806:
-

Commit 12f91ebc700ea7f4a57306a4d84fce2f75f8442b in logging-log4j2's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=12f91eb ]

LOG4J2-1806 Fix javadoc for DefaultRolloverStrategy::purgeAscending

This closes #41
https://github.com/apache/logging-log4j2/pull/41


> Fix javadoc for DefaultRolloverStrategy::purgeAscending
> ---
>
> Key: LOG4J2-1806
> URL: https://issues.apache.org/jira/browse/LOG4J2-1806
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> See https://github.com/apache/logging-log4j2/pull/41



--
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] [Created] (LOG4J2-1806) Fix javadoc for DefaultRolloverStrategy::purgeAscending

2017-02-02 Thread Remko Popma (JIRA)

Remko Popma created LOG4J2-1806:
---

 Summary: Fix javadoc for DefaultRolloverStrategy::purgeAscending
 Key: LOG4J2-1806
 URL: https://issues.apache.org/jira/browse/LOG4J2-1806
 Project: Log4j 2
  Issue Type: Bug
  Components: Documentation
Reporter: Remko Popma
Assignee: Remko Popma
 Fix For: 2.8.1


See https://github.com/apache/logging-log4j2/pull/41



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

Jenkins build is back to stable : Log4j 2.x #2642

2017-02-02 Thread Apache Jenkins Server

See 


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

[jira] [Commented] (LOG4J2-1799) Error determining the current charset

2017-02-02 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LOG4J2-1799:


Github user edwgiz commented on the issue:

https://github.com/apache/logging-log4j2/pull/57
  
Ok, thanks a lot


> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
> Fix For: 2.8.1
>
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1799) Error determining the current charset

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma resolved LOG4J2-1799.
-
   Resolution: Fixed
Fix Version/s: 2.8.1

Fixed in master. Please verify and close.

> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
> Fix For: 2.8.1
>
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1799) Error determining the current charset

2017-02-02 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LOG4J2-1799:


Github user asfgit closed the pull request at:

https://github.com/apache/logging-log4j2/pull/57


> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1799) Error determining the current charset

2017-02-02 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LOG4J2-1799:
-

Commit ac51b5bc451f2de2ab80fb42d1b9782c7c785d29 in logging-log4j2's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=ac51b5b ]

LOG4J2-1799 Fixed bug in PropertiesUtil::getCharsetProperty that caused 
UnsupportedCharsetException for ConsoleAppender.

This closes #57
https://github.com/apache/logging-log4j2/pull/57


> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1799) Error determining the current charset

2017-02-02 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LOG4J2-1799:
-

Commit e31731b6898a3f241c65fc613e7948284a4a42df in logging-log4j2's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=e31731b ]

Merge branch 'LOG4J2-1799' of https://github.com/edwgiz/logging-log4j2


> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1799) Error determining the current charset

2017-02-02 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LOG4J2-1799:
-

Commit 84d816ffbfac090de73ff283307b473850899723 in logging-log4j2's branch 
refs/heads/master from [~edwgiz]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=84d816f ]

[LOG4J2-1799]: Error determining the current charset


> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1799) Error determining the current charset

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma reassigned LOG4J2-1799:
---

Assignee: Remko Popma

> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1805) FixedDateFormat improvements

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma closed LOG4J2-1805.
---
Resolution: Fixed

Fixed in master in commit d52ce48.

> FixedDateFormat improvements
> 
>
> Key: LOG4J2-1805
> URL: https://issues.apache.org/jira/browse/LOG4J2-1805
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Pattern Converters
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> *Proposed changes:*
> * improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
> * expose {{FixedDateFormat::millisSinceMidnight}} as a public method
> In multi-threaded scenarios where time does not move forward monotonically, 
> the implementation of {{FixedDateFormat::updateMidnightMillis}} can result in 
> corrupted time stamps. In a project I am involved in we have a custom 
> PatternConverter that uses FixedDateFormat to format the "event time". In 
> these (artificial) tests, event time does not always move forward, so the 
> {{updateMidnightMillis}} is called concurrently with varying values. This is 
> not a production issue, but the implementation can be improved to be 
> thread-safe without impacting performance by using double-checked locking.
> Making {{FixedDateFormat::millisSinceMidnight}} public would provide a 
> performant and convenient way to strip off the date component. Useful for 
> systems that are on Java 7 or for systems on Java 8 that don't want to 
> construct a {{LocalTime}} object every time this value is required.



--
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-1805) FixedDateFormat improvements

2017-02-02 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LOG4J2-1805:
-

Commit d52ce48f74f6abc7f210122788af90a7526bc5ef in logging-log4j2's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=d52ce48 ]

LOG4J2-1805 Fixed rare race condition in FixedDateFormat, made 
FixedDateFormat::millisSinceMidnight method public.


> FixedDateFormat improvements
> 
>
> Key: LOG4J2-1805
> URL: https://issues.apache.org/jira/browse/LOG4J2-1805
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Pattern Converters
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> *Proposed changes:*
> * improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
> * expose {{FixedDateFormat::millisSinceMidnight}} as a public method
> In multi-threaded scenarios where time does not move forward monotonically, 
> the implementation of {{FixedDateFormat::updateMidnightMillis}} can result in 
> corrupted time stamps. In a project I am involved in we have a custom 
> PatternConverter that uses FixedDateFormat to format the "event time". In 
> these (artificial) tests, event time does not always move forward, so the 
> {{updateMidnightMillis}} is called concurrently with varying values. This is 
> not a production issue, but the implementation can be improved to be 
> thread-safe without impacting performance by using double-checked locking.
> Making {{FixedDateFormat::millisSinceMidnight}} public would provide a 
> performant and convenient way to strip off the date component. Useful for 
> systems that are on Java 7 or for systems on Java 8 that don't want to 
> construct a {{LocalTime}} object every time this value is required.



--
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-1799) Error determining the current charset

2017-02-02 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LOG4J2-1799:


Github user jvz commented on the issue:

https://github.com/apache/logging-log4j2/pull/57
  
I don't see any way to replay it from Travis. You could try doing a `git 
commit --amend` and `git push --force`. That will change the commit id which 
should trigger a new build.


> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1803) JMH generated benchmark classes not included in jar

2017-02-02 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LOG4J2-1803:
-

Commit 8ce7dbcdf1d8a92bba3f0c8c9429cd4c8c491306 in logging-log4j2's branch 
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=8ce7dbc ]

LOG4J2-1803 changelog


> JMH generated benchmark classes not included in jar
> ---
>
> Key: LOG4J2-1803
> URL: https://issues.apache.org/jira/browse/LOG4J2-1803
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Performance Benchmarks
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Ralph Goers
> Fix For: 2.8.1
>
>
> Some time after the 2.7 release, the JMH benchmarks stopped working. When 
> trying to execute them, this error occurs:
> {code}
> java.lang.IllegalArgumentException: Benchmark does not match a class
>   at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:90)
>   at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:198)
>   at org.openjdk.jmh.runner.BaseRunner.runBenchmarks(BaseRunner.java:95)
>   at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:51)
>   at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:68)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.logging.log4j.perf.jmh.generated.FileAppenderBenchmark_julFile
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:195)
>   at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:72)
>   ... 4 more
> {code}
> When I build the project, the classes generated by JMH under 
> log4j-perf/target/generated-sources/annotations are not included in the 
> shaded benchmarks.jar or in log4j-perf-2.8.1-SNAPSHOT.jar...
> The cause seems to be a change in the master pom:
> the {{maven-compiler-plugin}} plugin now has the below section which was not 
> there in 2.7. 
> If I take it out and build only log4j-perf, the benchmarks run without error. 
> (But building all modules fails: some problem in log4j-core...)
> {code}
>   
> 
>   
>   default-compile
>   
> compile
>   
>   compile
>   
> none
>   
> 
> 
>   
>   process-plugins
>   
> compile
>   
>   process-classes
>   
> only
>   
> 
>   
> {code}
> From the log4j-dev mailing list:
> {quote}
> That maven-compiler-plugin config was originally only included in log4j-core 
> in order to allow the PluginProcessor annotation processor to re-run against 
> log4j-core without needing to split it into its own jar. I'm not sure why 
> it's configured for everything now.
> {quote}
> Potentially related: somebody reported on StackOverflow that [their custom 
> plugin no longer loads with 
> 2.8|http://stackoverflow.com/questions/41938128/log4j-2-8-cannot-load-custom-converters-in-osgi-environment].



--
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-1803) JMH generated benchmark classes not included in jar

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma closed LOG4J2-1803.
---
   Resolution: Fixed
Fix Version/s: 2.8.1

I confirmed Ralph's fix works, closing the issue. Thanks, Ralph!

> JMH generated benchmark classes not included in jar
> ---
>
> Key: LOG4J2-1803
> URL: https://issues.apache.org/jira/browse/LOG4J2-1803
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Performance Benchmarks
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Ralph Goers
> Fix For: 2.8.1
>
>
> Some time after the 2.7 release, the JMH benchmarks stopped working. When 
> trying to execute them, this error occurs:
> {code}
> java.lang.IllegalArgumentException: Benchmark does not match a class
>   at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:90)
>   at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:198)
>   at org.openjdk.jmh.runner.BaseRunner.runBenchmarks(BaseRunner.java:95)
>   at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:51)
>   at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:68)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.logging.log4j.perf.jmh.generated.FileAppenderBenchmark_julFile
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:195)
>   at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:72)
>   ... 4 more
> {code}
> When I build the project, the classes generated by JMH under 
> log4j-perf/target/generated-sources/annotations are not included in the 
> shaded benchmarks.jar or in log4j-perf-2.8.1-SNAPSHOT.jar...
> The cause seems to be a change in the master pom:
> the {{maven-compiler-plugin}} plugin now has the below section which was not 
> there in 2.7. 
> If I take it out and build only log4j-perf, the benchmarks run without error. 
> (But building all modules fails: some problem in log4j-core...)
> {code}
>   
> 
>   
>   default-compile
>   
> compile
>   
>   compile
>   
> none
>   
> 
> 
>   
>   process-plugins
>   
> compile
>   
>   process-classes
>   
> only
>   
> 
>   
> {code}
> From the log4j-dev mailing list:
> {quote}
> That maven-compiler-plugin config was originally only included in log4j-core 
> in order to allow the PluginProcessor annotation processor to re-run against 
> log4j-core without needing to split it into its own jar. I'm not sure why 
> it's configured for everything now.
> {quote}
> Potentially related: somebody reported on StackOverflow that [their custom 
> plugin no longer loads with 
> 2.8|http://stackoverflow.com/questions/41938128/log4j-2-8-cannot-load-custom-converters-in-osgi-environment].



--
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-1803) JMH generated benchmark classes not included in jar

2017-02-02 Thread Remko Popma (JIRA)


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

Remko Popma reassigned LOG4J2-1803:
---

Assignee: Ralph Goers

> JMH generated benchmark classes not included in jar
> ---
>
> Key: LOG4J2-1803
> URL: https://issues.apache.org/jira/browse/LOG4J2-1803
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Performance Benchmarks
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Ralph Goers
>
> Some time after the 2.7 release, the JMH benchmarks stopped working. When 
> trying to execute them, this error occurs:
> {code}
> java.lang.IllegalArgumentException: Benchmark does not match a class
>   at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:90)
>   at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:198)
>   at org.openjdk.jmh.runner.BaseRunner.runBenchmarks(BaseRunner.java:95)
>   at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:51)
>   at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:68)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.logging.log4j.perf.jmh.generated.FileAppenderBenchmark_julFile
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:195)
>   at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:72)
>   ... 4 more
> {code}
> When I build the project, the classes generated by JMH under 
> log4j-perf/target/generated-sources/annotations are not included in the 
> shaded benchmarks.jar or in log4j-perf-2.8.1-SNAPSHOT.jar...
> The cause seems to be a change in the master pom:
> the {{maven-compiler-plugin}} plugin now has the below section which was not 
> there in 2.7. 
> If I take it out and build only log4j-perf, the benchmarks run without error. 
> (But building all modules fails: some problem in log4j-core...)
> {code}
>   
> 
>   
>   default-compile
>   
> compile
>   
>   compile
>   
> none
>   
> 
> 
>   
>   process-plugins
>   
> compile
>   
>   process-classes
>   
> only
>   
> 
>   
> {code}
> From the log4j-dev mailing list:
> {quote}
> That maven-compiler-plugin config was originally only included in log4j-core 
> in order to allow the PluginProcessor annotation processor to re-run against 
> log4j-core without needing to split it into its own jar. I'm not sure why 
> it's configured for everything now.
> {quote}
> Potentially related: somebody reported on StackOverflow that [their custom 
> plugin no longer loads with 
> 2.8|http://stackoverflow.com/questions/41938128/log4j-2-8-cannot-load-custom-converters-in-osgi-environment].



--
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-1799) Error determining the current charset

2017-02-02 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LOG4J2-1799:


Github user edwgiz commented on the issue:

https://github.com/apache/logging-log4j2/pull/57
  
How to restart the Travis check? There's just a log length exceeding 
because a lot of Maven downloads


> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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-1799) Error determining the current charset

2017-02-02 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LOG4J2-1799:


GitHub user edwgiz opened a pull request:

https://github.com/apache/logging-log4j2/pull/57

[LOG4J2-1799]: Error determining the current charset

https://issues.apache.org/jira/browse/LOG4J2-1799

It would be nice to add this fix to 2.8.1 release.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/edwgiz/logging-log4j2 LOG4J2-1799

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/logging-log4j2/pull/57.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #57


commit 84d816ffbfac090de73ff283307b473850899723
Author: Eduard Gizatullin 
Date:   2017-02-02T11:16:10Z

[LOG4J2-1799]: Error determining the current charset




> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset 
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?



--
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: Opinions or guidelines on what each logging level is for?

2017-02-02 Thread Gary Gregory

I have a basic introduction here
https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
but what eventually turns up (for me and at work) is that there are IMO
some levels missing. For example, I'd like a level between INFO and DEBUG
(like "more info" aka what some apps call VERBOSE). I would also use a
level between DEBUG and TRACE where I use TRACE for API entry/exit type of
logging. Ultimately, you can usually get away without using any extra
levels and instead use another super feature: Markers (see the link).

Gary

On Wed, Feb 1, 2017 at 10:29 PM, Matt Sicker  wrote:

> I had a meeting at work recently where a small debate was brought up as to
> what sorts of things to log at each logging level. I had my own opinion
> about it, of course, but I noticed that there are brief notes in the
> javadocs about each level (going back in the git logs, it look like Ralph
> wrote those notes almost 6 years ago!) and that's about it when it comes to
> any sort of specifics.
>
> Does anyone have some more elaborations on why you'd use each level? Or
> some more concrete differences between, for example, error/warn and
> debug/trace? Perhaps some examples reflecting how you've used it in the
> past or even custom logging levels you've added?
>
> In a related idea, I'm kind of thinking that a general page about logging
> concepts may be useful for the manual, so I'd like to gather some opinions
> on said topics first.
>
> --
> Matt Sicker 
>

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

38 matches

Mail list logo