[jira] [Commented] (LOG4J2-1502) CsvParameterLayout is inserting NUL character if data starts with {, (, [ or "

[Sumit Singhal (JIRA)]

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

Sumit Singhal commented on LOG4J2-1502:
---

Just to clarify Gary, the problem appears with a specific type of data, (JSON 
or starting with braces as mentioned). NUL character does not appear with 
normal strings.

> CsvParameterLayout is inserting NUL character if data starts with {, (, [ or "
> --
>
> Key: LOG4J2-1502
> URL: https://issues.apache.org/jira/browse/LOG4J2-1502
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Layouts
>Affects Versions: 2.6.2
>Reporter: Sumit Singhal
>
> I am using CsvParameterLayout to generate a CSV file out of log4j2. One of 
> the column is a JSON string. Following is the logger method I am using:
> {code:java}
> logger.info("log:{}",json);
> {code}
> Following is the JSON string:
> {"id":10,"name":"sumit"}
> And following is the string which is getting printed in CSV output file:
>  NUL{"id":10,"name":"sumit"}NUL
> The NUL character is the \x00 character. When I open the file in notepad++, 
> then only this character appears. In notepad it shows as space. This poses a 
> problem in CSV processing module.
> If there is some alphabet before {, then the output in CSV is fine. It seems 
> as if log4j is escaping '{' with a NUL character. It is happening if the 
> string starts with {, (, [, ' or ".
> Following are the dependencies:
> {code:xml}
>   
>   org.apache.logging.log4j
>   log4j-core
>   2.6.2
>   
>   
>   org.apache.logging.log4j
>   log4j-slf4j-impl
>   2.6.2
>   
>   
>   org.apache.commons
>   commons-csv
>   1.4
>   
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LOG4J2-1554) org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter

[Sergey Chernov (JIRA)]

Sergey Chernov created LOG4J2-1554:
--

 Summary: 
org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override 
all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter
 Key: LOG4J2-1554
 URL: https://issues.apache.org/jira/browse/LOG4J2-1554
 Project: Log4j 2
  Issue Type: Bug
  Components: Filters
Affects Versions: 2.6.2
 Environment: Development
Reporter: Sergey Chernov


We have found that filtering doesn't work with DynamicThresholdFilter when we 
are using methods like logger.trace(pattern, val); 

We have found that DynamicThresholdFilter overrides only few 'filter' methods 
of AbstractFilter what causes returning Result.NEUTRAL on them, so filtering 
doesn't work.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1235) org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy not working correctly

[Sascha Scholz (JIRA)]

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

Sascha Scholz commented on LOG4J2-1235:
---

Is anyone working on getting the patch merged? Please tell if something is 
needed.

Thanks,
Sascha

> org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy not working 
> correctly
> 
>
> Key: LOG4J2-1235
> URL: https://issues.apache.org/jira/browse/LOG4J2-1235
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Niranjan Rao
>Priority: Critical
>
> There is a problem in the function 
> org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy.scheduleNext().
> I got out of file handles errors despite of setting IdlePurgePolicy. I did 
> some digging I believe following is the cause
> If the createTime is Long.MAX_VALUE, task is never scheduled. However 
> function 
> org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy.update(String, 
> LogEvent) checks if the future is not null before deciding to schedule.
> After appendersUsage becomes empty first time, appenders keep piling up.
> I believe fix will be to set future to null in the function scheduleNext in 
> the else part of the condition where it checks for createTime



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-1553:
-

This is my "template" of points I try to cover in a Jira:

# What is the proposed change
# Why do I want to do this (benefits)
# Potential drawbacks
# How I propose to mitigate the drawbacks (and/or explain why the proposal is a 
good trade-off)

(If any of the above is missing, it just makes the reader do the work of 
figuring out what it could be...)

In the case of this ticket, I would expect something like
{quote}
I propose to let AbstractManager implement AutoCloseable.

This will make our tests cleaner, smaller and hopefully less error-prone. 
Current code:
{code}
FileManager mgr = new FileManager(lots, of, params);
try {
// test code
} finally {
mgr.close();
}
{code}

After the proposed change, our test code can look like this:
{code}
try (FileManager mgr = new FileManager(lots, of, params)) {
// test code
}
{code}

A drawback is that there is some potential for confusing contributors or other 
people reading our code: AutoCloseable is often used with short-lived objects, 
while in "production" usage the Managers in Log4j live for a very long time. 
Implementing AutoCloseable will not be useful for "production" usage of 
Managers, it will only be useful for tests. 

I believe we can reduce the risk of confusing people by documenting (javadoc 
and normal comments where appropriate) in our code where we implement  
AutoCloseable that this is to facilitate testing and not for production usage.
{quote}
This would tick all the four boxes I mention above.


> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> AbstractManager should implement AutoCloseable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Scala and Eclipse

[Mikael Ståldal]

I don't know, I only use IntelliJ IDEA.

On Sun, Aug 28, 2016 at 5:21 PM, Gary Gregory 
wrote:

> Hi,
>
> Is there a specific version of Scala plugins I should use to get the new
> Scala modules to build in Eclipse? Is it possible to have both the 2.10 and
> 2.11 Scala modules building in the same workspace with the same Eclipse
> plugin?
>
> 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
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

[jira] [Commented] (LOG4J2-1554) org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1554:
--

Sergey,

This sounds like the same issue as [LOG4J2-1511]. 

Can you try to build from Git master sources please?

Gary

> org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override 
> all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter
> 
>
> Key: LOG4J2-1554
> URL: https://issues.apache.org/jira/browse/LOG4J2-1554
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.6.2
> Environment: Development
>Reporter: Sergey Chernov
>
> We have found that filtering doesn't work with DynamicThresholdFilter when we 
> are using methods like logger.trace(pattern, val); 
> We have found that DynamicThresholdFilter overrides only few 'filter' methods 
> of AbstractFilter what causes returning Result.NEUTRAL on them, so filtering 
> doesn't work.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1553:
--

A short lived object depends on your perspective. For example, in JDBC, you 
keep a {{Connection}} and {{PreparedStatement}} around for a "long" time. I'll 
update the description...

> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> AbstractManager should implement AutoCloseable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1553:
-
Description: 
The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.

A manager holds on to resources that must be cleaned up. Typically these 
resources are allocated on instance creation and freed by calling the manager's 
{{release()}} method.

There are several benefits to this change:
- Make it obvious and formal that this kind of object must be properly managed.
- A reader or cloner of the code will know that there is a pattern here.
- Cleans up our unit tests which handle managers explicitly.

This pattern is used in many of our unit tests.

  was:AbstractManager should implement AutoCloseable.


> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern here.
> - Cleans up our unit tests which handle managers explicitly.
> This pattern is used in many of our unit tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-1553 at 8/29/16 6:30 PM:
---

A short lived object depends on your perspective. For example, in JDBC, you 
keep a {{Connection}} and {{PreparedStatement}} around for a "long" time. I'll 
update the description...

Javadoc'ing is good too.




was (Author: garydgregory):
A short lived object depends on your perspective. For example, in JDBC, you 
keep a {{Connection}} and {{PreparedStatement}} around for a "long" time. I'll 
update the description...

> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern to follow.
> - This will make our tests cleaner, smaller and hopefully less error-prone. 
> Our current unit test code follows this pattern:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> mgr.close();
> }
> {code}
> Sometimes, we also have:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> if (mgr != null) {
>   mgr.close();
> }
> }
> {code}
> After the proposed change, our test code can look like this:
> {code:java}
> try (SomeManager mgr = new SomeManager(lots, of, params)) {
> // test code
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1553:
-
Description: 
The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.

A manager holds on to resources that must be cleaned up. Typically these 
resources are allocated on instance creation and freed by calling the manager's 
{{release()}} method.

There are several benefits to this change:
- Make it obvious and formal that this kind of object must be properly managed.
- A reader or cloner of the code will know that there is a pattern to follow.
- This will make our tests cleaner, smaller and hopefully less error-prone. 

Our current unit test code follows this pattern:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
mgr.close();
}
{code}

Sometimes, we also have:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
if (mgr != null) {
  mgr.close();
}
}
{code}

After the proposed change, our test code can look like this:

{code:java}
try (SomeManager mgr = new SomeManager(lots, of, params)) {
// test code
}
{code}

  was:
The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.

A manager holds on to resources that must be cleaned up. Typically these 
resources are allocated on instance creation and freed by calling the manager's 
{{release()}} method.

There are several benefits to this change:
- Make it obvious and formal that this kind of object must be properly managed.
- A reader or cloner of the code will know that there is a pattern here.
- Cleans up our unit tests which handle managers explicitly.

This pattern is used in many of our unit tests.


> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern to follow.
> - This will make our tests cleaner, smaller and hopefully less error-prone. 
> Our current unit test code follows this pattern:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> mgr.close();
> }
> {code}
> Sometimes, we also have:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> if (mgr != null) {
>   mgr.close();
> }
> }
> {code}
> After the proposed change, our test code can look like this:
> {code:java}
> try (SomeManager mgr = new SomeManager(lots, of, params)) {
> // test code
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1553:
-
Description: 
The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.

A manager holds on to resources that must be cleaned up. Typically these 
resources are allocated on instance creation and freed by calling the manager's 
{{release()}} method.

For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, {{release()}} 
will re-implemented as {{close()}} and deprecated.

There are several benefits to this change:
- Make it obvious and formal that this kind of object must be properly managed.
- A reader or cloner of the code will know that there is a pattern to follow.
- This will make our tests cleaner, smaller and hopefully less error-prone. 

Possible disadvantages:
- Coders may think that managers can be used like resources like a 
{{java.io.File}}.
- Some {{AutoCloseable}} implementations are short-lived, this one not so much, 
so we will add Javadoc for this effect and to note the benefit for unit tests.

Our current unit test code follows this pattern:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
mgr.close();
}
{code}

Sometimes, we also have:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
if (mgr != null) {
  mgr.close();
}
}
{code}

After the proposed change, our test code can look like this:

{code:java}
try (SomeManager mgr = new SomeManager(lots, of, params)) {
// test code
}
{code}

  was:
The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.

A manager holds on to resources that must be cleaned up. Typically these 
resources are allocated on instance creation and freed by calling the manager's 
{{release()}} method.

There are several benefits to this change:
- Make it obvious and formal that this kind of object must be properly managed.
- A reader or cloner of the code will know that there is a pattern to follow.
- This will make our tests cleaner, smaller and hopefully less error-prone. 

Our current unit test code follows this pattern:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
mgr.close();
}
{code}

Sometimes, we also have:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
if (mgr != null) {
  mgr.close();
}
}
{code}

After the proposed change, our test code can look like this:

{code:java}
try (SomeManager mgr = new SomeManager(lots, of, params)) {
// test code
}
{code}


> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, 
> {{release()}} will re-implemented as {{close()}} and deprecated.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern to follow.
> - This will make our tests cleaner, smaller and hopefully less error-prone. 
> Possible disadvantages:
> - Coders may think that managers can be used like resources like a 
> {{java.io.File}}.
> - Some {{AutoCloseable}} implementations are short-lived, this one not so 
> much, so we will add Javadoc for this effect and to note the benefit for unit 
> tests.
> Our current unit test code follows this pattern:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> mgr.close();
> }
> {code}
> Sometimes, we also have:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> if (mgr != null) {
>   mgr.close();
> }
> }
> {code}
> After the proposed change, our test code can look like this:
> {code:java}
> try (SomeManager mgr = new SomeManager(lots, of, params)) {
> // test code
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LOG4J2-1235) org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy not working correctly

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-1235.
--
   Resolution: Fixed
Fix Version/s: 2.7

In Git master.

Please verify and close.

> org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy not working 
> correctly
> 
>
> Key: LOG4J2-1235
> URL: https://issues.apache.org/jira/browse/LOG4J2-1235
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Niranjan Rao
>Priority: Critical
> Fix For: 2.7
>
>
> There is a problem in the function 
> org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy.scheduleNext().
> I got out of file handles errors despite of setting IdlePurgePolicy. I did 
> some digging I believe following is the cause
> If the createTime is Long.MAX_VALUE, task is never scheduled. However 
> function 
> org.apache.logging.log4j.core.appender.routing.IdlePurgePolicy.update(String, 
> LogEvent) checks if the future is not null before deciding to schedule.
> After appendersUsage becomes empty first time, appenders keep piling up.
> I believe fix will be to set future to null in the function scheduleNext in 
> the else part of the condition where it checks for createTime



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1553:
--

Thank you [~rem...@yahoo.com] for the careful review and great suggestions.

> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, 
> {{release()}} will re-implemented as {{close()}} and deprecated.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern to follow.
> - This will make our tests cleaner, smaller and hopefully less error-prone. 
> Possible disadvantages:
> - Coders may think that managers can be used like resources like a 
> {{java.io.File}}.
> - Some {{AutoCloseable}} implementations are short-lived, this one not so 
> much, so we will add Javadoc for this effect and to note the benefit for unit 
> tests.
> Our current unit test code follows this pattern:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> mgr.close();
> }
> {code}
> Sometimes, we also have:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> if (mgr != null) {
>   mgr.close();
> }
> }
> {code}
> After the proposed change, our test code can look like this:
> {code:java}
> try (SomeManager mgr = new SomeManager(lots, of, params)) {
> // test code
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LOG4J2-1554) org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter

[Sergey Chernov (JIRA)]

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

Sergey Chernov closed LOG4J2-1554.
--
   Resolution: Fixed
Fix Version/s: 2.7

LOG4J2-1511 is exactly duplicate of the current issue, so closing. 

> org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override 
> all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter
> 
>
> Key: LOG4J2-1554
> URL: https://issues.apache.org/jira/browse/LOG4J2-1554
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.6.2
> Environment: Development
>Reporter: Sergey Chernov
> Fix For: 2.7
>
>
> We have found that filtering doesn't work with DynamicThresholdFilter when we 
> are using methods like logger.trace(pattern, val); 
> We have found that DynamicThresholdFilter overrides only few 'filter' methods 
> of AbstractFilter what causes returning Result.NEUTRAL on them, so filtering 
> doesn't work.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1554) org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter

[Sergey Chernov (JIRA)]

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

Sergey Chernov commented on LOG4J2-1554:


Gary Gregory, thank you for pointing to the existing issue. 

I'll try to build the master, but I've checked what has been changed in 
LOG4J2-1511 - it what I'm expecting to see, thank you! 

I've closed my issue as duplicate. 

> org.apache.logging.log4j.core.filter.DynamicThresholdFilter doesn't override 
> all 'filter' methods of org.apache.logging.log4j.core.filter.AbstractFilter
> 
>
> Key: LOG4J2-1554
> URL: https://issues.apache.org/jira/browse/LOG4J2-1554
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.6.2
> Environment: Development
>Reporter: Sergey Chernov
> Fix For: 2.7
>
>
> We have found that filtering doesn't work with DynamicThresholdFilter when we 
> are using methods like logger.trace(pattern, val); 
> We have found that DynamicThresholdFilter overrides only few 'filter' methods 
> of AbstractFilter what causes returning Result.NEUTRAL on them, so filtering 
> doesn't work.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1502) CsvParameterLayout and CsvLogEventLayout insert NUL character if data starts with {, (, [ or "

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1502:
-
Summary: CsvParameterLayout and CsvLogEventLayout insert NUL character if 
data starts with {, (, [ or "  (was: CsvParameterLayout is inserting NUL 
character if data starts with {, (, [ or ")

> CsvParameterLayout and CsvLogEventLayout insert NUL character if data starts 
> with {, (, [ or "
> --
>
> Key: LOG4J2-1502
> URL: https://issues.apache.org/jira/browse/LOG4J2-1502
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Layouts
>Affects Versions: 2.6.2
>Reporter: Sumit Singhal
>
> I am using CsvParameterLayout to generate a CSV file out of log4j2. One of 
> the column is a JSON string. Following is the logger method I am using:
> {code:java}
> logger.info("log:{}",json);
> {code}
> Following is the JSON string:
> {"id":10,"name":"sumit"}
> And following is the string which is getting printed in CSV output file:
>  NUL{"id":10,"name":"sumit"}NUL
> The NUL character is the \x00 character. When I open the file in notepad++, 
> then only this character appears. In notepad it shows as space. This poses a 
> problem in CSV processing module.
> If there is some alphabet before {, then the output in CSV is fine. It seems 
> as if log4j is escaping '{' with a NUL character. It is happening if the 
> string starts with {, (, [, ' or ".
> Following are the dependencies:
> {code:xml}
>   
>   org.apache.logging.log4j
>   log4j-core
>   2.6.2
>   
>   
>   org.apache.logging.log4j
>   log4j-slf4j-impl
>   2.6.2
>   
>   
>   org.apache.commons
>   commons-csv
>   1.4
>   
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LOG4J2-1502) CsvParameterLayout and CsvLogEventLayout insert NUL character if data starts with {, (, [ or "

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-1502.
--
   Resolution: Fixed
Fix Version/s: 2.7

Fixed in Git master. Please verify and close.

> CsvParameterLayout and CsvLogEventLayout insert NUL character if data starts 
> with {, (, [ or "
> --
>
> Key: LOG4J2-1502
> URL: https://issues.apache.org/jira/browse/LOG4J2-1502
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Layouts
>Affects Versions: 2.6.2
>Reporter: Sumit Singhal
> Fix For: 2.7
>
>
> I am using CsvParameterLayout to generate a CSV file out of log4j2. One of 
> the column is a JSON string. Following is the logger method I am using:
> {code:java}
> logger.info("log:{}",json);
> {code}
> Following is the JSON string:
> {"id":10,"name":"sumit"}
> And following is the string which is getting printed in CSV output file:
>  NUL{"id":10,"name":"sumit"}NUL
> The NUL character is the \x00 character. When I open the file in notepad++, 
> then only this character appears. In notepad it shows as space. This poses a 
> problem in CSV processing module.
> If there is some alphabet before {, then the output in CSV is fine. It seems 
> as if log4j is escaping '{' with a NUL character. It is happening if the 
> string starts with {, (, [, ' or ".
> Following are the dependencies:
> {code:xml}
>   
>   org.apache.logging.log4j
>   log4j-core
>   2.6.2
>   
>   
>   org.apache.logging.log4j
>   log4j-slf4j-impl
>   2.6.2
>   
>   
>   org.apache.commons
>   commons-csv
>   1.4
>   
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1502) CsvParameterLayout and CsvLogEventLayout insert NUL character if data starts with {, (, [ or "

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1502:
--

This issue also applies to {{CsvLogEventLayout}}.

> CsvParameterLayout and CsvLogEventLayout insert NUL character if data starts 
> with {, (, [ or "
> --
>
> Key: LOG4J2-1502
> URL: https://issues.apache.org/jira/browse/LOG4J2-1502
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Layouts
>Affects Versions: 2.6.2
>Reporter: Sumit Singhal
> Fix For: 2.7
>
>
> I am using CsvParameterLayout to generate a CSV file out of log4j2. One of 
> the column is a JSON string. Following is the logger method I am using:
> {code:java}
> logger.info("log:{}",json);
> {code}
> Following is the JSON string:
> {"id":10,"name":"sumit"}
> And following is the string which is getting printed in CSV output file:
>  NUL{"id":10,"name":"sumit"}NUL
> The NUL character is the \x00 character. When I open the file in notepad++, 
> then only this character appears. In notepad it shows as space. This poses a 
> problem in CSV processing module.
> If there is some alphabet before {, then the output in CSV is fine. It seems 
> as if log4j is escaping '{' with a NUL character. It is happening if the 
> string starts with {, (, [, ' or ".
> Following are the dependencies:
> {code:xml}
>   
>   org.apache.logging.log4j
>   log4j-core
>   2.6.2
>   
>   
>   org.apache.logging.log4j
>   log4j-slf4j-impl
>   2.6.2
>   
>   
>   org.apache.commons
>   commons-csv
>   1.4
>   
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1553:
--

In the branch, the Javadoc now reads:
{code:java}
/**
 * Abstract base class used to register managers.
 * 
 * This class implements {@link AutoCloseable} mostly to allow unit tests to be 
written safely and succinctly. While
 * managers do need to allocate resources (usually on construction) and then 
free these resources, a manager is longer
 * lived than other auto-closeable objects like streams. None the less, making 
a manager AutoCloseable forces readers to
 * be aware of the the pattern: allocate resources on construction and call 
{@link #close()} at some point.
 * 
 */
public abstract class AbstractManager implements AutoCloseable {
{code}

> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, 
> {{release()}} will re-implemented as {{close()}} and deprecated.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern to follow.
> - This will make our tests cleaner, smaller and hopefully less error-prone. 
> Possible disadvantages:
> - Coders may think that managers can be used like resources like a 
> {{java.io.File}}.
> - Some {{AutoCloseable}} implementations are short-lived, this one not so 
> much, so we will add Javadoc for this effect and to note the benefit for unit 
> tests.
> Our current unit test code follows this pattern:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> mgr.close();
> }
> {code}
> Sometimes, we also have:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> if (mgr != null) {
>   mgr.close();
> }
> }
> {code}
> After the proposed change, our test code can look like this:
> {code:java}
> try (SomeManager mgr = new SomeManager(lots, of, params)) {
> // test code
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1548) [CronTriggeringPolicy] ConfigurationScheduler schedules the task infinitely after first fire

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1548:
--

I applied the patch 
https://issues.apache.org/jira/secure/attachment/12825955/LOG4J2-1548-testcase-cleanFoldersRule.patch

Thank you!
Gary

> [CronTriggeringPolicy] ConfigurationScheduler schedules the task infinitely 
> after first fire
> 
>
> Key: LOG4J2-1548
> URL: https://issues.apache.org/jira/browse/LOG4J2-1548
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Pierrick HYMBERT
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: LOG4J2-1548-testcase-2.patch, 
> LOG4J2-1548-testcase-cleanFoldersRule.patch, LOG4J2-1548-testcase.patch, 
> LOG4J2-1548.patch
>
>
> After first fire at fixed time, rename/archive action is sheduled infinitely.
> Example of configuration:
> {code:xml}
> fileName="target/rolling-cron-once-a-day/rollingtest.log"
>
> filePattern="target/rolling-cron-once-a-day/rollingtest-%d{MMdd}_%d{HHmmss}-%i.log.gz"
>immediateFlush="true">
>   
>   
> 
> {code}
> First trigger is scheduled at 13:58:27 then every new log entry generates an 
> archive file.
> Test case and suggested fix attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Matt Sicker]

Although the ticket seems dormant right now, I haven't seen any new build
errors with the same problem, so maybe they fixed it.

On 23 August 2016 at 21:29, Gary Gregory  wrote:

> Thanks Matt!
>
> Gary
>
> On Tue, Aug 23, 2016 at 5:32 PM, Matt Sicker  wrote:
>
>> Well, there's another failed build. I'm going to make an infra ticket.
>>
>> -- Forwarded message --
>> From: Apache Jenkins Server 
>> Date: 23 August 2016 at 18:45
>> Subject: Build failed in Jenkins: Log4j 2.x #2207
>> To: log4j-dev@logging.apache.org
>>
>>
>> See 
>>
>> Changes:
>>
>> [ggregory] [LOG4J2-1506] Unregister JMX ignores log4j2.disable.jmx
>> property.
>>
>> [ggregory] Use "Log4j2" in error messages instead of "log4j2".
>>
>> [ggregory] [LOG4J2-1506] Unregister JMX ignores log4j2.disable.jmx
>> property.
>>
>> [ggregory] No need to abbrieviate the API name.
>>
>> [ggregory] No need to abbrieviate the API name.
>>
>> --
>> Started by an SCM change
>> [EnvInject] - Loading node environment variables.
>> Building remotely on ubuntu-us1 (Ubuntu golang-ppa ubuntu-us ubuntu) in
>> workspace 
>>  > git rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url https://git-wip-us.apache.org/
>> repos/asf/logging-log4j2.git # timeout=10
>> Fetching upstream changes from https://git-wip-us.apache.org/
>> repos/asf/logging-log4j2.git
>>  > git --version # timeout=10
>>  > git -c core.askpass=true fetch --tags --progress
>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
>> +refs/heads/*:refs/remotes/origin/*
>>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
>> Checking out Revision 24ebb9f52fac67866632752e35ff1909e6c4668a
>> (refs/remotes/origin/master)
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 24ebb9f52fac67866632752e35ff1909e6c4668a
>>  > git rev-list b48cc0af0e153bcc0f3c7c99b7f288ab2b64f264 # timeout=10
>> [EnvInject] - Executing scripts and injecting environment variables after
>> the SCM step.
>> [EnvInject] - Injecting as environment variables the properties content
>> LANG=en_US.UTF-8
>>
>> [EnvInject] - Variables injected successfully.
>> Parsing POMs
>> Modules changed, recalculating dependency graph
>> Established TCP socket on 37097
>> maven32-agent.jar already up to date
>> maven32-interceptor.jar already up to date
>> maven3-interceptor-commons.jar already up to date
>> [Log4j 2.x] $ /home/jenkins/tools/java/latest1.7/bin/java -Xmx2g
>> -Xms256m -XX:MaxPermSize=512m -cp /home/jenkins/jenkins-slave/ma
>> ven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.1
>> /boot/plexus-classworlds-2.5.1.jar:/home/jenkins/tools/maven
>> /apache-maven-3.2.1/conf/logging jenkins.maven3.agent.Maven32Main
>> /home/jenkins/tools/maven/apache-maven-3.2.1
>> /home/jenkins/jenkins-slave/slave.jar 
>> /home/jenkins/jenkins-slave/maven32-interceptor.jar
>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 37097
>> Java HotSpot(TM) 64-Bit Server VM warning: Insufficient space for shared
>> memory file:
>>6624
>> Try using the -Djava.io.tmpdir= option to select an alternate temp
>> location.
>>
>> <===[JENKINS REMOTING CAPACITY]===>   channel started
>> Executing Maven:  -B -f > /Log4j%202.x/ws/pom.xml> -Dmaven.repo.local=/home/jenki
>> ns/jenkins-slave/maven-repositories/0 clean install
>> [INFO] Scanning for projects...
>> [WARNING]
>> [WARNING] Some problems were encountered while building the effective
>> model for org.apache.logging.log4j:log4j-bom:pom:2.6.3-SNAPSHOT
>> [WARNING] 'parent.relativePath' points at org.apache.logging.log4j:log4j
>> instead of org.apache:apache, please verify your project structure @ line
>> 19, column 11
>> [WARNING]
>> [WARNING] It is highly recommended to fix these problems because they
>> threaten the stability of your build.
>> [WARNING]
>> [WARNING] For this reason, future Maven versions might no longer support
>> building such malformed projects.
>> [WARNING]
>> [INFO] 
>> 
>> [INFO] Reactor Build Order:
>> [INFO]
>> [INFO] Apache Log4j 2
>> [INFO] Apache Log4j API
>> [INFO] Apache Log4j Core
>> [INFO] Apache Log4j 1.x Compatibility API
>> [INFO] Apache Log4j SLF4J Binding
>> [INFO] Apache Log4j to SLF4J Adapter
>> [INFO] Apache Log4j Commons Logging Bridge
>> [INFO] Apache Log4j Flume Bridge
>> [INFO] Apache Log4j Web
>> [INFO] Apache Log4j Tag Library
>> [INFO] Apache Log4j JMX GUI
>> [INFO] Apache Log4j Samples
>> [INFO] Apache Log4j Samples: Flume - Common
>> [INFO] Apache Log4j Samples: Flume - Remote
>> [INFO] Apache Log4j Samples: Flume - Embedded
>> [INFO] Apache Log4j Samples: Configuration
>> [INFO] Apache Log4j Samples: Log

[jira] [Created] (LOG4J2-1555) TimeBasedTriggeringPolicy seems to be off by 1

[Farid Zakaria (JIRA)]

Farid Zakaria created LOG4J2-1555:
-

 Summary: TimeBasedTriggeringPolicy seems to be off by 1
 Key: LOG4J2-1555
 URL: https://issues.apache.org/jira/browse/LOG4J2-1555
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.6.2
Reporter: Farid Zakaria


I have the following log4j2.xml config

{code:title=log4j2.xml}





%m %ex%n













{code}

The time for the roll over files seem to be off by 1

{code}
-rw-r--r--  1 fzakaria  staff   197B Aug 29 15:33 
app-2016-08-29T15:33:39Z.1.log.gz
-rw-r--r--  1 fzakaria  staff   180B Aug 29 15:33 
app-2016-08-29T15:33:44Z.1.log.gz
-rw-r--r--  1 fzakaria  staff   183B Aug 29 15:33 
app-2016-08-29T15:33:49Z.1.log.gz
-rw-r--r--  1 fzakaria  staff   183B Aug 29 15:33 
app-2016-08-29T15:33:54Z.1.log.gz
-rw-r--r--  1 fzakaria  staff   183B Aug 29 15:34 
app-2016-08-29T15:33:59Z.1.log.gz
-rw-r--r--  1 fzakaria  staff   112B Aug 29 15:35 
app-2016-08-29T15:34:04Z.1.log.gz
-rw-r--r--  1 fzakaria  staff   112B Aug 29 15:35 
app-2016-08-29T15:34:54Z.1.log.gz
-rw-r--r--  1 fzakaria  staff   147B Aug 29 15:35 
app-2016-08-29T15:35:09Z.1.log.gz
{code}

I would expect intervals of 0, 5, 10, 15, 20, 25... given the interval and 
modulate boolean.

The code itself seems to subtract one from the calendar, but unsure why

https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/PatternProcessor.java#L172



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1010) Injectable context properties

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-1010:
-

The performance concerns Ralph raised regarding global Filters have been 
addressed.

For further reviews, may I propose that people review the 
{{LOG4J2-1349-gcfree-threadcontext}} branch instead? It has the same changes as 
the {{LOG4J2-1010&LOG4J2-1447-injectable-contextdata&better-datastructure}} 
branch, but in addition moved ContextData and related interfaces to 
org.apache.logging.log4j.spi package in log4j-api.

Without the LOG4J2-1349 changes
* context data-based Filters and Lookups need to make an unnecessary copy
* injecting context data into the log event needs to make an unnecessary copy

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> is not so useful since JVM threads might not be coupled to the logical flow 
> of the application.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-1553:
-
Description: 
The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.

A manager holds on to resources that must be cleaned up. Typically these 
resources are allocated on instance creation and freed by calling the manager's 
{{release()}} method.

For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, {{release()}} 
will re-implemented as {{close()}} and deprecated.

There are several benefits to this change:
- Make it obvious and formal that this kind of object must be properly managed.
- A reader or cloner of the code will know that there is a pattern to follow.
- This will make our tests cleaner, smaller and hopefully less error-prone. 

Possible disadvantages:
- Coders may think that managers can be used like resources like a 
{{java.io.File}}.
- Some {{AutoCloseable}} implementations are short-lived, this one not so much, 
so we will add Javadoc for this effect and to note the benefit for unit tests.

Our current unit test code follows this pattern:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
mgr.close();
}
{code}

Sometimes, we also have:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
if (mgr != null) {
  mgr.close();
}
}
{code}

After the proposed change, our test code can look like this:

{code:java}
try (SomeManager mgr = new SomeManager(lots, of, params)) {
// test code
}
{code}

New Javadoc:

{code:java}
/**
 * Abstract base class used to register managers.
 * 
 * This class implements {@link AutoCloseable} mostly to allow unit tests to be 
written safely and succinctly. While
 * managers do need to allocate resources (usually on construction) and then 
free these resources, a manager is longer
 * lived than other auto-closeable objects like streams. None the less, making 
a manager AutoCloseable forces readers to
 * be aware of the the pattern: allocate resources on construction and call 
{@link #close()} at some point.
 * 
 */
public abstract class AbstractManager implements AutoCloseable {
{code}

  was:
The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.

A manager holds on to resources that must be cleaned up. Typically these 
resources are allocated on instance creation and freed by calling the manager's 
{{release()}} method.

For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, {{release()}} 
will re-implemented as {{close()}} and deprecated.

There are several benefits to this change:
- Make it obvious and formal that this kind of object must be properly managed.
- A reader or cloner of the code will know that there is a pattern to follow.
- This will make our tests cleaner, smaller and hopefully less error-prone. 

Possible disadvantages:
- Coders may think that managers can be used like resources like a 
{{java.io.File}}.
- Some {{AutoCloseable}} implementations are short-lived, this one not so much, 
so we will add Javadoc for this effect and to note the benefit for unit tests.

Our current unit test code follows this pattern:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
mgr.close();
}
{code}

Sometimes, we also have:

{code:java}
SomeManager mgr = new SomeManager(lots, of, params);
try {
// test code
} finally {
if (mgr != null) {
  mgr.close();
}
}
{code}

After the proposed change, our test code can look like this:

{code:java}
try (SomeManager mgr = new SomeManager(lots, of, params)) {
// test code
}
{code}


> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, 
> {{release()}} will re-implemented as {{close()}} and deprecated.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern to follow.
> - This will make our tests cleaner, smaller and hopefully less error-prone. 
> Possible disadvantages:
> - Coders may think that managers can be used like resources like a 
> {{java.io.File}}.
> - Some {{AutoCloseable}} implementati

[jira] [Commented] (LOG4J2-1553) AbstractManager should implement AutoCloseable

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1553:
--

This branch is good to go IMO. I'll wait another day or so before committing in 
case there is more feedback.

> AbstractManager should implement AutoCloseable
> --
>
> Key: LOG4J2-1553
> URL: https://issues.apache.org/jira/browse/LOG4J2-1553
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The class {{AbstractManager}} should implement {{java.lang.AutoCloseable}}.
> A manager holds on to resources that must be cleaned up. Typically these 
> resources are allocated on instance creation and freed by calling the 
> manager's {{release()}} method.
> For {{AbstractManager}} to implement {{java.lang.AutoCloseable}}, 
> {{release()}} will re-implemented as {{close()}} and deprecated.
> There are several benefits to this change:
> - Make it obvious and formal that this kind of object must be properly 
> managed.
> - A reader or cloner of the code will know that there is a pattern to follow.
> - This will make our tests cleaner, smaller and hopefully less error-prone. 
> Possible disadvantages:
> - Coders may think that managers can be used like resources like a 
> {{java.io.File}}.
> - Some {{AutoCloseable}} implementations are short-lived, this one not so 
> much, so we will add Javadoc for this effect and to note the benefit for unit 
> tests.
> Our current unit test code follows this pattern:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> mgr.close();
> }
> {code}
> Sometimes, we also have:
> {code:java}
> SomeManager mgr = new SomeManager(lots, of, params);
> try {
> // test code
> } finally {
> if (mgr != null) {
>   mgr.close();
> }
> }
> {code}
> After the proposed change, our test code can look like this:
> {code:java}
> try (SomeManager mgr = new SomeManager(lots, of, params)) {
> // test code
> }
> {code}
> New Javadoc:
> {code:java}
> /**
>  * Abstract base class used to register managers.
>  * 
>  * This class implements {@link AutoCloseable} mostly to allow unit tests to 
> be written safely and succinctly. While
>  * managers do need to allocate resources (usually on construction) and then 
> free these resources, a manager is longer
>  * lived than other auto-closeable objects like streams. None the less, 
> making a manager AutoCloseable forces readers to
>  * be aware of the the pattern: allocate resources on construction and call 
> {@link #close()} at some point.
>  * 
>  */
> public abstract class AbstractManager implements AutoCloseable {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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