[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-1259 at 9/9/16 2:28 AM:
--

I've restored binary compatibility for TriggeringPolicy in Git master. I added 
a TODO comment for 3.0 to extend LifeCycle.


was (Author: garydgregory):
I've restore binary compatibility for TriggeringPolicy in Git master. I added a 
TODO comment for 3.0 to extend LifeCycle.

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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

Re: Async tests with ListAppender

[Remko Popma]

To answer your original question should ListAppender internally use 
CopyOnWriteArrayList, probably yes. There is certainly no harm and it might 
prevent unpredictable behavior. 

Also, ListAppender actually provides a CountDownLatch that you can set in the 
test (before logging) with the expected number of events. The appender will 
count down with each event, so in the test you can do countDownLatch.await(). 

Sent from my iPhone

> On 2016/09/09, at 8:33, Gary Gregory  wrote:
> 
> I'm pretty sure I've "fixed" AsyncAppender for now. The test needs to wait 
> long enough is all. Feel free to check the current version and AsyncAppender 
> and tell me what you think.
> 
> Gary
> 
>> On Thu, Sep 8, 2016 at 4:26 PM, Remko Popma  wrote:
>> Ah, you're if it's possible that the reason the AsyncAppender test is 
>> failing is because of a concurrency issue in ListAppender. It is possible 
>> when the queue is full: our recent change to the DefaultAsyncQueueFullPolicy 
>> is to log synchronously when the queue is full. This is also used in 
>> AsyncAppender. 
>> 
>> Sent from my iPhone
>> 
>>> On 2016/09/09, at 8:14, Gary Gregory  wrote:
>>> 
>>> Do we have tests that are async (I'd say yes of course) and that could 
>>> loose events in a list appender (I do not know)? Are we getting lucky? IOW, 
>>> do we have the kind of async tests that end up stressing the system in a 
>>> way were we could loose events in a list appender (don't know). If we do 
>>> not, should we, is that missing?
>>> 
>>> Gary
>>> 
 On Thu, Sep 8, 2016 at 4:09 PM, Ralph Goers  
 wrote:
 So why are you asking?
 
 Ralph
 
> On Sep 8, 2016, at 2:45 PM, Gary Gregory  wrote:
> 
>> On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers  
>> wrote:
>> Why would it? Do you have multiple threads logging? It wasn’t written to 
>> be used by anything but single threaded unit tests.
> 
> I do not have multiple threads logging in a test but I do not know if 
> there is one such test in the whole suite.
> 
> Gary
>  
>> 
>> Ralph
>> 
>>> On Sep 8, 2016, at 1:34 PM, Gary Gregory  wrote:
>>> 
>>> Should ListAppender use CopyOnWriteArray instead of ArrayList? Either 
>>> all the time or when using in aync tests?
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Re: Async tests with ListAppender

[Gary Gregory]

I'm pretty sure I've "fixed" AsyncAppender for now. The test needs to wait
long enough is all. Feel free to check the current version and AsyncAppender
and tell me what you think.

Gary

On Thu, Sep 8, 2016 at 4:26 PM, Remko Popma  wrote:

> Ah, you're if it's possible that the reason the AsyncAppender test is
> failing is because of a concurrency issue in ListAppender. It is possible
> when the queue is full: our recent change to the
> DefaultAsyncQueueFullPolicy is to log synchronously when the queue is full.
> This is also used in AsyncAppender.
>
> Sent from my iPhone
>
> On 2016/09/09, at 8:14, Gary Gregory  wrote:
>
> Do we have tests that are async (I'd say yes of course) and that could
> loose events in a list appender (I do not know)? Are we getting lucky? IOW,
> do we have the kind of async tests that end up stressing the system in a
> way were we could loose events in a list appender (don't know). If we do
> not, should we, is that missing?
>
> Gary
>
> On Thu, Sep 8, 2016 at 4:09 PM, Ralph Goers 
> wrote:
>
>> So why are you asking?
>>
>> Ralph
>>
>> On Sep 8, 2016, at 2:45 PM, Gary Gregory  wrote:
>>
>> On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers 
>> wrote:
>>
>>> Why would it? Do you have multiple threads logging? It wasn’t written to
>>> be used by anything but single threaded unit tests.
>>>
>>
>> I do not have multiple threads logging in a test but I do not know if
>> there is one such test in the whole suite.
>>
>> Gary
>>
>>
>>>
>>> Ralph
>>>
>>> On Sep 8, 2016, at 1:34 PM, Gary Gregory  wrote:
>>>
>>> Should ListAppender use CopyOnWriteArray instead of ArrayList? Either
>>> all the time or when using in aync tests?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> 
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> 
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Async tests with ListAppender

[Remko Popma]

Ah, you're if it's possible that the reason the AsyncAppender test is failing 
is because of a concurrency issue in ListAppender. It is possible when the 
queue is full: our recent change to the DefaultAsyncQueueFullPolicy is to log 
synchronously when the queue is full. This is also used in AsyncAppender. 

Sent from my iPhone

> On 2016/09/09, at 8:14, Gary Gregory  wrote:
> 
> Do we have tests that are async (I'd say yes of course) and that could loose 
> events in a list appender (I do not know)? Are we getting lucky? IOW, do we 
> have the kind of async tests that end up stressing the system in a way were 
> we could loose events in a list appender (don't know). If we do not, should 
> we, is that missing?
> 
> Gary
> 
>> On Thu, Sep 8, 2016 at 4:09 PM, Ralph Goers  
>> wrote:
>> So why are you asking?
>> 
>> Ralph
>> 
>>> On Sep 8, 2016, at 2:45 PM, Gary Gregory  wrote:
>>> 
 On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers  
 wrote:
 Why would it? Do you have multiple threads logging? It wasn’t written to 
 be used by anything but single threaded unit tests.
>>> 
>>> I do not have multiple threads logging in a test but I do not know if there 
>>> is one such test in the whole suite.
>>> 
>>> Gary
>>>  
 
 Ralph
 
> On Sep 8, 2016, at 1:34 PM, Gary Gregory  wrote:
> 
> Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all 
> the time or when using in aync tests?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> 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 is back to stable : Log4j 2.x #2286

[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

Re: Async tests with ListAppender

[Gary Gregory]

Do we have tests that are async (I'd say yes of course) and that could
loose events in a list appender (I do not know)? Are we getting lucky? IOW,
do we have the kind of async tests that end up stressing the system in a
way were we could loose events in a list appender (don't know). If we do
not, should we, is that missing?

Gary

On Thu, Sep 8, 2016 at 4:09 PM, Ralph Goers 
wrote:

> So why are you asking?
>
> Ralph
>
> On Sep 8, 2016, at 2:45 PM, Gary Gregory  wrote:
>
> On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers 
> wrote:
>
>> Why would it? Do you have multiple threads logging? It wasn’t written to
>> be used by anything but single threaded unit tests.
>>
>
> I do not have multiple threads logging in a test but I do not know if
> there is one such test in the whole suite.
>
> Gary
>
>
>>
>> Ralph
>>
>> On Sep 8, 2016, at 1:34 PM, Gary Gregory  wrote:
>>
>> Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all
>> the time or when using in aync tests?
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> 
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> 
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
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: Async tests with ListAppender

[Ralph Goers]

So why are you asking?

Ralph

> On Sep 8, 2016, at 2:45 PM, Gary Gregory  wrote:
> 
> On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers  > wrote:
> Why would it? Do you have multiple threads logging? It wasn’t written to be 
> used by anything but single threaded unit tests.
> 
> I do not have multiple threads logging in a test but I do not know if there 
> is one such test in the whole suite.
> 
> Gary
>  
> 
> Ralph
> 
>> On Sep 8, 2016, at 1:34 PM, Gary Gregory > > wrote:
>> 
>> Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all 
>> the time or when using in aync tests?
>> 
>> Gary
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com  
>> Home: http://garygregory.com/ 
>> Tweet! http://twitter.com/GaryGregory 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 

Jenkins build is still unstable: Log4j 2.x #2285

[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

Re: "sys" properties lookup regression

[Remko Popma]

Good catch!
This must be a regression caused by the change made to support value attribute 
in Property elements (https://issues.apache.org/jira/browse/LOG4J2-1313)

Sent from my iPhone

> On 2016/09/09, at 6:48, Leon Finker  wrote:
> 
> Hi,
> 
> Testing master branch.. We have the following xml configuration:
> ..
> 
> ..
> onMismatch="ACCEPT" />
> -- or you can have  doesn't matter for the 
> issue
> 
> And assume there is no 'additionalProp' System property set.  On master 
> branch, ${sys:additionalProp} doesn't get resolved and remains as literal 
> ${sys:additionalProp}. It's supposed to default to xml specified props, no? 
> This worked up to 2.6.3.
> 
> But if I change the xml prop to be:
>  
> 
> Then ${sys:additionalProp} fallsback to xml defined prop and resolves to 
> empty string.
> 
> 
> 
> -
> 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-1259) Log4j threads are leaking on tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-1259 at 9/8/16 10:19 PM:
---

I've restore binary compatibility for TriggeringPolicy in Git master. I added a 
TODO comment for 3.0 to extend LifeCycle.


was (Author: garydgregory):
I've restore binary compatibility for TriggerPolicy in Git master. I added a 
TODO comment for 3.0 to extend LifeCycle.

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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-1259) Log4j threads are leaking on tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1259:
--

I've restore binary compatibility for TriggerPolicy in Git master. I added a 
TODO comment for 3.0 to extend LifeCycle.

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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

"sys" properties lookup regression

[Leon Finker]

Hi,

Testing master branch.. We have the following xml configuration:
..

..

-- or you can have  doesn't matter for the 
issue

And assume there is no 'additionalProp' System property set.  On master branch, 
${sys:additionalProp} doesn't get resolved and remains as literal 
${sys:additionalProp}. It's supposed to default to xml specified props, no? 
This worked up to 2.6.3.

But if I change the xml prop to be:
 

Then ${sys:additionalProp} fallsback to xml defined prop and resolves to empty 
string.



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

Re: Async tests with ListAppender

[Gary Gregory]

On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers 
wrote:

> Why would it? Do you have multiple threads logging? It wasn’t written to
> be used by anything but single threaded unit tests.
>

I do not have multiple threads logging in a test but I do not know if there
is one such test in the whole suite.

Gary


>
> Ralph
>
> On Sep 8, 2016, at 1:34 PM, Gary Gregory  wrote:
>
> Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all
> the time or when using in aync tests?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Jenkins build is still unstable: Log4j 2.x #2284

[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

Re: Async tests with ListAppender

[Ralph Goers]

Why would it? Do you have multiple threads logging? It wasn’t written to be 
used by anything but single threaded unit tests.

Ralph

> On Sep 8, 2016, at 1:34 PM, Gary Gregory  wrote:
> 
> Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all the 
> time or when using in aync tests?
> 
> 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 

Async tests with ListAppender

[Gary Gregory]

Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all
the time or when using in aync tests?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Gary Gregory]

FWIW: When I look at Pivotal GemFire 8.2.1 (the latest I could get a
non-native version), I see it uses Log4j 2.1.

Gary

On Thu, Sep 8, 2016 at 12:00 PM, Gary Gregory 
wrote:

> What version of Gemfire are you using?
>
> Gary
>
> On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker  wrote:
>
>> Hi,
>>
>> We are using 3rd part library that depends on log4j2 2.3 API. While
>> testing latest log4j2 master, our process fails to start. Unless this API
>> is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
>>
>> [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
>> java.lang.NoSuchMethodError: org.apache.logging.log4j.core.
>> config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/
>> apache/logging/log4j/Level;Ljava/lang/String;Ljava/lang/
>> String;[Lorg/apache/logging/log4j/core/config/AppenderRef;
>> [Lorg/apache/logging/log4j/core/config/Property;Lorg/
>> apache/logging/log4j/core/config/Configuration;Lorg/
>> apache/logging/log4j/core/Filter;)Lorg/apache/logging/log4j/core/config/
>> LoggerConfig;
>> at com.gemstone.gemfire.internal.logging.log4j.Configurator.get
>> OrCreateLoggerConfig(Configurator.java:82) ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.internal.logging.LogService.configureLoggers(LogService.java:98)
>> ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85)
>> ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76)
>> ~[gemfire-8.2.0.13.jar:?]
>> at com.gemstone.gemfire.distributed.internal.DistributionManage
>> r.(DistributionManager.java:133) ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.distributed.DistributedSystem.connect(DistributedSystem.java:1610)
>> ~[gemfire-8.2.0.13.jar:?]
>>
>> Also noticed that you changed XmlConfiguration ctor and require
>> LoggerContext. That's ok since we can change that part. Looks a bit silly:
>> loggerContext.start(new XmlConfiguration(loggerContext, configSource));
>> unless absolutely required, probably not good idea to change the public
>> XmlConfiguration ctor.
>>
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Leon Finker]

Works. Thank you!

On 2016-09-08 14:55 (-0400), Gary Gregory  wrote: 
> I've added back the LoggerConfig.createLogger() factory method in Git
> master. Please try again.
> 
> Gary
> 
> On Thu, Sep 8, 2016 at 11:43 AM, Gary Gregory 
> wrote:
> 
> > Fixing...
> >
> > On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker  wrote:
> >
> >> Hi,
> >>
> >> We are using 3rd part library that depends on log4j2 2.3 API. While
> >> testing latest log4j2 master, our process fails to start. Unless this API
> >> is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
> >>
> >> [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
> >> java.lang.NoSuchMethodError: org.apache.logging.log4j.core.
> >> config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/
> >> apache/logging/log4j/Level;Ljava/lang/String;Ljava/lang/
> >> String;[Lorg/apache/logging/log4j/core/config/AppenderRef;
> >> [Lorg/apache/logging/log4j/core/config/Property;Lorg/
> >> apache/logging/log4j/core/config/Configuration;Lorg/
> >> apache/logging/log4j/core/Filter;)Lorg/apache/logging/log4j/core/config/
> >> LoggerConfig;
> >> at com.gemstone.gemfire.internal.logging.log4j.Configurator.get
> >> OrCreateLoggerConfig(Configurator.java:82) ~[gemfire-8.2.0.13.jar:?]
> >> at 
> >> com.gemstone.gemfire.internal.logging.LogService.configureLoggers(LogService.java:98)
> >> ~[gemfire-8.2.0.13.jar:?]
> >> at 
> >> com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85)
> >> ~[gemfire-8.2.0.13.jar:?]
> >> at 
> >> com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76)
> >> ~[gemfire-8.2.0.13.jar:?]
> >> at com.gemstone.gemfire.distributed.internal.DistributionManage
> >> r.(DistributionManager.java:133) ~[gemfire-8.2.0.13.jar:?]
> >> at 
> >> com.gemstone.gemfire.distributed.DistributedSystem.connect(DistributedSystem.java:1610)
> >> ~[gemfire-8.2.0.13.jar:?]
> >>
> >> Also noticed that you changed XmlConfiguration ctor and require
> >> LoggerContext. That's ok since we can change that part. Looks a bit silly:
> >> loggerContext.start(new XmlConfiguration(loggerContext, configSource));
> >> unless absolutely required, probably not good idea to change the public
> >> XmlConfiguration ctor.
> >>
> >> -
> >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> >>
> >>
> >
> >
> > --
> > 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
> 

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

Jenkins build became unstable: Log4j 2.x #2283

[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] [Created] (LOG4J2-1571) Example of extending Appenders tries to extend from final class OutputStreamAppender

[Adam A. Koch (JIRA)]

Adam A. Koch created LOG4J2-1571:


 Summary: Example of extending Appenders tries to extend from final 
class OutputStreamAppender
 Key: LOG4J2-1571
 URL: https://issues.apache.org/jira/browse/LOG4J2-1571
 Project: Log4j 2
  Issue Type: Documentation
  Components: Documentation
Affects Versions: 2.0
Reporter: Adam A. Koch
Priority: Minor


On the page 
https://logging.apache.org/log4j/2.0/manual/extending.html#Appenders the code 
example StubAppender extends from OutputStreamAppender but that class is final 
and cannot be extended. A better example would be great!



--
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: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Leon Finker]

8.2.0.13. 
-- [gemfire-8.2.0.13.jar:?]

Actually I double checked and they are on 2.1. 
Even latest version 8.2.1.1. I don't think they'll be in any hurry to upgrade.

On 2016-09-08 15:00 (-0400), Gary Gregory  wrote: 
> What version of Gemfire are you using?
> 
> Gary
> 
> On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker  wrote:
> 
> > Hi,
> >
> > We are using 3rd part library that depends on log4j2 2.3 API. While
> > testing latest log4j2 master, our process fails to start. Unless this API
> > is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
> >
> > [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
> > java.lang.NoSuchMethodError: org.apache.logging.log4j.core.
> > config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/apache/logging/
> > log4j/Level;Ljava/lang/String;Ljava/lang/String;[Lorg/
> > apache/logging/log4j/core/config/AppenderRef;[Lorg/
> > apache/logging/log4j/core/config/Property;Lorg/apache/
> > logging/log4j/core/config/Configuration;Lorg/apache/
> > logging/log4j/core/Filter;)Lorg/apache/logging/log4j/
> > core/config/LoggerConfig;
> > at com.gemstone.gemfire.internal.logging.log4j.Configurator.
> > getOrCreateLoggerConfig(Configurator.java:82) ~[gemfire-8.2.0.13.jar:?]
> > at com.gemstone.gemfire.internal.logging.LogService.
> > configureLoggers(LogService.java:98) ~[gemfire-8.2.0.13.jar:?]
> > at 
> > com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85)
> > ~[gemfire-8.2.0.13.jar:?]
> > at 
> > com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76)
> > ~[gemfire-8.2.0.13.jar:?]
> > at com.gemstone.gemfire.distributed.internal.
> > DistributionManager.(DistributionManager.java:133)
> > ~[gemfire-8.2.0.13.jar:?]
> > at com.gemstone.gemfire.distributed.DistributedSystem.
> > connect(DistributedSystem.java:1610) ~[gemfire-8.2.0.13.jar:?]
> >
> > Also noticed that you changed XmlConfiguration ctor and require
> > LoggerContext. That's ok since we can change that part. Looks a bit silly:
> > loggerContext.start(new XmlConfiguration(loggerContext, configSource));
> > unless absolutely required, probably not good idea to change the public
> > XmlConfiguration ctor.
> >
> > -
> > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> >
> >
> 
> 
> -- 
> 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
> 

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

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

[Gary Gregory]

Should they have the same name?

Gary

On Thu, Sep 8, 2016 at 11:24 AM, Matt Sicker  wrote:

> I actually don't know any good reason why they have different names. Most
> of the code used to exist in log4j-core, but a bunch of it was useful in
> log4j-api, so it's been slowly moved to the util package there.
>
> On 8 September 2016 at 13:07, Gary Gregory  wrote:
>
>> I think org.apache.logging.log4j.util.LoaderUtil
>> and org.apache.logging.log4j.core.util.Loader.
>>
>> It's also not clear why one is called "Util" and the other not.
>>
>> This is all probably nit-picking since these are both internal classes
>> but it will help anyone looking at the code including us.
>>
>> It's always nice to document intent.
>>
>> Gary
>>
>> On Thu, Sep 8, 2016 at 10:30 AM, Matt Sicker  wrote:
>>
>>> Which ones?
>>>
>>> On 8 September 2016 at 12:27, Gary Gregory 
>>> wrote:
>>>
 Good to know. Can the Javadocs be improved?

 Gary

 On Thu, Sep 8, 2016 at 9:39 AM, Matt Sicker  wrote:

> I'm not using the loader utils here because we already have the
> ClassLoader required. The use of LoaderUtil tends to be where we don't 
> know
> which ClassLoader to use.
>
> On 8 September 2016 at 11:09, Gary Gregory 
> wrote:
>
>> Hi Matt,
>>
>> When I look at the change in ThrowableProxy that go away from using
>> our Loader utils and go back to loading classes directly I find it
>> confusing: Are the Loader utils broken or are these call sites the wrong
>> use case for the utils? We (you IIRC) have made a point of using these
>> Loader utils (API and Core) to load classes all over, which is nice since
>> we get consistent pattern. So I find it confusing to see it done both 
>> ways
>> in the code overall. Does this warrant a comment in the code? It might 
>> not,
>> I'm just asking the question.
>>
>> Thank you,
>> Gary
>>
>>
>> On Thu, Sep 8, 2016 at 8:29 AM,  wrote:
>>
>>> Repository: logging-log4j2
>>> Updated Branches:
>>>   refs/heads/master 99c0d011d -> 284067cbd
>>>
>>>
>>> Fix class loader deadlock when using async logging and extended
>>> stack trace pattern
>>>
>>> This fixes LOG4J2-1457.
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
>>> /284067cb
>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/2
>>> 84067cb
>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/2
>>> 84067cb
>>>
>>> Branch: refs/heads/master
>>> Commit: 284067cbdb5f13c41225e22c2a60d79cd43f1383
>>> Parents: 99c0d01
>>> Author: Matt Sicker 
>>> Authored: Thu Sep 8 10:30:12 2016 -0500
>>> Committer: Matt Sicker 
>>> Committed: Thu Sep 8 10:30:12 2016 -0500
>>>
>>> 
>>> --
>>>  .../logging/log4j/core/impl/ThrowableProxy.java |  9 ++--
>>>  .../async/AsyncLoggerClassLoadDeadlock.java | 32 ++
>>>  .../async/AsyncLoggerClassLoadDeadlockTest.java | 45
>>> 
>>>  .../test/resources/AsyncLoggerConsoleTest.xml   | 16 +++
>>>  src/changes/changes.xml |  3 ++
>>>  5 files changed, 100 insertions(+), 5 deletions(-)
>>> 
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
>>> 84067cb/log4j-core/src/main/java/org/apache/logging/log4j/co
>>> re/impl/ThrowableProxy.java
>>> 
>>> --
>>> diff --git a/log4j-core/src/main/java/org
>>> /apache/logging/log4j/core/impl/ThrowableProxy.java
>>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>>> l/ThrowableProxy.java
>>> index a052e4d..e12e14a 100644
>>> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>>> l/ThrowableProxy.java
>>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>>> l/ThrowableProxy.java
>>> @@ -30,7 +30,6 @@ import java.util.Stack;
>>>
>>>  import org.apache.logging.log4j.core.pattern.PlainTextRenderer;
>>>  import org.apache.logging.log4j.core.pattern.TextRenderer;
>>> -import org.apache.logging.log4j.core.util.Loader;
>>>  import org.apache.logging.log4j.status.StatusLogger;
>>>  import org.apache.logging.log4j.util.LoaderUtil;
>>>  import org.apache.logging.log4j.util.ReflectionUtil;
>>> @@ -537,7 +536,7 @@ public class ThrowableProxy implements
>>> Serializable {
>>>  

[jira] [Closed] (LOG4J2-1546) Remove deprecated Core API Remove deprecated Core API org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, String, String , AppenderRef[] refs, P

[Gary Gregory (JIRA)]

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

Gary Gregory closed LOG4J2-1546.


> Remove deprecated Core API Remove deprecated Core API 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, 
> String, String , AppenderRef[] refs, Property[], Configuration config, 
> Filter).
> ---
>
> Key: LOG4J2-1546
> URL: https://issues.apache.org/jira/browse/LOG4J2-1546
> Project: Log4j 2
>  Issue Type: Task
>Reporter: Gary Gregory
>
> Remove deprecated Core API:
> {{org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, 
> Level, String, String , AppenderRef[] refs, Property[], Configuration config, 
> Filter)}}; 
> use:
> {{org.apache.logging.log4j.core.config.LoggerConfig.createLogger(boolean, 
> Level, String, String, AppenderRef[], Property[], Configuration, Filter)}}.



--
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: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Gary Gregory]

What version of Gemfire are you using?

Gary

On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker  wrote:

> Hi,
>
> We are using 3rd part library that depends on log4j2 2.3 API. While
> testing latest log4j2 master, our process fails to start. Unless this API
> is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
>
> [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
> java.lang.NoSuchMethodError: org.apache.logging.log4j.core.
> config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/apache/logging/
> log4j/Level;Ljava/lang/String;Ljava/lang/String;[Lorg/
> apache/logging/log4j/core/config/AppenderRef;[Lorg/
> apache/logging/log4j/core/config/Property;Lorg/apache/
> logging/log4j/core/config/Configuration;Lorg/apache/
> logging/log4j/core/Filter;)Lorg/apache/logging/log4j/
> core/config/LoggerConfig;
> at com.gemstone.gemfire.internal.logging.log4j.Configurator.
> getOrCreateLoggerConfig(Configurator.java:82) ~[gemfire-8.2.0.13.jar:?]
> at com.gemstone.gemfire.internal.logging.LogService.
> configureLoggers(LogService.java:98) ~[gemfire-8.2.0.13.jar:?]
> at 
> com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85)
> ~[gemfire-8.2.0.13.jar:?]
> at 
> com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76)
> ~[gemfire-8.2.0.13.jar:?]
> at com.gemstone.gemfire.distributed.internal.
> DistributionManager.(DistributionManager.java:133)
> ~[gemfire-8.2.0.13.jar:?]
> at com.gemstone.gemfire.distributed.DistributedSystem.
> connect(DistributedSystem.java:1610) ~[gemfire-8.2.0.13.jar:?]
>
> Also noticed that you changed XmlConfiguration ctor and require
> LoggerContext. That's ok since we can change that part. Looks a bit silly:
> loggerContext.start(new XmlConfiguration(loggerContext, configSource));
> unless absolutely required, probably not good idea to change the public
> XmlConfiguration ctor.
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>


-- 
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] [Resolved] (LOG4J2-1546) Remove deprecated Core API Remove deprecated Core API org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, String, String , AppenderRef[] refs,

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-1546.
--
Resolution: Won't Fix

Reverted commit and resolving as "Won't Fix". A user reported breakage in a 3rd 
party library.

> Remove deprecated Core API Remove deprecated Core API 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, 
> String, String , AppenderRef[] refs, Property[], Configuration config, 
> Filter).
> ---
>
> Key: LOG4J2-1546
> URL: https://issues.apache.org/jira/browse/LOG4J2-1546
> Project: Log4j 2
>  Issue Type: Task
>Reporter: Gary Gregory
>
> Remove deprecated Core API:
> {{org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, 
> Level, String, String , AppenderRef[] refs, Property[], Configuration config, 
> Filter)}}; 
> use:
> {{org.apache.logging.log4j.core.config.LoggerConfig.createLogger(boolean, 
> Level, String, String, AppenderRef[], Property[], Configuration, Filter)}}.



--
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] [Reopened] (LOG4J2-1546) Remove deprecated Core API Remove deprecated Core API org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, String, String , AppenderRef[] refs,

[Gary Gregory (JIRA)]

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

Gary Gregory reopened LOG4J2-1546:
--

> Remove deprecated Core API Remove deprecated Core API 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, 
> String, String , AppenderRef[] refs, Property[], Configuration config, 
> Filter).
> ---
>
> Key: LOG4J2-1546
> URL: https://issues.apache.org/jira/browse/LOG4J2-1546
> Project: Log4j 2
>  Issue Type: Task
>Reporter: Gary Gregory
>
> Remove deprecated Core API:
> {{org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, 
> Level, String, String , AppenderRef[] refs, Property[], Configuration config, 
> Filter)}}; 
> use:
> {{org.apache.logging.log4j.core.config.LoggerConfig.createLogger(boolean, 
> Level, String, String, AppenderRef[], Property[], Configuration, Filter)}}.



--
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: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Gary Gregory]

I've added back the LoggerConfig.createLogger() factory method in Git
master. Please try again.

Gary

On Thu, Sep 8, 2016 at 11:43 AM, Gary Gregory 
wrote:

> Fixing...
>
> On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker  wrote:
>
>> Hi,
>>
>> We are using 3rd part library that depends on log4j2 2.3 API. While
>> testing latest log4j2 master, our process fails to start. Unless this API
>> is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
>>
>> [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
>> java.lang.NoSuchMethodError: org.apache.logging.log4j.core.
>> config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/
>> apache/logging/log4j/Level;Ljava/lang/String;Ljava/lang/
>> String;[Lorg/apache/logging/log4j/core/config/AppenderRef;
>> [Lorg/apache/logging/log4j/core/config/Property;Lorg/
>> apache/logging/log4j/core/config/Configuration;Lorg/
>> apache/logging/log4j/core/Filter;)Lorg/apache/logging/log4j/core/config/
>> LoggerConfig;
>> at com.gemstone.gemfire.internal.logging.log4j.Configurator.get
>> OrCreateLoggerConfig(Configurator.java:82) ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.internal.logging.LogService.configureLoggers(LogService.java:98)
>> ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85)
>> ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76)
>> ~[gemfire-8.2.0.13.jar:?]
>> at com.gemstone.gemfire.distributed.internal.DistributionManage
>> r.(DistributionManager.java:133) ~[gemfire-8.2.0.13.jar:?]
>> at 
>> com.gemstone.gemfire.distributed.DistributedSystem.connect(DistributedSystem.java:1610)
>> ~[gemfire-8.2.0.13.jar:?]
>>
>> Also noticed that you changed XmlConfiguration ctor and require
>> LoggerContext. That's ok since we can change that part. Looks a bit silly:
>> loggerContext.start(new XmlConfiguration(loggerContext, configSource));
>> unless absolutely required, probably not good idea to change the public
>> XmlConfiguration ctor.
>>
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Gary Gregory]

Fixing...

On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker  wrote:

> Hi,
>
> We are using 3rd part library that depends on log4j2 2.3 API. While
> testing latest log4j2 master, our process fails to start. Unless this API
> is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
>
> [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
> java.lang.NoSuchMethodError: org.apache.logging.log4j.core.
> config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/apache/logging/
> log4j/Level;Ljava/lang/String;Ljava/lang/String;[Lorg/
> apache/logging/log4j/core/config/AppenderRef;[Lorg/
> apache/logging/log4j/core/config/Property;Lorg/apache/
> logging/log4j/core/config/Configuration;Lorg/apache/
> logging/log4j/core/Filter;)Lorg/apache/logging/log4j/
> core/config/LoggerConfig;
> at com.gemstone.gemfire.internal.logging.log4j.Configurator.
> getOrCreateLoggerConfig(Configurator.java:82) ~[gemfire-8.2.0.13.jar:?]
> at com.gemstone.gemfire.internal.logging.LogService.
> configureLoggers(LogService.java:98) ~[gemfire-8.2.0.13.jar:?]
> at 
> com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85)
> ~[gemfire-8.2.0.13.jar:?]
> at 
> com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76)
> ~[gemfire-8.2.0.13.jar:?]
> at com.gemstone.gemfire.distributed.internal.
> DistributionManager.(DistributionManager.java:133)
> ~[gemfire-8.2.0.13.jar:?]
> at com.gemstone.gemfire.distributed.DistributedSystem.
> connect(DistributedSystem.java:1610) ~[gemfire-8.2.0.13.jar:?]
>
> Also noticed that you changed XmlConfiguration ctor and require
> LoggerContext. That's ok since we can change that part. Looks a bit silly:
> loggerContext.start(new XmlConfiguration(loggerContext, configSource));
> unless absolutely required, probably not good idea to change the public
> XmlConfiguration ctor.
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>


-- 
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: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

[Matt Sicker]

I actually don't know any good reason why they have different names. Most
of the code used to exist in log4j-core, but a bunch of it was useful in
log4j-api, so it's been slowly moved to the util package there.

On 8 September 2016 at 13:07, Gary Gregory  wrote:

> I think org.apache.logging.log4j.util.LoaderUtil
> and org.apache.logging.log4j.core.util.Loader.
>
> It's also not clear why one is called "Util" and the other not.
>
> This is all probably nit-picking since these are both internal classes but
> it will help anyone looking at the code including us.
>
> It's always nice to document intent.
>
> Gary
>
> On Thu, Sep 8, 2016 at 10:30 AM, Matt Sicker  wrote:
>
>> Which ones?
>>
>> On 8 September 2016 at 12:27, Gary Gregory 
>> wrote:
>>
>>> Good to know. Can the Javadocs be improved?
>>>
>>> Gary
>>>
>>> On Thu, Sep 8, 2016 at 9:39 AM, Matt Sicker  wrote:
>>>
 I'm not using the loader utils here because we already have the
 ClassLoader required. The use of LoaderUtil tends to be where we don't know
 which ClassLoader to use.

 On 8 September 2016 at 11:09, Gary Gregory 
 wrote:

> Hi Matt,
>
> When I look at the change in ThrowableProxy that go away from using
> our Loader utils and go back to loading classes directly I find it
> confusing: Are the Loader utils broken or are these call sites the wrong
> use case for the utils? We (you IIRC) have made a point of using these
> Loader utils (API and Core) to load classes all over, which is nice since
> we get consistent pattern. So I find it confusing to see it done both ways
> in the code overall. Does this warrant a comment in the code? It might 
> not,
> I'm just asking the question.
>
> Thank you,
> Gary
>
>
> On Thu, Sep 8, 2016 at 8:29 AM,  wrote:
>
>> Repository: logging-log4j2
>> Updated Branches:
>>   refs/heads/master 99c0d011d -> 284067cbd
>>
>>
>> Fix class loader deadlock when using async logging and extended stack
>> trace pattern
>>
>> This fixes LOG4J2-1457.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
>> /284067cb
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/2
>> 84067cb
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/2
>> 84067cb
>>
>> Branch: refs/heads/master
>> Commit: 284067cbdb5f13c41225e22c2a60d79cd43f1383
>> Parents: 99c0d01
>> Author: Matt Sicker 
>> Authored: Thu Sep 8 10:30:12 2016 -0500
>> Committer: Matt Sicker 
>> Committed: Thu Sep 8 10:30:12 2016 -0500
>>
>> 
>> --
>>  .../logging/log4j/core/impl/ThrowableProxy.java |  9 ++--
>>  .../async/AsyncLoggerClassLoadDeadlock.java | 32 ++
>>  .../async/AsyncLoggerClassLoadDeadlockTest.java | 45
>> 
>>  .../test/resources/AsyncLoggerConsoleTest.xml   | 16 +++
>>  src/changes/changes.xml |  3 ++
>>  5 files changed, 100 insertions(+), 5 deletions(-)
>> 
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
>> 84067cb/log4j-core/src/main/java/org/apache/logging/log4j/co
>> re/impl/ThrowableProxy.java
>> 
>> --
>> diff --git a/log4j-core/src/main/java/org
>> /apache/logging/log4j/core/impl/ThrowableProxy.java
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>> l/ThrowableProxy.java
>> index a052e4d..e12e14a 100644
>> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>> l/ThrowableProxy.java
>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>> l/ThrowableProxy.java
>> @@ -30,7 +30,6 @@ import java.util.Stack;
>>
>>  import org.apache.logging.log4j.core.pattern.PlainTextRenderer;
>>  import org.apache.logging.log4j.core.pattern.TextRenderer;
>> -import org.apache.logging.log4j.core.util.Loader;
>>  import org.apache.logging.log4j.status.StatusLogger;
>>  import org.apache.logging.log4j.util.LoaderUtil;
>>  import org.apache.logging.log4j.util.ReflectionUtil;
>> @@ -537,7 +536,7 @@ public class ThrowableProxy implements
>> Serializable {
>>  Class clazz;
>>  if (lastLoader != null) {
>>  try {
>> -clazz = Loader.initializeClass(className,
>> lastLoader);
>> +clazz = lastLoader.loadClass(className);
>> 

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

[Gary Gregory]

I think org.apache.logging.log4j.util.LoaderUtil
and org.apache.logging.log4j.core.util.Loader.

It's also not clear why one is called "Util" and the other not.

This is all probably nit-picking since these are both internal classes but
it will help anyone looking at the code including us.

It's always nice to document intent.

Gary

On Thu, Sep 8, 2016 at 10:30 AM, Matt Sicker  wrote:

> Which ones?
>
> On 8 September 2016 at 12:27, Gary Gregory  wrote:
>
>> Good to know. Can the Javadocs be improved?
>>
>> Gary
>>
>> On Thu, Sep 8, 2016 at 9:39 AM, Matt Sicker  wrote:
>>
>>> I'm not using the loader utils here because we already have the
>>> ClassLoader required. The use of LoaderUtil tends to be where we don't know
>>> which ClassLoader to use.
>>>
>>> On 8 September 2016 at 11:09, Gary Gregory 
>>> wrote:
>>>
 Hi Matt,

 When I look at the change in ThrowableProxy that go away from using our
 Loader utils and go back to loading classes directly I find it confusing:
 Are the Loader utils broken or are these call sites the wrong use case for
 the utils? We (you IIRC) have made a point of using these Loader utils (API
 and Core) to load classes all over, which is nice since we get consistent
 pattern. So I find it confusing to see it done both ways in the code
 overall. Does this warrant a comment in the code? It might not, I'm just
 asking the question.

 Thank you,
 Gary


 On Thu, Sep 8, 2016 at 8:29 AM,  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master 99c0d011d -> 284067cbd
>
>
> Fix class loader deadlock when using async logging and extended stack
> trace pattern
>
> This fixes LOG4J2-1457.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
> /284067cb
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/2
> 84067cb
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/2
> 84067cb
>
> Branch: refs/heads/master
> Commit: 284067cbdb5f13c41225e22c2a60d79cd43f1383
> Parents: 99c0d01
> Author: Matt Sicker 
> Authored: Thu Sep 8 10:30:12 2016 -0500
> Committer: Matt Sicker 
> Committed: Thu Sep 8 10:30:12 2016 -0500
>
> --
>  .../logging/log4j/core/impl/ThrowableProxy.java |  9 ++--
>  .../async/AsyncLoggerClassLoadDeadlock.java | 32 ++
>  .../async/AsyncLoggerClassLoadDeadlockTest.java | 45
> 
>  .../test/resources/AsyncLoggerConsoleTest.xml   | 16 +++
>  src/changes/changes.xml |  3 ++
>  5 files changed, 100 insertions(+), 5 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
> 84067cb/log4j-core/src/main/java/org/apache/logging/log4j/co
> re/impl/ThrowableProxy.java
> --
> diff --git a/log4j-core/src/main/java/org
> /apache/logging/log4j/core/impl/ThrowableProxy.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
> l/ThrowableProxy.java
> index a052e4d..e12e14a 100644
> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
> l/ThrowableProxy.java
> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
> l/ThrowableProxy.java
> @@ -30,7 +30,6 @@ import java.util.Stack;
>
>  import org.apache.logging.log4j.core.pattern.PlainTextRenderer;
>  import org.apache.logging.log4j.core.pattern.TextRenderer;
> -import org.apache.logging.log4j.core.util.Loader;
>  import org.apache.logging.log4j.status.StatusLogger;
>  import org.apache.logging.log4j.util.LoaderUtil;
>  import org.apache.logging.log4j.util.ReflectionUtil;
> @@ -537,7 +536,7 @@ public class ThrowableProxy implements
> Serializable {
>  Class clazz;
>  if (lastLoader != null) {
>  try {
> -clazz = Loader.initializeClass(className,
> lastLoader);
> +clazz = lastLoader.loadClass(className);
>  if (clazz != null) {
>  return clazz;
>  }
> @@ -548,16 +547,16 @@ public class ThrowableProxy implements
> Serializable {
>  try {
>  clazz = LoaderUtil.loadClass(className);
>  } catch (final ClassNotFoundException | NoClassDefFoundError
> e) {
> -return initializeClass(className);
> +return 

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Leon Finker]

It's this commit facb281ba2f5f83903a7aedf385f83d7f9520561
* Remove internal method that is @deprecated Use {@link
#createLogger(boolean, Level, String, String, AppenderRef[], Property[],
Configuration, Filter)}

But it was public, not internal. In any case I wouldn't care if major 3rd party 
library didn't make use of it. And there is no way to change that. If it was 
under our control, we would update our source to new api.



On 2016-09-08 13:49 (-0400), Ralph Goers  wrote: 
> Thanks for pointing this out. There is currently a discussion on the dev list 
> about what we want to remain backward compatible in Log4j core. AppenderRef 
> is certainly one of the things that should be.
> 
> Ralph
> 
> > On Sep 8, 2016, at 10:40 AM, Leon Finker  wrote:
> > 
> > Hi,
> > 
> > We are using 3rd part library that depends on log4j2 2.3 API. While testing 
> > latest log4j2 master, our process fails to start. Unless this API is 
> > compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
> > 
> > [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
> > java.lang.NoSuchMethodError: 
> > org.apache.logging.log4j.core.config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/apache/logging/log4j/Level;Ljava/lang/String;Ljava/lang/String;[Lorg/apache/logging/log4j/core/config/AppenderRef;[Lorg/apache/logging/log4j/core/config/Property;Lorg/apache/logging/log4j/core/config/Configuration;Lorg/apache/logging/log4j/core/Filter;)Lorg/apache/logging/log4j/core/config/LoggerConfig;
> > at 
> > com.gemstone.gemfire.internal.logging.log4j.Configurator.getOrCreateLoggerConfig(Configurator.java:82)
> >  ~[gemfire-8.2.0.13.jar:?]
> > at 
> > com.gemstone.gemfire.internal.logging.LogService.configureLoggers(LogService.java:98)
> >  ~[gemfire-8.2.0.13.jar:?]
> > at 
> > com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85) 
> > ~[gemfire-8.2.0.13.jar:?]
> > at 
> > com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76)
> >  ~[gemfire-8.2.0.13.jar:?]
> > at 
> > com.gemstone.gemfire.distributed.internal.DistributionManager.(DistributionManager.java:133)
> >  ~[gemfire-8.2.0.13.jar:?]
> > at 
> > com.gemstone.gemfire.distributed.DistributedSystem.connect(DistributedSystem.java:1610)
> >  ~[gemfire-8.2.0.13.jar:?]
> > 
> > Also noticed that you changed XmlConfiguration ctor and require 
> > LoggerContext. That's ok since we can change that part. Looks a bit silly:
> > loggerContext.start(new XmlConfiguration(loggerContext, configSource));
> > unless absolutely required, probably not good idea to change the public 
> > XmlConfiguration ctor.
> > 
> > -
> > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> > 
> > 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 
> 

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

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Ralph Goers]

Thanks for pointing this out. There is currently a discussion on the dev list 
about what we want to remain backward compatible in Log4j core. AppenderRef is 
certainly one of the things that should be.

Ralph

> On Sep 8, 2016, at 10:40 AM, Leon Finker  wrote:
> 
> Hi,
> 
> We are using 3rd part library that depends on log4j2 2.3 API. While testing 
> latest log4j2 master, our process fails to start. Unless this API is 
> compatible there is no way to upgrade to log4j2 2.7. Can this be fixed?
> 
> [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
> java.lang.NoSuchMethodError: 
> org.apache.logging.log4j.core.config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/apache/logging/log4j/Level;Ljava/lang/String;Ljava/lang/String;[Lorg/apache/logging/log4j/core/config/AppenderRef;[Lorg/apache/logging/log4j/core/config/Property;Lorg/apache/logging/log4j/core/config/Configuration;Lorg/apache/logging/log4j/core/Filter;)Lorg/apache/logging/log4j/core/config/LoggerConfig;
>   at 
> com.gemstone.gemfire.internal.logging.log4j.Configurator.getOrCreateLoggerConfig(Configurator.java:82)
>  ~[gemfire-8.2.0.13.jar:?]
>   at 
> com.gemstone.gemfire.internal.logging.LogService.configureLoggers(LogService.java:98)
>  ~[gemfire-8.2.0.13.jar:?]
>   at 
> com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85) 
> ~[gemfire-8.2.0.13.jar:?]
>   at 
> com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76) 
> ~[gemfire-8.2.0.13.jar:?]
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.(DistributionManager.java:133)
>  ~[gemfire-8.2.0.13.jar:?]
>   at 
> com.gemstone.gemfire.distributed.DistributedSystem.connect(DistributedSystem.java:1610)
>  ~[gemfire-8.2.0.13.jar:?]
> 
> Also noticed that you changed XmlConfiguration ctor and require 
> LoggerContext. That's ok since we can change that part. Looks a bit silly:
> loggerContext.start(new XmlConfiguration(loggerContext, configSource));
> unless absolutely required, probably not good idea to change the public 
> XmlConfiguration ctor.
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 
> 



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

2.6.3-SNAPSHOT java.lang.NoSuchMethodError

[Leon Finker]

Hi,

We are using 3rd part library that depends on log4j2 2.3 API. While testing 
latest log4j2 master, our process fails to start. Unless this API is compatible 
there is no way to upgrade to log4j2 2.7. Can this be fixed?

[2016-09-08 17:16:54,153Z][FATAL][main:0xf][...]
java.lang.NoSuchMethodError: 
org.apache.logging.log4j.core.config.LoggerConfig.createLogger(Ljava/lang/String;Lorg/apache/logging/log4j/Level;Ljava/lang/String;Ljava/lang/String;[Lorg/apache/logging/log4j/core/config/AppenderRef;[Lorg/apache/logging/log4j/core/config/Property;Lorg/apache/logging/log4j/core/config/Configuration;Lorg/apache/logging/log4j/core/Filter;)Lorg/apache/logging/log4j/core/config/LoggerConfig;
at 
com.gemstone.gemfire.internal.logging.log4j.Configurator.getOrCreateLoggerConfig(Configurator.java:82)
 ~[gemfire-8.2.0.13.jar:?]
at 
com.gemstone.gemfire.internal.logging.LogService.configureLoggers(LogService.java:98)
 ~[gemfire-8.2.0.13.jar:?]
at 
com.gemstone.gemfire.internal.logging.LogService.init(LogService.java:85) 
~[gemfire-8.2.0.13.jar:?]
at 
com.gemstone.gemfire.internal.logging.LogService.(LogService.java:76) 
~[gemfire-8.2.0.13.jar:?]
at 
com.gemstone.gemfire.distributed.internal.DistributionManager.(DistributionManager.java:133)
 ~[gemfire-8.2.0.13.jar:?]
at 
com.gemstone.gemfire.distributed.DistributedSystem.connect(DistributedSystem.java:1610)
 ~[gemfire-8.2.0.13.jar:?]

Also noticed that you changed XmlConfiguration ctor and require LoggerContext. 
That's ok since we can change that part. Looks a bit silly:
loggerContext.start(new XmlConfiguration(loggerContext, configSource));
unless absolutely required, probably not good idea to change the public 
XmlConfiguration ctor.

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

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

[Matt Sicker]

Which ones?

On 8 September 2016 at 12:27, Gary Gregory  wrote:

> Good to know. Can the Javadocs be improved?
>
> Gary
>
> On Thu, Sep 8, 2016 at 9:39 AM, Matt Sicker  wrote:
>
>> I'm not using the loader utils here because we already have the
>> ClassLoader required. The use of LoaderUtil tends to be where we don't know
>> which ClassLoader to use.
>>
>> On 8 September 2016 at 11:09, Gary Gregory 
>> wrote:
>>
>>> Hi Matt,
>>>
>>> When I look at the change in ThrowableProxy that go away from using our
>>> Loader utils and go back to loading classes directly I find it confusing:
>>> Are the Loader utils broken or are these call sites the wrong use case for
>>> the utils? We (you IIRC) have made a point of using these Loader utils (API
>>> and Core) to load classes all over, which is nice since we get consistent
>>> pattern. So I find it confusing to see it done both ways in the code
>>> overall. Does this warrant a comment in the code? It might not, I'm just
>>> asking the question.
>>>
>>> Thank you,
>>> Gary
>>>
>>>
>>> On Thu, Sep 8, 2016 at 8:29 AM,  wrote:
>>>
 Repository: logging-log4j2
 Updated Branches:
   refs/heads/master 99c0d011d -> 284067cbd


 Fix class loader deadlock when using async logging and extended stack
 trace pattern

 This fixes LOG4J2-1457.


 Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
 Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
 /284067cb
 Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/2
 84067cb
 Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/2
 84067cb

 Branch: refs/heads/master
 Commit: 284067cbdb5f13c41225e22c2a60d79cd43f1383
 Parents: 99c0d01
 Author: Matt Sicker 
 Authored: Thu Sep 8 10:30:12 2016 -0500
 Committer: Matt Sicker 
 Committed: Thu Sep 8 10:30:12 2016 -0500

 --
  .../logging/log4j/core/impl/ThrowableProxy.java |  9 ++--
  .../async/AsyncLoggerClassLoadDeadlock.java | 32 ++
  .../async/AsyncLoggerClassLoadDeadlockTest.java | 45
 
  .../test/resources/AsyncLoggerConsoleTest.xml   | 16 +++
  src/changes/changes.xml |  3 ++
  5 files changed, 100 insertions(+), 5 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
 84067cb/log4j-core/src/main/java/org/apache/logging/log4j/co
 re/impl/ThrowableProxy.java
 --
 diff --git 
 a/log4j-core/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java
 b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
 l/ThrowableProxy.java
 index a052e4d..e12e14a 100644
 --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
 l/ThrowableProxy.java
 +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
 l/ThrowableProxy.java
 @@ -30,7 +30,6 @@ import java.util.Stack;

  import org.apache.logging.log4j.core.pattern.PlainTextRenderer;
  import org.apache.logging.log4j.core.pattern.TextRenderer;
 -import org.apache.logging.log4j.core.util.Loader;
  import org.apache.logging.log4j.status.StatusLogger;
  import org.apache.logging.log4j.util.LoaderUtil;
  import org.apache.logging.log4j.util.ReflectionUtil;
 @@ -537,7 +536,7 @@ public class ThrowableProxy implements Serializable
 {
  Class clazz;
  if (lastLoader != null) {
  try {
 -clazz = Loader.initializeClass(className, lastLoader);
 +clazz = lastLoader.loadClass(className);
  if (clazz != null) {
  return clazz;
  }
 @@ -548,16 +547,16 @@ public class ThrowableProxy implements
 Serializable {
  try {
  clazz = LoaderUtil.loadClass(className);
  } catch (final ClassNotFoundException | NoClassDefFoundError
 e) {
 -return initializeClass(className);
 +return loadClass(className);
  } catch (final SecurityException e) {
  return null;
  }
  return clazz;
  }

 -private Class initializeClass(final String className) {
 +private Class loadClass(final String className) {
  try {
 -return Loader.initializeClass(className,
 this.getClass().getClassLoader());
 +return this.getClass().getClassLoader
 ().loadClass(className);
  } catch (final 

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

[Gary Gregory]

Good to know. Can the Javadocs be improved?

Gary

On Thu, Sep 8, 2016 at 9:39 AM, Matt Sicker  wrote:

> I'm not using the loader utils here because we already have the
> ClassLoader required. The use of LoaderUtil tends to be where we don't know
> which ClassLoader to use.
>
> On 8 September 2016 at 11:09, Gary Gregory  wrote:
>
>> Hi Matt,
>>
>> When I look at the change in ThrowableProxy that go away from using our
>> Loader utils and go back to loading classes directly I find it confusing:
>> Are the Loader utils broken or are these call sites the wrong use case for
>> the utils? We (you IIRC) have made a point of using these Loader utils (API
>> and Core) to load classes all over, which is nice since we get consistent
>> pattern. So I find it confusing to see it done both ways in the code
>> overall. Does this warrant a comment in the code? It might not, I'm just
>> asking the question.
>>
>> Thank you,
>> Gary
>>
>>
>> On Thu, Sep 8, 2016 at 8:29 AM,  wrote:
>>
>>> Repository: logging-log4j2
>>> Updated Branches:
>>>   refs/heads/master 99c0d011d -> 284067cbd
>>>
>>>
>>> Fix class loader deadlock when using async logging and extended stack
>>> trace pattern
>>>
>>> This fixes LOG4J2-1457.
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
>>> /284067cb
>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/2
>>> 84067cb
>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/2
>>> 84067cb
>>>
>>> Branch: refs/heads/master
>>> Commit: 284067cbdb5f13c41225e22c2a60d79cd43f1383
>>> Parents: 99c0d01
>>> Author: Matt Sicker 
>>> Authored: Thu Sep 8 10:30:12 2016 -0500
>>> Committer: Matt Sicker 
>>> Committed: Thu Sep 8 10:30:12 2016 -0500
>>>
>>> --
>>>  .../logging/log4j/core/impl/ThrowableProxy.java |  9 ++--
>>>  .../async/AsyncLoggerClassLoadDeadlock.java | 32 ++
>>>  .../async/AsyncLoggerClassLoadDeadlockTest.java | 45
>>> 
>>>  .../test/resources/AsyncLoggerConsoleTest.xml   | 16 +++
>>>  src/changes/changes.xml |  3 ++
>>>  5 files changed, 100 insertions(+), 5 deletions(-)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
>>> 84067cb/log4j-core/src/main/java/org/apache/logging/log4j/co
>>> re/impl/ThrowableProxy.java
>>> --
>>> diff --git 
>>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java
>>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>>> l/ThrowableProxy.java
>>> index a052e4d..e12e14a 100644
>>> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>>> l/ThrowableProxy.java
>>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>>> l/ThrowableProxy.java
>>> @@ -30,7 +30,6 @@ import java.util.Stack;
>>>
>>>  import org.apache.logging.log4j.core.pattern.PlainTextRenderer;
>>>  import org.apache.logging.log4j.core.pattern.TextRenderer;
>>> -import org.apache.logging.log4j.core.util.Loader;
>>>  import org.apache.logging.log4j.status.StatusLogger;
>>>  import org.apache.logging.log4j.util.LoaderUtil;
>>>  import org.apache.logging.log4j.util.ReflectionUtil;
>>> @@ -537,7 +536,7 @@ public class ThrowableProxy implements Serializable {
>>>  Class clazz;
>>>  if (lastLoader != null) {
>>>  try {
>>> -clazz = Loader.initializeClass(className, lastLoader);
>>> +clazz = lastLoader.loadClass(className);
>>>  if (clazz != null) {
>>>  return clazz;
>>>  }
>>> @@ -548,16 +547,16 @@ public class ThrowableProxy implements
>>> Serializable {
>>>  try {
>>>  clazz = LoaderUtil.loadClass(className);
>>>  } catch (final ClassNotFoundException | NoClassDefFoundError e)
>>> {
>>> -return initializeClass(className);
>>> +return loadClass(className);
>>>  } catch (final SecurityException e) {
>>>  return null;
>>>  }
>>>  return clazz;
>>>  }
>>>
>>> -private Class initializeClass(final String className) {
>>> +private Class loadClass(final String className) {
>>>  try {
>>> -return Loader.initializeClass(className,
>>> this.getClass().getClassLoader());
>>> +return this.getClass().getClassLoader
>>> ().loadClass(className);
>>>  } catch (final ClassNotFoundException | NoClassDefFoundError |
>>> SecurityException e) {
>>>  return null;
>>>  }
>>>
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
>>> 

[jira] [Closed] (LOG4J2-1457) Class loader deadlock when using async logging and extended stack trace pattern

[Matt Sicker (JIRA)]

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

Matt Sicker closed LOG4J2-1457.
---

Thanks for the confirmation and the help fixing this!

> Class loader deadlock when using async logging and extended stack trace 
> pattern
> ---
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
>Reporter: Leon Finker
>Assignee: Matt Sicker
>Priority: Critical
> Fix For: 2.7
>
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread 
> dump. Is it possible to have an option of pre-initializing the exception's 
> thread stack on the caller's thread? It's hard to predict what libraries are 
> doing in their classes' static initializers and may eventually end up logging 
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0 
> tid=0x7ff870c7b000 nid=0x79f3 in Object.wait() [0x7ff839142000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x7ff871677000 
> nid=0x725 runnable [0x7ff74bd27000]
> ..



--
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-1457) Class loader deadlock when using async logging and extended stack trace pattern

[Leon Finker (JIRA)]

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

Leon Finker commented on LOG4J2-1457:
-

Confirmed. NOTE: now that log42 is using DefaultAsyncQueueFullPolicy with 
EventRoute.SYNCHRONOUS, the deadlock will not happen in any case. In order to 
reproduce one would have to use EventRoute.ENQUEUE, with which I tested this 
fix. Before this fix deadlock happens. After this fix deadlock doesn't happen.

> Class loader deadlock when using async logging and extended stack trace 
> pattern
> ---
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
>Reporter: Leon Finker
>Assignee: Matt Sicker
>Priority: Critical
> Fix For: 2.7
>
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread 
> dump. Is it possible to have an option of pre-initializing the exception's 
> thread stack on the caller's thread? It's hard to predict what libraries are 
> doing in their classes' static initializers and may eventually end up logging 
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0 
> tid=0x7ff870c7b000 nid=0x79f3 in Object.wait() [0x7ff839142000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x7ff871677000 
> nid=0x725 runnable [0x7ff74bd27000]
> ..



--
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: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

[Matt Sicker]

I'm not using the loader utils here because we already have the ClassLoader
required. The use of LoaderUtil tends to be where we don't know which
ClassLoader to use.

On 8 September 2016 at 11:09, Gary Gregory  wrote:

> Hi Matt,
>
> When I look at the change in ThrowableProxy that go away from using our
> Loader utils and go back to loading classes directly I find it confusing:
> Are the Loader utils broken or are these call sites the wrong use case for
> the utils? We (you IIRC) have made a point of using these Loader utils (API
> and Core) to load classes all over, which is nice since we get consistent
> pattern. So I find it confusing to see it done both ways in the code
> overall. Does this warrant a comment in the code? It might not, I'm just
> asking the question.
>
> Thank you,
> Gary
>
>
> On Thu, Sep 8, 2016 at 8:29 AM,  wrote:
>
>> Repository: logging-log4j2
>> Updated Branches:
>>   refs/heads/master 99c0d011d -> 284067cbd
>>
>>
>> Fix class loader deadlock when using async logging and extended stack
>> trace pattern
>>
>> This fixes LOG4J2-1457.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
>> /284067cb
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/284067cb
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/284067cb
>>
>> Branch: refs/heads/master
>> Commit: 284067cbdb5f13c41225e22c2a60d79cd43f1383
>> Parents: 99c0d01
>> Author: Matt Sicker 
>> Authored: Thu Sep 8 10:30:12 2016 -0500
>> Committer: Matt Sicker 
>> Committed: Thu Sep 8 10:30:12 2016 -0500
>>
>> --
>>  .../logging/log4j/core/impl/ThrowableProxy.java |  9 ++--
>>  .../async/AsyncLoggerClassLoadDeadlock.java | 32 ++
>>  .../async/AsyncLoggerClassLoadDeadlockTest.java | 45
>> 
>>  .../test/resources/AsyncLoggerConsoleTest.xml   | 16 +++
>>  src/changes/changes.xml |  3 ++
>>  5 files changed, 100 insertions(+), 5 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
>> 84067cb/log4j-core/src/main/java/org/apache/logging/log4j/co
>> re/impl/ThrowableProxy.java
>> --
>> diff --git 
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>> l/ThrowableProxy.java
>> index a052e4d..e12e14a 100644
>> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>> l/ThrowableProxy.java
>> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/imp
>> l/ThrowableProxy.java
>> @@ -30,7 +30,6 @@ import java.util.Stack;
>>
>>  import org.apache.logging.log4j.core.pattern.PlainTextRenderer;
>>  import org.apache.logging.log4j.core.pattern.TextRenderer;
>> -import org.apache.logging.log4j.core.util.Loader;
>>  import org.apache.logging.log4j.status.StatusLogger;
>>  import org.apache.logging.log4j.util.LoaderUtil;
>>  import org.apache.logging.log4j.util.ReflectionUtil;
>> @@ -537,7 +536,7 @@ public class ThrowableProxy implements Serializable {
>>  Class clazz;
>>  if (lastLoader != null) {
>>  try {
>> -clazz = Loader.initializeClass(className, lastLoader);
>> +clazz = lastLoader.loadClass(className);
>>  if (clazz != null) {
>>  return clazz;
>>  }
>> @@ -548,16 +547,16 @@ public class ThrowableProxy implements Serializable
>> {
>>  try {
>>  clazz = LoaderUtil.loadClass(className);
>>  } catch (final ClassNotFoundException | NoClassDefFoundError e) {
>> -return initializeClass(className);
>> +return loadClass(className);
>>  } catch (final SecurityException e) {
>>  return null;
>>  }
>>  return clazz;
>>  }
>>
>> -private Class initializeClass(final String className) {
>> +private Class loadClass(final String className) {
>>  try {
>> -return Loader.initializeClass(className,
>> this.getClass().getClassLoader());
>> +return this.getClass().getClassLoader
>> ().loadClass(className);
>>  } catch (final ClassNotFoundException | NoClassDefFoundError |
>> SecurityException e) {
>>  return null;
>>  }
>>
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/2
>> 84067cb/log4j-core/src/test/java/org/apache/logging/log4j/co
>> re/async/AsyncLoggerClassLoadDeadlock.java
>> --
>> diff --git a/log4j-core/src/test/java/org/apache/logging/log4j/core/asy
>> nc/AsyncLoggerClassLoadDeadlock.java 

Re: [1/2] logging-log4j2 git commit: Remove obsolete comment

[Gary Gregory]

That would be great, but I do not see why the primary source of
documentation (the Javadoc) should be deleted in the first place. When I am
in an IDE whizzing around and coding, I use the Javadoc popups first
instead of going to a web browser.

Gary

On Thu, Sep 8, 2016 at 8:33 AM, Ralph Goers 
wrote:

> Why wouldn’t we add information about Log4j 1 to the Migration page?
>
> Ralph
>
> On Sep 8, 2016, at 8:13 AM, Gary Gregory  wrote:
>
> That's just silly IMO, Jira is not a place people go to to read
> documentation, I could understand if you sent out a link to the site...
>
>
> Gary
>
> On Sep 8, 2016 1:45 AM, "Mikael Ståldal" 
> wrote:
>
>> In https://issues.apache.org/jira/browse/LOG4J2-1523
>>
>>
>> On Wed, Sep 7, 2016 at 8:26 PM, Gary Gregory 
>> wrote:
>>
>>> How do you know what is supported then?
>>>
>>> Gary
>>>
>>> -- Forwarded message --
>>> From: 
>>> Date: Wed, Sep 7, 2016 at 12:15 PM
>>> Subject: [1/2] logging-log4j2 git commit: Remove obsolete comment
>>> To: comm...@logging.apache.org
>>>
>>>
>>> Repository: logging-log4j2
>>> Updated Branches:
>>>   refs/heads/master 15eb84c2d -> a559d5caf
>>>
>>>
>>> Remove obsolete comment
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
>>> /f016c441
>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/f
>>> 016c441
>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/f
>>> 016c441
>>>
>>> Branch: refs/heads/master
>>> Commit: f016c44110a7505b5e9addbe5f5fa95f2f6c39f4
>>> Parents: 4f3b21d
>>> Author: Mikael Ståldal 
>>> Authored: Wed Sep 7 18:15:32 2016 +0200
>>> Committer: Mikael Ståldal 
>>> Committed: Wed Sep 7 18:15:32 2016 +0200
>>>
>>> --
>>>  .../log4j/config/Log4j1ConfigurationParser.java  | 15
>>> ---
>>>  1 file changed, 15 deletions(-)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/f
>>> 016c441/log4j-1.2-api/src/main/java/org/apache/log4j/config/
>>> Log4j1ConfigurationParser.java
>>> --
>>> diff --git 
>>> a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
>>> b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
>>> ConfigurationParser.java
>>> index 04a7812..a8c3977 100644
>>> --- a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
>>> ConfigurationParser.java
>>> +++ b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
>>> ConfigurationParser.java
>>> @@ -37,21 +37,6 @@ import org.apache.logging.log4j.status.StatusLogger;
>>>
>>>  /**
>>>   * Experimental parser for Log4j 1.2 properties configuration files.
>>> - * 
>>> - * Currently supports:
>>> - * 
>>> - * 
>>> - * log4j.debug
>>> - * log4j.rootLogger
>>> - * log4j.logger
>>> - * log4j.appender
>>> - * org.apache.log4j.ConsoleAppender
>>> - * 
>>> - * Follow
>>> - * Target
>>> - * layout
>>> - * 
>>> - * 
>>>   *
>>>   * This class is not thread-safe.
>>>   */
>>>
>>>
>>>
>>>
>>> --
>>> 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.
>>
>
>


-- 
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: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

[Gary Gregory]

Hi Matt,

When I look at the change in ThrowableProxy that go away from using our
Loader utils and go back to loading classes directly I find it confusing:
Are the Loader utils broken or are these call sites the wrong use case for
the utils? We (you IIRC) have made a point of using these Loader utils (API
and Core) to load classes all over, which is nice since we get consistent
pattern. So I find it confusing to see it done both ways in the code
overall. Does this warrant a comment in the code? It might not, I'm just
asking the question.

Thank you,
Gary


On Thu, Sep 8, 2016 at 8:29 AM,  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master 99c0d011d -> 284067cbd
>
>
> Fix class loader deadlock when using async logging and extended stack
> trace pattern
>
> This fixes LOG4J2-1457.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/284067cb
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/284067cb
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/284067cb
>
> Branch: refs/heads/master
> Commit: 284067cbdb5f13c41225e22c2a60d79cd43f1383
> Parents: 99c0d01
> Author: Matt Sicker 
> Authored: Thu Sep 8 10:30:12 2016 -0500
> Committer: Matt Sicker 
> Committed: Thu Sep 8 10:30:12 2016 -0500
>
> --
>  .../logging/log4j/core/impl/ThrowableProxy.java |  9 ++--
>  .../async/AsyncLoggerClassLoadDeadlock.java | 32 ++
>  .../async/AsyncLoggerClassLoadDeadlockTest.java | 45 
>  .../test/resources/AsyncLoggerConsoleTest.xml   | 16 +++
>  src/changes/changes.xml |  3 ++
>  5 files changed, 100 insertions(+), 5 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 284067cb/log4j-core/src/main/java/org/apache/logging/log4j/
> core/impl/ThrowableProxy.java
> --
> diff --git 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> impl/ThrowableProxy.java
> index a052e4d..e12e14a 100644
> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> impl/ThrowableProxy.java
> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> impl/ThrowableProxy.java
> @@ -30,7 +30,6 @@ import java.util.Stack;
>
>  import org.apache.logging.log4j.core.pattern.PlainTextRenderer;
>  import org.apache.logging.log4j.core.pattern.TextRenderer;
> -import org.apache.logging.log4j.core.util.Loader;
>  import org.apache.logging.log4j.status.StatusLogger;
>  import org.apache.logging.log4j.util.LoaderUtil;
>  import org.apache.logging.log4j.util.ReflectionUtil;
> @@ -537,7 +536,7 @@ public class ThrowableProxy implements Serializable {
>  Class clazz;
>  if (lastLoader != null) {
>  try {
> -clazz = Loader.initializeClass(className, lastLoader);
> +clazz = lastLoader.loadClass(className);
>  if (clazz != null) {
>  return clazz;
>  }
> @@ -548,16 +547,16 @@ public class ThrowableProxy implements Serializable {
>  try {
>  clazz = LoaderUtil.loadClass(className);
>  } catch (final ClassNotFoundException | NoClassDefFoundError e) {
> -return initializeClass(className);
> +return loadClass(className);
>  } catch (final SecurityException e) {
>  return null;
>  }
>  return clazz;
>  }
>
> -private Class initializeClass(final String className) {
> +private Class loadClass(final String className) {
>  try {
> -return Loader.initializeClass(className, this.getClass().
> getClassLoader());
> +return this.getClass().getClassLoader().loadClass(className);
>  } catch (final ClassNotFoundException | NoClassDefFoundError |
> SecurityException e) {
>  return null;
>  }
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 284067cb/log4j-core/src/test/java/org/apache/logging/log4j/core/async/
> AsyncLoggerClassLoadDeadlock.java
> --
> diff --git a/log4j-core/src/test/java/org/apache/logging/log4j/core/async/
> AsyncLoggerClassLoadDeadlock.java b/log4j-core/src/test/java/
> org/apache/logging/log4j/core/async/AsyncLoggerClassLoadDeadlock.java
> new file mode 100644
> index 000..f8341f9
> --- /dev/null
> +++ b/log4j-core/src/test/java/org/apache/logging/log4j/core/async/
> AsyncLoggerClassLoadDeadlock.java
> @@ -0,0 +1,32 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * 

Re: [1/2] logging-log4j2 git commit: Remove obsolete comment

[Ralph Goers]

Why wouldn’t we add information about Log4j 1 to the Migration page?

Ralph

> On Sep 8, 2016, at 8:13 AM, Gary Gregory  wrote:
> 
> That's just silly IMO, Jira is not a place people go to to read 
> documentation, I could understand if you sent out a link to the site...
> 
> 
> 
> Gary
> 
> 
> On Sep 8, 2016 1:45 AM, "Mikael Ståldal"  > wrote:
> In https://issues.apache.org/jira/browse/LOG4J2-1523 
> 
> 
> 
> On Wed, Sep 7, 2016 at 8:26 PM, Gary Gregory  > wrote:
> How do you know what is supported then?
> 
> Gary
> 
> -- Forwarded message --
> From: >
> Date: Wed, Sep 7, 2016 at 12:15 PM
> Subject: [1/2] logging-log4j2 git commit: Remove obsolete comment
> To: comm...@logging.apache.org 
> 
> 
> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master 15eb84c2d -> a559d5caf
> 
> 
> Remove obsolete comment
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo 
> 
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/f016c441 
> 
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/f016c441 
> 
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/f016c441 
> 
> 
> Branch: refs/heads/master
> Commit: f016c44110a7505b5e9addbe5f5fa95f2f6c39f4
> Parents: 4f3b21d
> Author: Mikael Ståldal  >
> Authored: Wed Sep 7 18:15:32 2016 +0200
> Committer: Mikael Ståldal  >
> Committed: Wed Sep 7 18:15:32 2016 +0200
> 
> --
>  .../log4j/config/Log4j1ConfigurationParser.java  | 15 ---
>  1 file changed, 15 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/f016c441/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
>  
> 
> --
> diff --git 
> a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
>  
> b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
> index 04a7812..a8c3977 100644
> --- 
> a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
> +++ 
> b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
> @@ -37,21 +37,6 @@ import org.apache.logging.log4j.status.StatusLogger;
> 
>  /**
>   * Experimental parser for Log4j 1.2 properties configuration files.
> - * 
> - * Currently supports:
> - * 
> - * 
> - * log4j.debug
> - * log4j.rootLogger
> - * log4j.logger
> - * log4j.appender
> - * org.apache.log4j.ConsoleAppender
> - * 
> - * Follow
> - * Target
> - * layout
> - * 
> - * 
>   *
>   * This class is not thread-safe.
>   */
> 
> 
> 
> 
> -- 
> 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 
> 
> 
> -- 
>  
> 
> 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] [Resolved] (LOG4J2-1457) Class loader deadlock when using async logging and extended stack trace pattern

[Matt Sicker (JIRA)]

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

Matt Sicker resolved LOG4J2-1457.
-
Resolution: Fixed

I've added your unit tests along with a simpler fix in ThrowableProxy to the 
master branch in commit 284067cbdb5f13c41225e22c2a60d79cd43f1383. Please verify 
and close.

> Class loader deadlock when using async logging and extended stack trace 
> pattern
> ---
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
>Reporter: Leon Finker
>Assignee: Matt Sicker
>Priority: Critical
> Fix For: 2.7
>
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread 
> dump. Is it possible to have an option of pre-initializing the exception's 
> thread stack on the caller's thread? It's hard to predict what libraries are 
> doing in their classes' static initializers and may eventually end up logging 
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0 
> tid=0x7ff870c7b000 nid=0x79f3 in Object.wait() [0x7ff839142000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x7ff871677000 
> nid=0x725 runnable [0x7ff74bd27000]
> ..



--
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-1457) Class loader deadlock when using async logging and extended stack trace pattern

[Matt Sicker (JIRA)]

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

Matt Sicker updated LOG4J2-1457:

Summary: Class loader deadlock when using async logging and extended stack 
trace pattern  (was: Class loader deadlock when using async logging)

> Class loader deadlock when using async logging and extended stack trace 
> pattern
> ---
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
>Reporter: Leon Finker
>Assignee: Matt Sicker
>Priority: Critical
> Fix For: 2.7
>
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread 
> dump. Is it possible to have an option of pre-initializing the exception's 
> thread stack on the caller's thread? It's hard to predict what libraries are 
> doing in their classes' static initializers and may eventually end up logging 
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0 
> tid=0x7ff870c7b000 nid=0x79f3 in Object.wait() [0x7ff839142000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x7ff871677000 
> nid=0x725 runnable [0x7ff74bd27000]
> ..



--
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-1259) Log4j threads are leaking on tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1259:
--

What is your failing test?

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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

Re: [1/2] logging-log4j2 git commit: Remove obsolete comment

[Gary Gregory]

That's just silly IMO, Jira is not a place people go to to read
documentation, I could understand if you sent out a link to the site...


Gary

On Sep 8, 2016 1:45 AM, "Mikael Ståldal"  wrote:

> In https://issues.apache.org/jira/browse/LOG4J2-1523
>
>
> On Wed, Sep 7, 2016 at 8:26 PM, Gary Gregory 
> wrote:
>
>> How do you know what is supported then?
>>
>> Gary
>>
>> -- Forwarded message --
>> From: 
>> Date: Wed, Sep 7, 2016 at 12:15 PM
>> Subject: [1/2] logging-log4j2 git commit: Remove obsolete comment
>> To: comm...@logging.apache.org
>>
>>
>> Repository: logging-log4j2
>> Updated Branches:
>>   refs/heads/master 15eb84c2d -> a559d5caf
>>
>>
>> Remove obsolete comment
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
>> /f016c441
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/f016c441
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/f016c441
>>
>> Branch: refs/heads/master
>> Commit: f016c44110a7505b5e9addbe5f5fa95f2f6c39f4
>> Parents: 4f3b21d
>> Author: Mikael Ståldal 
>> Authored: Wed Sep 7 18:15:32 2016 +0200
>> Committer: Mikael Ståldal 
>> Committed: Wed Sep 7 18:15:32 2016 +0200
>>
>> --
>>  .../log4j/config/Log4j1ConfigurationParser.java  | 15
>> ---
>>  1 file changed, 15 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/f
>> 016c441/log4j-1.2-api/src/main/java/org/apache/log4j/config/
>> Log4j1ConfigurationParser.java
>> --
>> diff --git 
>> a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
>> b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
>> ConfigurationParser.java
>> index 04a7812..a8c3977 100644
>> --- a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
>> ConfigurationParser.java
>> +++ b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
>> ConfigurationParser.java
>> @@ -37,21 +37,6 @@ import org.apache.logging.log4j.status.StatusLogger;
>>
>>  /**
>>   * Experimental parser for Log4j 1.2 properties configuration files.
>> - * 
>> - * Currently supports:
>> - * 
>> - * 
>> - * log4j.debug
>> - * log4j.rootLogger
>> - * log4j.logger
>> - * log4j.appender
>> - * org.apache.log4j.ConsoleAppender
>> - * 
>> - * Follow
>> - * Target
>> - * layout
>> - * 
>> - * 
>>   *
>>   * This class is not thread-safe.
>>   */
>>
>>
>>
>>
>> --
>> 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] [Comment Edited] (LOG4J2-1457) Class loader deadlock when using async logging

[Matt Sicker (JIRA)]

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

Matt Sicker edited comment on LOG4J2-1457 at 9/8/16 3:11 PM:
-

Taking a closer look at this issue again, I could simply remove the 
initialization of custom log level plugins ahead of time as the documentation 
states that you need to specify them in your log4j config file anyways.

Edit: wait, I have this backwards. That's the code that can remain unchanged.


was (Author: jvz):
Taking a closer look at this issue again, I could simply remove the 
initialization of custom log level plugins ahead of time as the documentation 
states that you need to specify them in your log4j config file anyways.

> Class loader deadlock when using async logging
> --
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
>Reporter: Leon Finker
>Assignee: Matt Sicker
>Priority: Critical
> Fix For: 2.7
>
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread 
> dump. Is it possible to have an option of pre-initializing the exception's 
> thread stack on the caller's thread? It's hard to predict what libraries are 
> doing in their classes' static initializers and may eventually end up logging 
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0 
> tid=0x7ff870c7b000 nid=0x79f3 in Object.wait() [0x7ff839142000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x7ff871677000 
> nid=0x725 runnable [0x7ff74bd27000]
> ..



--
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-1528) Serialize configuration into a log4j2.xml file

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1528:
--

Cool, thank you.

> Serialize configuration into a log4j2.xml file
> --
>
> Key: LOG4J2-1528
> URL: https://issues.apache.org/jira/browse/LOG4J2-1528
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Affects Versions: 2.6.2
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.7
>
>
> This would be useful for e.g. converting from Log4j 1 to Log4j 2 config.



--
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-1457) Class loader deadlock when using async logging

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-1457:
-

Yeah, I'll take a look at this again today.

> Class loader deadlock when using async logging
> --
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
>Reporter: Leon Finker
>Assignee: Matt Sicker
>Priority: Critical
> Fix For: 2.7
>
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread 
> dump. Is it possible to have an option of pre-initializing the exception's 
> thread stack on the caller's thread? It's hard to predict what libraries are 
> doing in their classes' static initializers and may eventually end up logging 
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0 
> tid=0x7ff870c7b000 nid=0x79f3 in Object.wait() [0x7ff839142000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x7ff871677000 
> nid=0x725 runnable [0x7ff74bd27000]
> ..



--
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: [1/2] logging-log4j2 git commit: Deprecate org.apache.logging.log4j.core.util.NullOutputStream.NULL_OUTPUT_STREAM in favor of org.apache.logging.log4j.core.util.NullOutputStream.getInstance().

[Matt Sicker]

We can just convert everything to LF. Needs to be done on all active
branches, though, or else we'll get crazy merge conflicts I think.

On 8 September 2016 at 02:15, Gary Gregory  wrote:

> Let's all agree to 'something' and have that 'something' tested. Then we
> can add it to our site docs.
>
> Gary
>
> On Thu, Sep 8, 2016 at 12:10 AM, Remko Popma 
> wrote:
>
>> Guys, would it be possible to do something about the commit mails showing
>> all lines as changed?
>>
>> It seems that we need to take two steps:
>> 1. Change Eclipse settings: http://stackoverflow.com/a/24337518/1446916
>> 2. Convert CRLF to unix LF in existing files.
>>
>> Apparently there's no need to configure.gitattributes or core.autocrlf
>>
>> There is no way to see what changed at the moment...
>>
>> Remko
>>
>> Sent from my iPhone
>>
>> > On 2016/09/08, at 12:54, ggreg...@apache.org wrote:
>> >
>> > Repository: logging-log4j2
>> > Updated Branches:
>> >  refs/heads/master d85a0589b -> f73f89b14
>> >
>> >
>> > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/f
>> 73f89b1/log4j-core/src/main/java/org/apache/logging/log4j/co
>> re/net/TcpSocketManager.java
>> > --
>> > diff --git 
>> > a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/net
>> /TcpSocketManager.java
>> > index 855b99a..444c250 100644
>> > --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/net
>> /TcpSocketManager.java
>> > +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/net
>> /TcpSocketManager.java
>> > @@ -1,327 +1,327 @@
>> > -/*
>> > - * Licensed to the Apache Software Foundation (ASF) under one or more
>> > - * contributor license agreements. See the NOTICE file distributed with
>> > - * this work for additional information regarding copyright ownership.
>> > - * The ASF licenses this file to You under the Apache license, Version
>> 2.0
>> > - * (the "License"); you may not use this file except in compliance with
>> > - * the License. You may obtain a copy of the License at
>> > - *
>> > - *  http://www.apache.org/licenses/LICENSE-2.0
>> > - *
>> > - * Unless required by applicable law or agreed to in writing, software
>> > - * distributed under the License is distributed on an "AS IS" BASIS,
>> > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> > - * See the license for the specific language governing permissions and
>> > - * limitations under the license.
>> > - */
>> > -package org.apache.logging.log4j.core.net;
>> > -
>> > -import java.io.IOException;
>> > -import java.io.OutputStream;
>> > -import java.io.Serializable;
>> > -import java.net.ConnectException;
>> > -import java.net.InetAddress;
>> > -import java.net.InetSocketAddress;
>> > -import java.net.Socket;
>> > -import java.net.UnknownHostException;
>> > -import java.util.HashMap;
>> > -import java.util.Map;
>> > -import java.util.concurrent.CountDownLatch;
>> > -
>> > -import org.apache.logging.log4j.core.Layout;
>> > -import org.apache.logging.log4j.core.appender.AppenderLoggingExcept
>> ion;
>> > -import org.apache.logging.log4j.core.appender.ManagerFactory;
>> > -import org.apache.logging.log4j.core.appender.OutputStreamManager;
>> > -import org.apache.logging.log4j.core.util.Log4jThread;
>> > -import org.apache.logging.log4j.core.util.NullOutputStream;
>> > -import org.apache.logging.log4j.util.Strings;
>> > -
>> > -/**
>> > - * Manager of TCP Socket connections.
>> > - */
>> > -public class TcpSocketManager extends AbstractSocketManager {
>> > -/**
>> > -  The default reconnection delay (3 milliseconds or 30
>> seconds).
>> > - */
>> > -public static final int DEFAULT_RECONNECTION_DELAY_MILLIS   =
>> 3;
>> > -/**
>> > -  The default port number of remote logging server (4560).
>> > - */
>> > -private static final int DEFAULT_PORT = 4560;
>> > -
>> > -private static final TcpSocketManagerFactory FACTORY = new
>> TcpSocketManagerFactory();
>> > -
>> > -private final int reconnectionDelay;
>> > -
>> > -private Reconnector reconnector;
>> > -
>> > -private Socket socket;
>> > -
>> > -private final boolean retry;
>> > -
>> > -private final boolean immediateFail;
>> > -
>> > -private final int connectTimeoutMillis;
>> > -
>> > -/**
>> > - * The Constructor.
>> > - * @param name The unique name of this connection.
>> > - * @param os The OutputStream.
>> > - * @param socket The Socket.
>> > - * @param inetAddress The Internet address of the host.
>> > - * @param host The name of the host.
>> > - * @param port The port number on the host.
>> > - * @param connectTimeoutMillis the connect timeout in milliseconds.
>> > - * @param delay Reconnection interval.
>> > - * @param immediateFail True if the write should fail if no socket

[jira] [Commented] (LOG4J2-1457) Class loader deadlock when using async logging

[Leon Finker (JIRA)]

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

Leon Finker commented on LOG4J2-1457:
-

Matt, can this make it into 2.7? 

> Class loader deadlock when using async logging
> --
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
>Reporter: Leon Finker
>Assignee: Matt Sicker
>Priority: Critical
> Fix For: 2.7
>
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread 
> dump. Is it possible to have an option of pre-initializing the exception's 
> thread stack on the caller's thread? It's hard to predict what libraries are 
> doing in their classes' static initializers and may eventually end up logging 
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0 
> tid=0x7ff870c7b000 nid=0x79f3 in Object.wait() [0x7ff839142000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x7ff871677000 
> nid=0x725 runnable [0x7ff74bd27000]
> ..



--
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] [Issue Comment Deleted] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[Steffen Offermann (JIRA)]

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

Steffen Offermann updated LOG4J2-1259:
--
Comment: was deleted

(was: Now {{CronTriggeringPolicy.stop()}} does get called - but the thread 
still does not disappear. I'll investigate ...)

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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

Re: Deprecated factory methods replaced by builders.

[Ralph Goers]

What about them? Do they fit into the category of anything I have described? No.

Ralph

> On Sep 7, 2016, at 10:18 PM, Gary Gregory  wrote:
> 
> What about code in the Core util package?
> 
> Gary
> 
>> On Wed, Sep 7, 2016 at 10:06 PM, Ralph Goers  
>> wrote:
>> Everything is internal, but as I said previously, there are things where we 
>> do want to try to maintain compatibility - plugins being one of them.  Also 
>> as I said, we really need to document where anyone making customizations is 
>> at risk and where they aren’t.
>> 
>> Ralph
>> 
>>> On Sep 7, 2016, at 9:22 PM, Gary Gregory  wrote:
>>> 
 On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma  wrote:
 Okay. 
 Shall we introduce an @Internal annotation?
>>> 
>>> Please no, everything in Core is internal. I think we need to start with 
>>> English sentences before we get caught up on details of how to communicate 
>>> that to users.
>>> 
>>> Gary
>>>  
 
 Sent from my iPhone
 
> On 2016/09/08, at 12:52, Matt Sicker  wrote:
> 
> I agree that util packages are out of scope for BC. That's especially 
> true in log4j-api where everything else has BC concerns.
> 
>> On 7 September 2016 at 21:14, Gary Gregory  
>> wrote:
>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example 
>> because the Core util package is or should out of bounds for BC. I 
>> thought we had "agreed" on that.
>> 
>> Gary
>> 
>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma  
>>> wrote:
>>> We should make an effort not to break compatibility unless it's 
>>> unavoidable. There is usually a way to accomplish things without 
>>> breaking BC.
>>> 
>>> This is doubly true for plugins but should be our policy in general. 
>>> 
>>> We should not make breaking changes for aesthetic reasons. For example, 
>>> NullOutputStream.NULL_OUTPUT_STREAM would have been better named 
>>> INSTANCE, but this is one thing I would not change at this stage. 
>>> 
>>> One of the reasons people (I think on the Spark mailing list) mentioned 
>>> for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we 
>>> would make breaking changes. 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On 2016/09/08, at 8:03, Gary Gregory  wrote:
 
> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers 
>  wrote:
> We really need to document what we want to strive to maintain 
> compatibility with in core.  Basic components like Appenders and 
> their managers, Filters, Layouts, & Lookups or pretty much any Plugin 
> type would be at the top of my list. 
 
 Bleh, then we need to mark methods in some @tag-way in Javadocs.
 
 Gary 
> 
> Ralph
> 
>> On Sep 7, 2016, at 11:05 AM, Gary Gregory  
>> wrote:
>> 
>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma 
>>>  wrote:
>>> We should do this before starting the 2.7 release. 
>>> If we are serious about being the replacement for Log4j 1.2 we 
>>> should not break user code for no good reason.
>> 
>> What does this have to do with 1.2?
>> 
>> Gary 
>>> 
 On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma 
  wrote:
 I think that would be good. 
 
 Based on the number of Jira tickets being filed we are beginning 
 to see increased uptake. Programmatic configuration is used 
 surprisingly often. Leaving the factory methods in with some 
 reasonable default for the missing parameters ensures existing 
 users can smoothly upgrade. 
 
 Sent from my iPhone
 
> On 2016/09/07, at 3:03, Matt Sicker  wrote:
> 
> All the commits that removed deprecated factory methods it sounds 
> like.
> 
>> On 6 September 2016 at 13:00, Gary Gregory 
>>  wrote:
>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker  
>>> wrote:
>>> Should we revert those commits? There's still time.
>> 
>> What commit? Do you mean to add back factory methods?
>> 
>> Gary
>>  
>>> 
 On 3 September 2016 at 01:12, Ralph Goers 
  wrote:
 Perhaps we shouldn’t have.
 
 Ralph
 

[jira] [Commented] (LOG4J2-1528) Serialize configuration into a log4j2.xml file

[JIRA]

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

Mikael Ståldal commented on LOG4J2-1528:


I changed it to two spaces for indention.

> Serialize configuration into a log4j2.xml file
> --
>
> Key: LOG4J2-1528
> URL: https://issues.apache.org/jira/browse/LOG4J2-1528
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Affects Versions: 2.6.2
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.7
>
>
> This would be useful for e.g. converting from Log4j 1 to Log4j 2 config.



--
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: [1/2] logging-log4j2 git commit: Remove obsolete comment

[Mikael Ståldal]

In https://issues.apache.org/jira/browse/LOG4J2-1523


On Wed, Sep 7, 2016 at 8:26 PM, Gary Gregory  wrote:

> How do you know what is supported then?
>
> Gary
>
> -- Forwarded message --
> From: 
> Date: Wed, Sep 7, 2016 at 12:15 PM
> Subject: [1/2] logging-log4j2 git commit: Remove obsolete comment
> To: comm...@logging.apache.org
>
>
> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master 15eb84c2d -> a559d5caf
>
>
> Remove obsolete comment
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit
> /f016c441
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/f016c441
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/f016c441
>
> Branch: refs/heads/master
> Commit: f016c44110a7505b5e9addbe5f5fa95f2f6c39f4
> Parents: 4f3b21d
> Author: Mikael Ståldal 
> Authored: Wed Sep 7 18:15:32 2016 +0200
> Committer: Mikael Ståldal 
> Committed: Wed Sep 7 18:15:32 2016 +0200
>
> --
>  .../log4j/config/Log4j1ConfigurationParser.java  | 15 ---
>  1 file changed, 15 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/f
> 016c441/log4j-1.2-api/src/main/java/org/apache/log4j/config/
> Log4j1ConfigurationParser.java
> --
> diff --git 
> a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
> b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
> ConfigurationParser.java
> index 04a7812..a8c3977 100644
> --- a/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
> ConfigurationParser.java
> +++ b/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1
> ConfigurationParser.java
> @@ -37,21 +37,6 @@ import org.apache.logging.log4j.status.StatusLogger;
>
>  /**
>   * Experimental parser for Log4j 1.2 properties configuration files.
> - * 
> - * Currently supports:
> - * 
> - * 
> - * log4j.debug
> - * log4j.rootLogger
> - * log4j.logger
> - * log4j.appender
> - * org.apache.log4j.ConsoleAppender
> - * 
> - * Follow
> - * Target
> - * layout
> - * 
> - * 
>   *
>   * This class is not thread-safe.
>   */
>
>
>
>
> --
> 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.

Re: logging-log4j2 git commit: Fix POM description.

[Remko Popma]

"warpper" should be wrapper. 

Sent from my iPhone

> On 2016/09/08, at 13:47, ggreg...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master f2a7f74ec -> 1d3dc77cf
> 
> 
> Fix POM description.
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/1d3dc77c
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/1d3dc77c
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/1d3dc77c
> 
> Branch: refs/heads/master
> Commit: 1d3dc77cff1ee43c9e59f1b404947688a6780ecb
> Parents: f2a7f74
> Author: Gary Gregory 
> Authored: Wed Sep 7 21:47:33 2016 -0700
> Committer: Gary Gregory 
> Committed: Wed Sep 7 21:47:33 2016 -0700
> 
> --
> log4j-api-scala_2.10/pom.xml | 2 +-
> log4j-api-scala_2.11/pom.xml | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/1d3dc77c/log4j-api-scala_2.10/pom.xml
> --
> diff --git a/log4j-api-scala_2.10/pom.xml b/log4j-api-scala_2.10/pom.xml
> index ff1723c..5acbeca 100644
> --- a/log4j-api-scala_2.10/pom.xml
> +++ b/log4j-api-scala_2.10/pom.xml
> @@ -25,7 +25,7 @@
>   
>   log4j-api-scala_2.10
>   jar
> -  Scala 2.10 warpper for Log4j API
> +  Apache Log4j Scala 2.10 warpper for Log4j API
>   Scala warpper for Log4j API
>   
> ${basedir}/..
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/1d3dc77c/log4j-api-scala_2.11/pom.xml
> --
> diff --git a/log4j-api-scala_2.11/pom.xml b/log4j-api-scala_2.11/pom.xml
> index b64437a..4755301 100644
> --- a/log4j-api-scala_2.11/pom.xml
> +++ b/log4j-api-scala_2.11/pom.xml
> @@ -25,7 +25,7 @@
>   
>   log4j-api-scala_2.11
>   jar
> -  Scala 2.11 warpper for Log4j API
> +  Apache Log4j Scala 2.11 warpper for Log4j API
>   Scala warpper for Log4j API
>   
> ${basedir}/..
> 

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

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[Steffen Offermann (JIRA)]

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

Steffen Offermann commented on LOG4J2-1259:
---

Go rest! My day has just begun. :)

It works now! Thanks so far!

It's still a breaking change, and one of our test cases fails now, but other 
than that this looks promising. :)

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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-1259) Log4j threads are leaking on tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1259:
--

Arg, good catch again. Time for rest after a long day. Fixed in Git master.

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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-1259) Log4j threads are leaking on tomcat shutdown

[Steffen Offermann (JIRA)]

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

Steffen Offermann commented on LOG4J2-1259:
---

Now {{CronTriggeringPolicy.stop()}} does get called - but the thread still does 
not disappear. I'll investigate ...

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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-1259) Log4j threads are leaking on tomcat shutdown

[Steffen Offermann (JIRA)]

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

Steffen Offermann commented on LOG4J2-1259:
---

Will do in a minute, Gary. I just checked it out and looked at it - in the 
overridden method {{CompositeTriggeringPolicy.stop()}} you don't call the super 
implementation, and hence the {{state}} attribute won't get changed. Was that 
intended?

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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

Re: [1/2] logging-log4j2 git commit: Deprecate org.apache.logging.log4j.core.util.NullOutputStream.NULL_OUTPUT_STREAM in favor of org.apache.logging.log4j.core.util.NullOutputStream.getInstance().

[Gary Gregory]

Let's all agree to 'something' and have that 'something' tested. Then we
can add it to our site docs.

Gary

On Thu, Sep 8, 2016 at 12:10 AM, Remko Popma  wrote:

> Guys, would it be possible to do something about the commit mails showing
> all lines as changed?
>
> It seems that we need to take two steps:
> 1. Change Eclipse settings: http://stackoverflow.com/a/24337518/1446916
> 2. Convert CRLF to unix LF in existing files.
>
> Apparently there's no need to configure.gitattributes or core.autocrlf
>
> There is no way to see what changed at the moment...
>
> Remko
>
> Sent from my iPhone
>
> > On 2016/09/08, at 12:54, ggreg...@apache.org wrote:
> >
> > Repository: logging-log4j2
> > Updated Branches:
> >  refs/heads/master d85a0589b -> f73f89b14
> >
> >
> > http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> f73f89b1/log4j-core/src/main/java/org/apache/logging/log4j/
> core/net/TcpSocketManager.java
> > --
> > diff --git 
> > a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> net/TcpSocketManager.java
> > index 855b99a..444c250 100644
> > --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> net/TcpSocketManager.java
> > +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> net/TcpSocketManager.java
> > @@ -1,327 +1,327 @@
> > -/*
> > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > - * contributor license agreements. See the NOTICE file distributed with
> > - * this work for additional information regarding copyright ownership.
> > - * The ASF licenses this file to You under the Apache license, Version
> 2.0
> > - * (the "License"); you may not use this file except in compliance with
> > - * the License. You may obtain a copy of the License at
> > - *
> > - *  http://www.apache.org/licenses/LICENSE-2.0
> > - *
> > - * Unless required by applicable law or agreed to in writing, software
> > - * distributed under the License is distributed on an "AS IS" BASIS,
> > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > - * See the license for the specific language governing permissions and
> > - * limitations under the license.
> > - */
> > -package org.apache.logging.log4j.core.net;
> > -
> > -import java.io.IOException;
> > -import java.io.OutputStream;
> > -import java.io.Serializable;
> > -import java.net.ConnectException;
> > -import java.net.InetAddress;
> > -import java.net.InetSocketAddress;
> > -import java.net.Socket;
> > -import java.net.UnknownHostException;
> > -import java.util.HashMap;
> > -import java.util.Map;
> > -import java.util.concurrent.CountDownLatch;
> > -
> > -import org.apache.logging.log4j.core.Layout;
> > -import org.apache.logging.log4j.core.appender.AppenderLoggingException;
> > -import org.apache.logging.log4j.core.appender.ManagerFactory;
> > -import org.apache.logging.log4j.core.appender.OutputStreamManager;
> > -import org.apache.logging.log4j.core.util.Log4jThread;
> > -import org.apache.logging.log4j.core.util.NullOutputStream;
> > -import org.apache.logging.log4j.util.Strings;
> > -
> > -/**
> > - * Manager of TCP Socket connections.
> > - */
> > -public class TcpSocketManager extends AbstractSocketManager {
> > -/**
> > -  The default reconnection delay (3 milliseconds or 30 seconds).
> > - */
> > -public static final int DEFAULT_RECONNECTION_DELAY_MILLIS   =
> 3;
> > -/**
> > -  The default port number of remote logging server (4560).
> > - */
> > -private static final int DEFAULT_PORT = 4560;
> > -
> > -private static final TcpSocketManagerFactory FACTORY = new
> TcpSocketManagerFactory();
> > -
> > -private final int reconnectionDelay;
> > -
> > -private Reconnector reconnector;
> > -
> > -private Socket socket;
> > -
> > -private final boolean retry;
> > -
> > -private final boolean immediateFail;
> > -
> > -private final int connectTimeoutMillis;
> > -
> > -/**
> > - * The Constructor.
> > - * @param name The unique name of this connection.
> > - * @param os The OutputStream.
> > - * @param socket The Socket.
> > - * @param inetAddress The Internet address of the host.
> > - * @param host The name of the host.
> > - * @param port The port number on the host.
> > - * @param connectTimeoutMillis the connect timeout in milliseconds.
> > - * @param delay Reconnection interval.
> > - * @param immediateFail True if the write should fail if no socket
> is immediately available.
> > - * @param layout The Layout.
> > - * @param bufferSize The buffer size.
> > - */
> > -public TcpSocketManager(final String name, final OutputStream os,
> final Socket socket, final InetAddress inetAddress,
> > -final String host, final int port, final
> int 

[jira] [Closed] (LOG4J2-1567) DynamicThresholdFilter

[jdumetier (JIRA)]

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

jdumetier closed LOG4J2-1567.
-

> DynamicThresholdFilter 
> ---
>
> Key: LOG4J2-1567
> URL: https://issues.apache.org/jira/browse/LOG4J2-1567
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.6.2
>Reporter: jdumetier
>Priority: Critical
> Fix For: 2.7
>
> Attachments: DynamicThreasholdFilter.patch.txt
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The DynamicThresholdFilter doesn't override all the methods of the Filter 
> interface, this leads to misses for example when the method : {code}Result 
> filter(Logger logger, Level level, Marker marker, String message, Object p0, 
> Object p1);{code} is called.



--
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: Deprecated factory methods replaced by builders.

[Gary Gregory]

Note that I said "for removed code". Clirr will also complain about methods
added but I did not show that. Sadly, Clirr does not complain about methods
being added via a change in inheritance. Clirr is ld...

Gary

On Thu, Sep 8, 2016 at 12:00 AM, Remko Popma  wrote:

> Interesting, so Clirr does not detect the breaking change to
> TriggeringPolicy.
>
> Sent from my iPhone
>
> On 2016/09/08, at 13:32, Gary Gregory  wrote:
>
> FWIW, here is what Clirr finds for removed code:
>
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setFilter(org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setIgnoreExceptions(boolean)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setLayout(org.apache.logging.log4j.core.Layout)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setName(java.lang.String)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager:
> Method 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager:
> Method 'protected void close()' has been removed
> [ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory:
> Class org.apache.logging.log4j.core.async.DaemonThreadFactory removed
> [ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method
> 'public org.apache.logging.log4j.core.config.LoggerConfig
> createLogger(java.lang.String, org.apache.logging.log4j.Level,
> java.lang.String, java.lang.String, org.apache.logging.lo
> g4j.core.config.AppenderRef[], 
> org.apache.logging.log4j.core.config.Property[],
> org.apache.logging.log4j.core.config.Configuration,
> org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions:
> Method 'public java.util.List getPackages()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method
> 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public
> java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has
> been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public
> java.lang.Class loadClass(java.lang.String)' has been removed
>
> Gary
>
> On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory 
> wrote:
>
>> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker  wrote:
>>
>>> This is actually why I suggested making an spi package long ago in core
>>> for public classes that would remain BC. Sadly, it's a little late for that
>>> now.
>>>
>>
>> It's never too late ;-)
>>
>> We could do that and call it 2.8 or surely for 3.0. BC for Core is not
>> 100% guaranteed, we just try to make life not too painful for SPI providers.
>>
>> Gary
>>
>>
>>>
>>> On 7 September 2016 at 23:22, Gary Gregory 
>>> wrote:
>>>
 On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma 
 wrote:

> Okay.
> Shall we introduce an @Internal annotation?
>

 Please no, everything in Core is internal. I think we need to start
 with English sentences before we get caught up on details of how to
 communicate that to users.

 Gary


>
> Sent from my iPhone
>
> On 2016/09/08, at 12:52, Matt Sicker  wrote:
>
> I agree that util packages are out of scope for BC. That's especially
> true in log4j-api where everything else has BC concerns.
>
> On 7 September 2016 at 21:14, Gary Gregory 
> wrote:
>
>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>> because the Core util package is or should out of bounds for BC. I 
>> thought
>> we had "agreed" on that.
>>
>> Gary
>>
>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma 
>> wrote:
>>
>>> We should make an effort not to break compatibility unless it's
>>> unavoidable. There is usually a way to accomplish things without 
>>> breaking
>>> BC.
>>>
>>> This is doubly true for plugins but should be our policy in general.
>>>
>>> We should not make breaking changes for aesthetic reasons. For
>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>>> named INSTANCE, but this is one thing I would not change at this stage.
>>>
>>> 

Re: [1/2] logging-log4j2 git commit: Deprecate org.apache.logging.log4j.core.util.NullOutputStream.NULL_OUTPUT_STREAM in favor of org.apache.logging.log4j.core.util.NullOutputStream.getInstance().

[Remko Popma]

Guys, would it be possible to do something about the commit mails showing all 
lines as changed?

It seems that we need to take two steps: 
1. Change Eclipse settings: http://stackoverflow.com/a/24337518/1446916
2. Convert CRLF to unix LF in existing files. 

Apparently there's no need to configure.gitattributes or core.autocrlf

There is no way to see what changed at the moment...

Remko

Sent from my iPhone

> On 2016/09/08, at 12:54, ggreg...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master d85a0589b -> f73f89b14
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/f73f89b1/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java
> --
> diff --git 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java
>  
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java
> index 855b99a..444c250 100644
> --- 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java
> +++ 
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java
> @@ -1,327 +1,327 @@
> -/*
> - * Licensed to the Apache Software Foundation (ASF) under one or more
> - * contributor license agreements. See the NOTICE file distributed with
> - * this work for additional information regarding copyright ownership.
> - * The ASF licenses this file to You under the Apache license, Version 2.0
> - * (the "License"); you may not use this file except in compliance with
> - * the License. You may obtain a copy of the License at
> - *
> - *  http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing, software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> - * See the license for the specific language governing permissions and
> - * limitations under the license.
> - */
> -package org.apache.logging.log4j.core.net;
> -
> -import java.io.IOException;
> -import java.io.OutputStream;
> -import java.io.Serializable;
> -import java.net.ConnectException;
> -import java.net.InetAddress;
> -import java.net.InetSocketAddress;
> -import java.net.Socket;
> -import java.net.UnknownHostException;
> -import java.util.HashMap;
> -import java.util.Map;
> -import java.util.concurrent.CountDownLatch;
> -
> -import org.apache.logging.log4j.core.Layout;
> -import org.apache.logging.log4j.core.appender.AppenderLoggingException;
> -import org.apache.logging.log4j.core.appender.ManagerFactory;
> -import org.apache.logging.log4j.core.appender.OutputStreamManager;
> -import org.apache.logging.log4j.core.util.Log4jThread;
> -import org.apache.logging.log4j.core.util.NullOutputStream;
> -import org.apache.logging.log4j.util.Strings;
> -
> -/**
> - * Manager of TCP Socket connections.
> - */
> -public class TcpSocketManager extends AbstractSocketManager {
> -/**
> -  The default reconnection delay (3 milliseconds or 30 seconds).
> - */
> -public static final int DEFAULT_RECONNECTION_DELAY_MILLIS   = 3;
> -/**
> -  The default port number of remote logging server (4560).
> - */
> -private static final int DEFAULT_PORT = 4560;
> -
> -private static final TcpSocketManagerFactory FACTORY = new 
> TcpSocketManagerFactory();
> -
> -private final int reconnectionDelay;
> -
> -private Reconnector reconnector;
> -
> -private Socket socket;
> -
> -private final boolean retry;
> -
> -private final boolean immediateFail;
> -
> -private final int connectTimeoutMillis;
> -
> -/**
> - * The Constructor.
> - * @param name The unique name of this connection.
> - * @param os The OutputStream.
> - * @param socket The Socket.
> - * @param inetAddress The Internet address of the host.
> - * @param host The name of the host.
> - * @param port The port number on the host.
> - * @param connectTimeoutMillis the connect timeout in milliseconds.
> - * @param delay Reconnection interval.
> - * @param immediateFail True if the write should fail if no socket is 
> immediately available.
> - * @param layout The Layout.
> - * @param bufferSize The buffer size.
> - */
> -public TcpSocketManager(final String name, final OutputStream os, final 
> Socket socket, final InetAddress inetAddress,
> -final String host, final int port, final int 
> connectTimeoutMillis, final int delay,
> -final boolean immediateFail, final Layout extends Serializable> layout, final int bufferSize) {
> -super(name, os, inetAddress, host, port, layout, true, bufferSize);
> -this.connectTimeoutMillis = connectTimeoutMillis;
> -this.reconnectionDelay = delay;
> -this.socket = socket;
> -this.immediateFail = 

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1259:
--

Hi [~SteffenO]:

Nice find and my bad! I implemented {{CompositeTriggeringPolicy.stop(long, 
TimeUnit)}}. 

Can you please test the latest for your use case? 

We are currently discussing on the ML what the boundaries are for Binary 
Compatibility in the {{log4j-core}} module. For the {{log4j-api}} module, we 
strive for 100% BC of course. As Matt remarked on the ML, we should have 
created an SPI package a long time ago...

Gary

> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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

Re: Deprecated factory methods replaced by builders.

[Remko Popma]

Interesting, so Clirr does not detect the breaking change to TriggeringPolicy. 

Sent from my iPhone

> On 2016/09/08, at 13:32, Gary Gregory  wrote:
> 
> FWIW, here is what Clirr finds for removed code:
> 
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: 
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder 
> setFilter(org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: 
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder 
> setIgnoreExceptions(boolean)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: 
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder 
> setLayout(org.apache.logging.log4j.core.Layout)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: 
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder 
> setName(java.lang.String)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager: 
> Method 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager: Method 
> 'protected void close()' has been removed
> [ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory: Class 
> org.apache.logging.log4j.core.async.DaemonThreadFactory removed
> [ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method 
> 'public org.apache.logging.log4j.core.config.LoggerConfig 
> createLogger(java.lang.String, org.apache.logging.log4j.Level, 
> java.lang.String, java.lang.String, org.apache.logging.lo
> g4j.core.config.AppenderRef[], 
> org.apache.logging.log4j.core.config.Property[], 
> org.apache.logging.log4j.core.config.Configuration, 
> org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions: 
> Method 'public java.util.List getPackages()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method 
> 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public 
> java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has been 
> removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public 
> java.lang.Class loadClass(java.lang.String)' has been removed
> 
> Gary
> 
>> On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory  wrote:
>>> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker  wrote:
>>> This is actually why I suggested making an spi package long ago in core for 
>>> public classes that would remain BC. Sadly, it's a little late for that now.
>> 
>> It's never too late ;-)
>> 
>> We could do that and call it 2.8 or surely for 3.0. BC for Core is not 100% 
>> guaranteed, we just try to make life not too painful for SPI providers.
>> 
>> Gary
>>  
>>> 
 On 7 September 2016 at 23:22, Gary Gregory  wrote:
> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma  wrote:
> Okay. 
> Shall we introduce an @Internal annotation?
 
 Please no, everything in Core is internal. I think we need to start with 
 English sentences before we get caught up on details of how to communicate 
 that to users.
 
 Gary
  
> 
> Sent from my iPhone
> 
>> On 2016/09/08, at 12:52, Matt Sicker  wrote:
>> 
>> I agree that util packages are out of scope for BC. That's especially 
>> true in log4j-api where everything else has BC concerns.
>> 
>>> On 7 September 2016 at 21:14, Gary Gregory  
>>> wrote:
>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example 
>>> because the Core util package is or should out of bounds for BC. I 
>>> thought we had "agreed" on that.
>>> 
>>> Gary
>>> 
 On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma  
 wrote:
 We should make an effort not to break compatibility unless it's 
 unavoidable. There is usually a way to accomplish things without 
 breaking BC.
 
 This is doubly true for plugins but should be our policy in general. 
 
 We should not make breaking changes for aesthetic reasons. For 
 example, NullOutputStream.NULL_OUTPUT_STREAM would have been better 
 named INSTANCE, but this is one thing I would not change at this 
 stage. 
 
 One of the reasons people (I think on the Spark mailing list) 
 mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was 
 worries we would make breaking changes. 
 
 
 Sent from my iPhone
 
> On 2016/09/08, at 

[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[Steffen Offermann (JIRA)]

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

Steffen Offermann edited comment on LOG4J2-1259 at 9/8/16 6:51 AM:
---

Thanks again, Gary!

{{RollingFileManager.releaseSub()}} is indeed called, but it holds a 
{{CompositeTriggeringPolicy}}, which does not stop the nested policies because 
it does not override the {{stop()}} method inherited from {{AbstractLifeCycle}}:

{code}
@Override
public boolean stop(final long timeout, final TimeUnit timeUnit) {
this.state = LifeCycle.State.STOPPED;
return true;
}
{code}

And the change also still breaks existing code, because the 
{{TriggeringPolicy}} interface was changed. All artifacts using Log4j2 would 
have to be recompiled, including the transitive dependencies.




was (Author: steffeno):
Thanks again, Gary!

{{RollingFileManager.releaseSub()}} is indeed called, but it holds a 
{{CompositeTriggeringPolicy}}, which does not stop the nested policies because 
it does not override the {{stop()}} methode inherited from 
{{AbstractLifeCycle}}:

{code}
@Override
public boolean stop(final long timeout, final TimeUnit timeUnit) {
this.state = LifeCycle.State.STOPPED;
return true;
}
{code}

And the change also still breaks existing code, because the 
{{TriggeringPolicy}} interface was changed. All artifacts using Log4j2 would 
have to be recompiled, including the transitive dependencies.



> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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-1259) Log4j threads are leaking on tomcat shutdown

[Steffen Offermann (JIRA)]

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

Steffen Offermann commented on LOG4J2-1259:
---

Thanks again, Gary!

{{RollingFileManager.releaseSub()}} is indeed called, but it holds a 
{{CompositeTriggeringPolicy}}, which does not stop the nested policies because 
it does not override the {{stop()}} methode inherited from 
{{AbstractLifeCycle}}:

{code}
@Override
public boolean stop(final long timeout, final TimeUnit timeUnit) {
this.state = LifeCycle.State.STOPPED;
return true;
}
{code}

And the change also still breaks existing code, because the 
{{TriggeringPolicy}} interface was changed. All artifacts using Log4j2 would 
have to be recompiled, including the transitive dependencies.



> Log4j threads are leaking on tomcat shutdown
> 
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web 
> also included in the web application deployed in Tomcat 8. The context 
> listener is correctly starting up and shutting down, catalina.properties does 
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>  
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
>  java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a 
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>  sun.misc.Unsafe.park(Native Method)
>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>  com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>  
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>  com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>  
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  java.lang.Thread.run(Thread.java:745)
> {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-1570) Logging with a lambda expression with a method call that also logs causes logs within method call to reference line num and method name as parent method

[Joel Berta (JIRA)]

Joel Berta created LOG4J2-1570:
--

 Summary: Logging with a lambda expression with a method call that 
also logs causes logs within method call to reference line num and method name 
as parent method
 Key: LOG4J2-1570
 URL: https://issues.apache.org/jira/browse/LOG4J2-1570
 Project: Log4j 2
  Issue Type: Bug
  Components: API
Affects Versions: 2.6.2
Reporter: Joel Berta
Priority: Minor


While logging a message using lambda expressions. If i call a method within the 
log message (i.e logger.info(() -> "foo" +bar()) which also logs messages, 
those logs within the called method will reference the line number and method 
name of the method which invoked it.

Running the following code demonstrates this issue:

{code:title=TestingLogging.java|borderStyle=solid}
 private static final Logger LOGGER = 
LogManager.getLogger(TestingLogging.class);

public static String foo(){
LOGGER.info("bar");
return "foo";
}

public static void main(String[] args){
System.out.println("correct method reference: ");
LOGGER.info(foo());

System.out.println("\nincorrect method reference: ");

// causes logging in foo to reference
// this line number and method (main)
LOGGER.info(() -> foo());
}
{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

Re: Deprecated factory methods replaced by builders.

[Gary Gregory]

We can take a one step at a time approach too. There is only one interface
in javax.security.auth.spi...

Gary

On Wed, Sep 7, 2016 at 11:23 PM, Gary Gregory 
wrote:

> So what would this look like? Just stick all the interfaces in there? And
> add more interfaces for things that are "public" and "supported"?
>
> Gary
>
> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker  wrote:
>
>> This is actually why I suggested making an spi package long ago in core
>> for public classes that would remain BC. Sadly, it's a little late for that
>> now.
>>
>> On 7 September 2016 at 23:22, Gary Gregory 
>> wrote:
>>
>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma 
>>> wrote:
>>>
 Okay.
 Shall we introduce an @Internal annotation?

>>>
>>> Please no, everything in Core is internal. I think we need to start with
>>> English sentences before we get caught up on details of how to communicate
>>> that to users.
>>>
>>> Gary
>>>
>>>

 Sent from my iPhone

 On 2016/09/08, at 12:52, Matt Sicker  wrote:

 I agree that util packages are out of scope for BC. That's especially
 true in log4j-api where everything else has BC concerns.

 On 7 September 2016 at 21:14, Gary Gregory 
 wrote:

> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
> because the Core util package is or should out of bounds for BC. I thought
> we had "agreed" on that.
>
> Gary
>
> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma 
> wrote:
>
>> We should make an effort not to break compatibility unless it's
>> unavoidable. There is usually a way to accomplish things without breaking
>> BC.
>>
>> This is doubly true for plugins but should be our policy in general.
>>
>> We should not make breaking changes for aesthetic reasons. For
>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>> named INSTANCE, but this is one thing I would not change at this stage.
>>
>> One of the reasons people (I think on the Spark mailing list)
>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>> we would make breaking changes.
>>
>>
>> Sent from my iPhone
>>
>> On 2016/09/08, at 8:03, Gary Gregory  wrote:
>>
>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>> ralph.go...@dslextreme.com> wrote:
>>
>>> We really need to document what we want to strive to maintain
>>> compatibility with in core.  Basic components like Appenders and their
>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type 
>>> would
>>> be at the top of my list.
>>>
>>
>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>
>> Gary
>>
>>>
>>> Ralph
>>>
>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory 
>>> wrote:
>>>
>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma 
>>>  wrote:
>>>
 We should do this before starting the 2.7 release.
 If we are serious about being the replacement for Log4j 1.2 we
 should not break user code for no good reason.

>>>
>>> What does this have to do with 1.2?
>>>
>>> Gary
>>>

 On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma 
  wrote:

> I think that would be good.
>
> Based on the number of Jira tickets being filed we are beginning
> to see increased uptake. Programmatic configuration is used 
> surprisingly
> often. Leaving the factory methods in with some reasonable default 
> for the
> missing parameters ensures existing users can smoothly upgrade.
>
> Sent from my iPhone
>
> On 2016/09/07, at 3:03, Matt Sicker  wrote:
>
> All the commits that removed deprecated factory methods it sounds
> like.
>
> On 6 September 2016 at 13:00, Gary Gregory  > wrote:
>
>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker 
>> wrote:
>>
>>> Should we revert those commits? There's still time.
>>>
>>
>> What commit? Do you mean to add back factory methods?
>>
>> Gary
>>
>>
>>>
>>> On 3 September 2016 at 01:12, Ralph Goers <
>>> ralph.go...@dslextreme.com> wrote:
>>>
 Perhaps we shouldn’t have.

 Ralph

 On Sep 2, 2016, at 7:46 PM, Matt Sicker 
 wrote:

 We've already removed several deprecated factories in this

Re: Deprecated factory methods replaced by builders.

[Gary Gregory]

So what would this look like? Just stick all the interfaces in there? And
add more interfaces for things that are "public" and "supported"?

Gary

On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker  wrote:

> This is actually why I suggested making an spi package long ago in core
> for public classes that would remain BC. Sadly, it's a little late for that
> now.
>
> On 7 September 2016 at 23:22, Gary Gregory  wrote:
>
>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma 
>> wrote:
>>
>>> Okay.
>>> Shall we introduce an @Internal annotation?
>>>
>>
>> Please no, everything in Core is internal. I think we need to start with
>> English sentences before we get caught up on details of how to communicate
>> that to users.
>>
>> Gary
>>
>>
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/09/08, at 12:52, Matt Sicker  wrote:
>>>
>>> I agree that util packages are out of scope for BC. That's especially
>>> true in log4j-api where everything else has BC concerns.
>>>
>>> On 7 September 2016 at 21:14, Gary Gregory 
>>> wrote:
>>>
 I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
 because the Core util package is or should out of bounds for BC. I thought
 we had "agreed" on that.

 Gary

 On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma 
 wrote:

> We should make an effort not to break compatibility unless it's
> unavoidable. There is usually a way to accomplish things without breaking
> BC.
>
> This is doubly true for plugins but should be our policy in general.
>
> We should not make breaking changes for aesthetic reasons. For
> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
> named INSTANCE, but this is one thing I would not change at this stage.
>
> One of the reasons people (I think on the Spark mailing list)
> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
> we would make breaking changes.
>
>
> Sent from my iPhone
>
> On 2016/09/08, at 8:03, Gary Gregory  wrote:
>
> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
> ralph.go...@dslextreme.com> wrote:
>
>> We really need to document what we want to strive to maintain
>> compatibility with in core.  Basic components like Appenders and their
>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type 
>> would
>> be at the top of my list.
>>
>
> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>
> Gary
>
>>
>> Ralph
>>
>> On Sep 7, 2016, at 11:05 AM, Gary Gregory 
>> wrote:
>>
>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma 
>> wrote:
>>
>>> We should do this before starting the 2.7 release.
>>> If we are serious about being the replacement for Log4j 1.2 we
>>> should not break user code for no good reason.
>>>
>>
>> What does this have to do with 1.2?
>>
>> Gary
>>
>>>
>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma 
>>> wrote:
>>>
 I think that would be good.

 Based on the number of Jira tickets being filed we are beginning to
 see increased uptake. Programmatic configuration is used surprisingly
 often. Leaving the factory methods in with some reasonable default for 
 the
 missing parameters ensures existing users can smoothly upgrade.

 Sent from my iPhone

 On 2016/09/07, at 3:03, Matt Sicker  wrote:

 All the commits that removed deprecated factory methods it sounds
 like.

 On 6 September 2016 at 13:00, Gary Gregory 
  wrote:

> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker 
> wrote:
>
>> Should we revert those commits? There's still time.
>>
>
> What commit? Do you mean to add back factory methods?
>
> Gary
>
>
>>
>> On 3 September 2016 at 01:12, Ralph Goers <
>> ralph.go...@dslextreme.com> wrote:
>>
>>> Perhaps we shouldn’t have.
>>>
>>> Ralph
>>>
>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker 
>>> wrote:
>>>
>>> We've already removed several deprecated factories in this
>>> upcoming release, though.
>>>
>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>> mikael.stal...@magine.com> wrote:
>>>
 I agree with Remko, let's keep them unless they are in the way.
 We can remove all of them in Log4j 3.0.

 On Fri, Sep 2, 2016 at 1:31 AM, 

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

[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