Re: Considering org.apache.log4j.Hierarchy.ht as a "memory leak"

2013-08-26 Thread Deon van der Merwe

Hi Ralph,

On 27/08/2013 07:29, Ralph Goers wrote:

First, you are referring to Log4j 1.x.


Correct.


> Most of our work is currently

focused on Log4j 2.  That said, you would have the same issue with Log4j
2, Logback or even java.util.logging.


Understood.




What possible reason could you have for creating a logger per
subscriber?  The key to us being able to provide a solution is to know
what you are attempting to accomplish by doing that.  You cannot
possibly configure 10 million loggers so it can't possibly have anything
to do with that.  If it is to have some mechanism to identify the
subscriber than there are much better ways to do that.



No, they are not all created in 1 go: they are created dynamically as 
the subscriber might use the system.  The main reason for making the 
subscriber part of the category is to be able to do tracing per subscriber.




I would suggest reading through the Log4j 2 manual at
http://logging.apache.org/log4j/2.x/manual/index.html and seeing if the
facilities it has provide a solution.



Sure.  2.x been in the works for just of a year now, so about time to 
plan migration.





--
__Deon___
TruTeq Wireless (Pty) Ltd.   Tel: +27 12 667 1530
http://www.truteq.co.za  Fax: +27 12 667 1531
 Timezone: SAST GMT+2
Copyright&Legal: http://truteq.co.za/legal_notice.pdf

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



Re: Considering org.apache.log4j.Hierarchy.ht as a "memory leak"

2013-08-26 Thread Ralph Goers
First, you are referring to Log4j 1.x.  Most of our work is currently focused 
on Log4j 2.  That said, you would have the same issue with Log4j 2, Logback or 
even java.util.logging.  

What possible reason could you have for creating a logger per subscriber?  The 
key to us being able to provide a solution is to know what you are attempting 
to accomplish by doing that.  You cannot possibly configure 10 million loggers 
so it can't possibly have anything to do with that.  If it is to have some 
mechanism to identify the subscriber than there are much better ways to do 
that. 

I would suggest reading through the Log4j 2 manual at 
http://logging.apache.org/log4j/2.x/manual/index.html and seeing if the 
facilities it has provide a solution.

Ralph


On Aug 26, 2013, at 1:32 PM, Deon van der Merwe wrote:

> Hi,
> 
> For every new category created a new entry is added into 
> org.apache.log4j.Hierarchy.ht.  And at the same time also for any possible 
> parent category of that new entry.
> 
> This cache is fine when you have a fairly fixed number possible categories.  
> That cache will grow to some size and remain that size.
> 
> In our application we have several static categories but then also categories 
> which consists of some subscriber identity.  Possible range here is in the 
> order of tens of millions.  Most of these subscriber identity categories live 
> for a fairly short time, let's say less than 10 minutes.  Below is a sample 
> output from jstat showing the number of Logger objects going over 11M.  At 
> that point the GC starts to complain and the JVM is starting to suffer.
> 
> Now, org.apache.log4j.Hierarchy has a "clear" method which will just clean 
> the ht lookup completely.  Using that clear feels a bit harsh/extreme, 
> especially considering that we still have categories that do live a very long 
> time.
> 
> So, the question is if using "clear" is good practice or not?  If it is good, 
> then fine.  If not: what is good practice for keeping this ht lookup size 
> down to more practical levels (looking at current/live traffic etc)?
> 
> 
> 
> num #instances #bytes  class name
> --
>  28: 418071672280  org.apache.log4j.Logger
>  20: 880863523440  org.apache.log4j.Logger
>  15:1138354553400  org.apache.log4j.Logger
>  18:1332675330680  org.apache.log4j.Logger
>  16:1523796095160  org.apache.log4j.Logger
>  15:1735596942360  org.apache.log4j.Logger
>  11:2104808419200  org.apache.log4j.Logger
>  11:316526   12661040  org.apache.log4j.Logger
>  10:672608   26904320  org.apache.log4j.Logger
>   2:892928   35717120  org.apache.log4j.Logger
> ...
> ...
> ...
>   2:  11295227  451809080  org.apache.log4j.Logger
>   2:  11301788  452071520  org.apache.log4j.Logger
>   2:  11317688  452707520  org.apache.log4j.Logger
>   2:  11352595  454103800  org.apache.log4j.Logger
>   2:  11389363  455574520  org.apache.log4j.Logger
>   2:  11428866  457154640  org.apache.log4j.Logger
>   2:  11470739  458829560  org.apache.log4j.Logger
>   2:  11514552  460582080  org.apache.log4j.Logger
>   2:  11556256  462250240  org.apache.log4j.Logger
> 
> 
> 
> -- 
> __Deon___
> TruTeq Wireless (Pty) Ltd.   Tel: +27 12 667 1530
> http://www.truteq.co.za  Fax: +27 12 667 1531
> Timezone: SAST GMT+2
> Copyright&Legal: http://truteq.co.za/legal_notice.pdf
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 



[jira] [Commented] (LOG4J2-368) PatternLayout in 1.2 bridge missing constructor

2013-08-26 Thread Gus Heck (JIRA)

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

Gus Heck commented on LOG4J2-368:
-

It allows velocity to render my template.

> PatternLayout in 1.2 bridge missing constructor
> ---
>
> Key: LOG4J2-368
> URL: https://issues.apache.org/jira/browse/LOG4J2-368
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta8
> Environment: Velocity 1.7 hits this
>Reporter: Gus Heck
>Assignee: Ralph Goers
> Fix For: 2.0-beta9
>
>
> java.lang.NoSuchMethodError: 
> org.apache.log4j.PatternLayout.(Ljava/lang/String;)V
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.initAppender(Log4JLogChute.java:117)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.init(Log4JLogChute.java:85) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:157)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:269) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:871)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:262) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.requireInitialization(RuntimeInstance.java:302)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1531)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:343) 
> ~[velocity-1.7-dep.jar:1.7]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Closed] (LOG4J2-368) PatternLayout in 1.2 bridge missing constructor

2013-08-26 Thread Gus Heck (JIRA)

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

Gus Heck closed LOG4J2-368.
---


> PatternLayout in 1.2 bridge missing constructor
> ---
>
> Key: LOG4J2-368
> URL: https://issues.apache.org/jira/browse/LOG4J2-368
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta8
> Environment: Velocity 1.7 hits this
>Reporter: Gus Heck
>Assignee: Ralph Goers
> Fix For: 2.0-beta9
>
>
> java.lang.NoSuchMethodError: 
> org.apache.log4j.PatternLayout.(Ljava/lang/String;)V
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.initAppender(Log4JLogChute.java:117)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.init(Log4JLogChute.java:85) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:157)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:269) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:871)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:262) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.requireInitialization(RuntimeInstance.java:302)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1531)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:343) 
> ~[velocity-1.7-dep.jar:1.7]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



Considering org.apache.log4j.Hierarchy.ht as a "memory leak"

2013-08-26 Thread Deon van der Merwe

Hi,

For every new category created a new entry is added into 
org.apache.log4j.Hierarchy.ht.  And at the same time also for any 
possible parent category of that new entry.


This cache is fine when you have a fairly fixed number possible 
categories.  That cache will grow to some size and remain that size.


In our application we have several static categories but then also 
categories which consists of some subscriber identity.  Possible range 
here is in the order of tens of millions.  Most of these subscriber 
identity categories live for a fairly short time, let's say less than 10 
minutes.  Below is a sample output from jstat showing the number of 
Logger objects going over 11M.  At that point the GC starts to complain 
and the JVM is starting to suffer.


Now, org.apache.log4j.Hierarchy has a "clear" method which will just 
clean the ht lookup completely.  Using that clear feels a bit 
harsh/extreme, especially considering that we still have categories that 
do live a very long time.


So, the question is if using "clear" is good practice or not?  If it is 
good, then fine.  If not: what is good practice for keeping this ht 
lookup size down to more practical levels (looking at current/live 
traffic etc)?




 num #instances #bytes  class name
--
  28: 418071672280  org.apache.log4j.Logger
  20: 880863523440  org.apache.log4j.Logger
  15:1138354553400  org.apache.log4j.Logger
  18:1332675330680  org.apache.log4j.Logger
  16:1523796095160  org.apache.log4j.Logger
  15:1735596942360  org.apache.log4j.Logger
  11:2104808419200  org.apache.log4j.Logger
  11:316526   12661040  org.apache.log4j.Logger
  10:672608   26904320  org.apache.log4j.Logger
   2:892928   35717120  org.apache.log4j.Logger
...
...
...
   2:  11295227  451809080  org.apache.log4j.Logger
   2:  11301788  452071520  org.apache.log4j.Logger
   2:  11317688  452707520  org.apache.log4j.Logger
   2:  11352595  454103800  org.apache.log4j.Logger
   2:  11389363  455574520  org.apache.log4j.Logger
   2:  11428866  457154640  org.apache.log4j.Logger
   2:  11470739  458829560  org.apache.log4j.Logger
   2:  11514552  460582080  org.apache.log4j.Logger
   2:  11556256  462250240  org.apache.log4j.Logger



--
__Deon___
TruTeq Wireless (Pty) Ltd.   Tel: +27 12 667 1530
http://www.truteq.co.za  Fax: +27 12 667 1531
 Timezone: SAST GMT+2
Copyright&Legal: http://truteq.co.za/legal_notice.pdf

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



[jira] [Resolved] (LOG4J2-368) PatternLayout in 1.2 bridge missing constructor

2013-08-26 Thread Ralph Goers (JIRA)

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

Ralph Goers resolved LOG4J2-368.


   Resolution: Fixed
Fix Version/s: 2.0-beta9
 Assignee: Ralph Goers

Fixed in revision 1517659. Please verify and close.

> PatternLayout in 1.2 bridge missing constructor
> ---
>
> Key: LOG4J2-368
> URL: https://issues.apache.org/jira/browse/LOG4J2-368
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta8
> Environment: Velocity 1.7 hits this
>Reporter: Gus Heck
>Assignee: Ralph Goers
> Fix For: 2.0-beta9
>
>
> java.lang.NoSuchMethodError: 
> org.apache.log4j.PatternLayout.(Ljava/lang/String;)V
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.initAppender(Log4JLogChute.java:117)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.init(Log4JLogChute.java:85) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:157)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:269) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:871)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:262) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.requireInitialization(RuntimeInstance.java:302)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1531)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:343) 
> ~[velocity-1.7-dep.jar:1.7]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Commented] (LOG4J2-372) Build-path-issue. Invalid file or path...

2013-08-26 Thread Ralph Goers (JIRA)

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

Ralph Goers commented on LOG4J2-372:


mvn eclipse:eclipse works fine on my Mac. I'll have to try it in my Windows VM.

> Build-path-issue. Invalid file or path...
> -
>
> Key: LOG4J2-372
> URL: https://issues.apache.org/jira/browse/LOG4J2-372
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.0-beta9
> Environment: Log4j Samples: Flume - Remote
>Reporter: Roland Weiglhofer
>Priority: Minor
> Attachments: build_log4j2.txt
>
>
> calling 'mvn eclipse:eclipse' causes following error:
> ...
> [DEBUG] Searching for sources for javax.servlet:servlet-api:2.5:null at 
> javax.servlet:servlet-api:2.5:javadoc
> [DEBUG] Searching for sources for junit:junit:4.7:null at 
> junit:junit:4.7:javadoc
> [DEBUG] testOutput toRelativeAndFixSeparator 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote , 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\test-classes
> [DEBUG] testOutput after toRelative : target/test-classes
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\resources
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes, false }.
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\webapp\WEB-INF
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes\D:\rtu-workspace\log4j2-patch\samples\flume-remote\target,
>  false }.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Cant canonicalize system path: {0}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Resolved] (LOG4J2-364) WebLookup

2013-08-26 Thread Ralph Goers (JIRA)

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

Ralph Goers resolved LOG4J2-364.


Resolution: Fixed

PDF generation was fixed in revision 1517619.

> WebLookup
> -
>
> Key: LOG4J2-364
> URL: https://issues.apache.org/jira/browse/LOG4J2-364
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Core
>Reporter: David Nault
> Fix For: 2.0-beta9
>
> Attachments: WebLookup.java
>
>
> Add a "web" lookup plugin for resolving a webapp's root directory. 
> Investigate whether it can be included in BaseConfiguration's list of 
> hard-wired plugins.
> Motivated by email thread:
> 
> http://mail-archives.apache.org/mod_mbox/logging-log4j-user/201308.mbox/%3cd39a34d2-d584-4ddb-b121-407aa25e2...@criticalpath.net%3e

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Commented] (LOG4J2-368) PatternLayout in 1.2 bridge missing constructor

2013-08-26 Thread Ralph Goers (JIRA)

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

Ralph Goers commented on LOG4J2-368:


The 1.2 bridge is meant to be the minimum amount of stuff from Log4j 1 to pass 
applications over to Log4j 2. Log4j 1 Layouts, Appenders and Filters will not 
work with Log4j 2 so there is no point in implementing them.  The only reason 
PatternLayout exists is because Velocity has a hard-coded reference to it. I am 
not sure how I missed implementing the constructor since it was created for the 
sole purpose of making Velocity work.

> PatternLayout in 1.2 bridge missing constructor
> ---
>
> Key: LOG4J2-368
> URL: https://issues.apache.org/jira/browse/LOG4J2-368
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta8
> Environment: Velocity 1.7 hits this
>Reporter: Gus Heck
>
> java.lang.NoSuchMethodError: 
> org.apache.log4j.PatternLayout.(Ljava/lang/String;)V
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.initAppender(Log4JLogChute.java:117)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.init(Log4JLogChute.java:85) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:157)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:269) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:871)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:262) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.requireInitialization(RuntimeInstance.java:302)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1531)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:343) 
> ~[velocity-1.7-dep.jar:1.7]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Commented] (LOG4J2-368) PatternLayout in 1.2 bridge missing constructor

2013-08-26 Thread Gus Heck (JIRA)

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

Gus Heck commented on LOG4J2-368:
-

Hmm, looks like Huge swaths of the 1.2 bridge are no-op implementations... I'm 
guessing that the 1.2 bridge is much further behind than the rest of log4j 2.0? 
Or am I missing something?

> PatternLayout in 1.2 bridge missing constructor
> ---
>
> Key: LOG4J2-368
> URL: https://issues.apache.org/jira/browse/LOG4J2-368
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta8
> Environment: Velocity 1.7 hits this
>Reporter: Gus Heck
>
> java.lang.NoSuchMethodError: 
> org.apache.log4j.PatternLayout.(Ljava/lang/String;)V
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.initAppender(Log4JLogChute.java:117)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.init(Log4JLogChute.java:85) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:157)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:269) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:871)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:262) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.requireInitialization(RuntimeInstance.java:302)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1531)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:343) 
> ~[velocity-1.7-dep.jar:1.7]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Commented] (LOG4J2-372) Build-path-issue. Invalid file or path...

2013-08-26 Thread Roland Weiglhofer (JIRA)

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

Roland Weiglhofer commented on LOG4J2-372:
--

Thanks! I'll try it tomorrow.

> Build-path-issue. Invalid file or path...
> -
>
> Key: LOG4J2-372
> URL: https://issues.apache.org/jira/browse/LOG4J2-372
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.0-beta9
> Environment: Log4j Samples: Flume - Remote
>Reporter: Roland Weiglhofer
>Priority: Minor
> Attachments: build_log4j2.txt
>
>
> calling 'mvn eclipse:eclipse' causes following error:
> ...
> [DEBUG] Searching for sources for javax.servlet:servlet-api:2.5:null at 
> javax.servlet:servlet-api:2.5:javadoc
> [DEBUG] Searching for sources for junit:junit:4.7:null at 
> junit:junit:4.7:javadoc
> [DEBUG] testOutput toRelativeAndFixSeparator 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote , 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\test-classes
> [DEBUG] testOutput after toRelative : target/test-classes
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\resources
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes, false }.
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\webapp\WEB-INF
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes\D:\rtu-workspace\log4j2-patch\samples\flume-remote\target,
>  false }.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Cant canonicalize system path: {0}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Commented] (LOG4J2-368) PatternLayout in 1.2 bridge missing constructor

2013-08-26 Thread Gus Heck (JIRA)

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

Gus Heck commented on LOG4J2-368:
-

looking at revision 1517589, it seems that Pattern Layout is really not 
implemented yet:

{code}
package org.apache.log4j;

import org.apache.log4j.spi.LoggingEvent;

/**
 *
 */
public class PatternLayout extends Layout {

@Override
public String format(final LoggingEvent event) {
return "";
}

@Override
public boolean ignoresThrowable() {
return true;
}
}

{code}

I'm wondering what the intended approach is here? I may try my hand at a patch, 
but haven't played with the log4j codebase before... (I've done some 
fixes/features for Ant a long time ago and a smattering of fixes here/there 
since, but nothing in logging).

> PatternLayout in 1.2 bridge missing constructor
> ---
>
> Key: LOG4J2-368
> URL: https://issues.apache.org/jira/browse/LOG4J2-368
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta8
> Environment: Velocity 1.7 hits this
>Reporter: Gus Heck
>
> java.lang.NoSuchMethodError: 
> org.apache.log4j.PatternLayout.(Ljava/lang/String;)V
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.initAppender(Log4JLogChute.java:117)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.Log4JLogChute.init(Log4JLogChute.java:85) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:157)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:269) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:871)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:262) 
> ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.requireInitialization(RuntimeInstance.java:302)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1531)
>  ~[velocity-1.7-dep.jar:1.7]
>   at 
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:343) 
> ~[velocity-1.7-dep.jar:1.7]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
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-372) Build-path-issue. Invalid file or path...

2013-08-26 Thread Remko Popma (JIRA)

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

Remko Popma edited comment on LOG4J2-372 at 8/26/13 3:57 PM:
-

I had to make one change to get mvn eclipse:eclipse to run:
in samples/flume-embedded/pom.xml and samples/flume-remote/pom.xml,
replace the $\{basedir} variable with {{../..}}

Still investigating if this breaks anything, but as a one-off it should help 
you generate the .project and .classpath files you want.

  was (Author: rem...@yahoo.com):
I had to make one change to get mvn eclipse:eclipse to run:
in samples/flume-embedded/pom.xml and samples/flume-remote/pom.xml,
replace the ${basedir} variable with ../..

Still investigating if this breaks anything, but as a one-off it should help 
you generate the .project and .classpath files you want.
  
> Build-path-issue. Invalid file or path...
> -
>
> Key: LOG4J2-372
> URL: https://issues.apache.org/jira/browse/LOG4J2-372
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.0-beta9
> Environment: Log4j Samples: Flume - Remote
>Reporter: Roland Weiglhofer
>Priority: Minor
> Attachments: build_log4j2.txt
>
>
> calling 'mvn eclipse:eclipse' causes following error:
> ...
> [DEBUG] Searching for sources for javax.servlet:servlet-api:2.5:null at 
> javax.servlet:servlet-api:2.5:javadoc
> [DEBUG] Searching for sources for junit:junit:4.7:null at 
> junit:junit:4.7:javadoc
> [DEBUG] testOutput toRelativeAndFixSeparator 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote , 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\test-classes
> [DEBUG] testOutput after toRelative : target/test-classes
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\resources
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes, false }.
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\webapp\WEB-INF
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes\D:\rtu-workspace\log4j2-patch\samples\flume-remote\target,
>  false }.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Cant canonicalize system path: {0}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Commented] (LOG4J2-372) Build-path-issue. Invalid file or path...

2013-08-26 Thread Remko Popma (JIRA)

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

Remko Popma commented on LOG4J2-372:


I had to make one change to get mvn eclipse:eclipse to run:
in samples/flume-embedded/pom.xml and samples/flume-remote/pom.xml,
replace the ${basedir} variable with ../..

Still investigating if this breaks anything, but as a one-off it should help 
you generate the .project and .classpath files you want.

> Build-path-issue. Invalid file or path...
> -
>
> Key: LOG4J2-372
> URL: https://issues.apache.org/jira/browse/LOG4J2-372
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.0-beta9
> Environment: Log4j Samples: Flume - Remote
>Reporter: Roland Weiglhofer
>Priority: Minor
> Attachments: build_log4j2.txt
>
>
> calling 'mvn eclipse:eclipse' causes following error:
> ...
> [DEBUG] Searching for sources for javax.servlet:servlet-api:2.5:null at 
> javax.servlet:servlet-api:2.5:javadoc
> [DEBUG] Searching for sources for junit:junit:4.7:null at 
> junit:junit:4.7:javadoc
> [DEBUG] testOutput toRelativeAndFixSeparator 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote , 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\test-classes
> [DEBUG] testOutput after toRelative : target/test-classes
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\resources
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes, false }.
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\webapp\WEB-INF
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes\D:\rtu-workspace\log4j2-patch\samples\flume-remote\target,
>  false }.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Cant canonicalize system path: {0}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Updated] (LOG4J2-372) Build-path-issue. Invalid file or path...

2013-08-26 Thread Roland Weiglhofer (JIRA)

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

Roland Weiglhofer updated LOG4J2-372:
-

Attachment: build_log4j2.txt

> Build-path-issue. Invalid file or path...
> -
>
> Key: LOG4J2-372
> URL: https://issues.apache.org/jira/browse/LOG4J2-372
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.0-beta9
> Environment: Log4j Samples: Flume - Remote
>Reporter: Roland Weiglhofer
>Priority: Minor
> Attachments: build_log4j2.txt
>
>
> calling 'mvn eclipse:eclipse' causes following error:
> ...
> [DEBUG] Searching for sources for javax.servlet:servlet-api:2.5:null at 
> javax.servlet:servlet-api:2.5:javadoc
> [DEBUG] Searching for sources for junit:junit:4.7:null at 
> junit:junit:4.7:javadoc
> [DEBUG] testOutput toRelativeAndFixSeparator 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote , 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\test-classes
> [DEBUG] testOutput after toRelative : target/test-classes
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\resources
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes, false }.
> [DEBUG] Processing resource dir: 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\webapp\WEB-INF
> [DEBUG] Making relative and fixing separator: { 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
> D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes\D:\rtu-workspace\log4j2-patch\samples\flume-remote\target,
>  false }.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Cant canonicalize system path: {0}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Created] (LOG4J2-372) Build-path-issue. Invalid file or path...

2013-08-26 Thread Roland Weiglhofer (JIRA)
Roland Weiglhofer created LOG4J2-372:


 Summary: Build-path-issue. Invalid file or path...
 Key: LOG4J2-372
 URL: https://issues.apache.org/jira/browse/LOG4J2-372
 Project: Log4j 2
  Issue Type: Bug
  Components: Flume Appender
Affects Versions: 2.0-beta9
 Environment: Log4j Samples: Flume - Remote
Reporter: Roland Weiglhofer
Priority: Minor
 Attachments: build_log4j2.txt

calling 'mvn eclipse:eclipse' causes following error:

...
[DEBUG] Searching for sources for javax.servlet:servlet-api:2.5:null at 
javax.servlet:servlet-api:2.5:javadoc
[DEBUG] Searching for sources for junit:junit:4.7:null at 
junit:junit:4.7:javadoc
[DEBUG] testOutput toRelativeAndFixSeparator 
D:\rtu-workspace\log4j2-patch\samples\flume-remote , 
D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\test-classes
[DEBUG] testOutput after toRelative : target/test-classes
[DEBUG] Processing resource dir: 
D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\resources
[DEBUG] Making relative and fixing separator: { 
D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes, false }.
[DEBUG] Processing resource dir: 
D:\rtu-workspace\log4j2-patch\samples\flume-remote\src\main\webapp\WEB-INF
[DEBUG] Making relative and fixing separator: { 
D:\rtu-workspace\log4j2-patch\samples\flume-remote, 
D:\rtu-workspace\log4j2-patch\samples\flume-remote\target\classes\D:\rtu-workspace\log4j2-patch\samples\flume-remote\target,
 false }.
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Cant canonicalize system path: {0}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Updated] (LOG4J2-307) Upgrade LMAX disruptor library from 3.0.1 to 3.2.0 (was 3.1.1)

2013-08-26 Thread Remko Popma (JIRA)

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

Remko Popma updated LOG4J2-307:
---

Description: 
Upgrade LMAX Disruptor library from 3.0.1 to 3.1.1.

Edit 2013-8-26: the latest version is now 3.2.0

  was:Upgrade LMAX Disruptor library from 3.0.1 to 3.1.1.

Summary: Upgrade LMAX disruptor library from 3.0.1 to 3.2.0 (was 3.1.1) 
 (was: Upgrade LMAX disruptor library from 3.0.1 to 3.1.1)

> Upgrade LMAX disruptor library from 3.0.1 to 3.2.0 (was 3.1.1)
> --
>
> Key: LOG4J2-307
> URL: https://issues.apache.org/jira/browse/LOG4J2-307
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-beta9
>
>
> Upgrade LMAX Disruptor library from 3.0.1 to 3.1.1.
> Edit 2013-8-26: the latest version is now 3.2.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Resolved] (LOG4J2-307) Upgrade LMAX disruptor library from 3.0.1 to 3.2.0 (was 3.1.1)

2013-08-26 Thread Remko Popma (JIRA)

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

Remko Popma resolved LOG4J2-307.


Resolution: Fixed

Updated to disruptor 3.2.0 in revision 1517552.

> Upgrade LMAX disruptor library from 3.0.1 to 3.2.0 (was 3.1.1)
> --
>
> Key: LOG4J2-307
> URL: https://issues.apache.org/jira/browse/LOG4J2-307
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-beta9
>
>
> Upgrade LMAX Disruptor library from 3.0.1 to 3.1.1.
> Edit 2013-8-26: the latest version is now 3.2.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Reopened] (LOG4J2-307) Upgrade LMAX disruptor library from 3.0.1 to 3.1.1

2013-08-26 Thread Remko Popma (JIRA)

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

Remko Popma reopened LOG4J2-307:



re-open to update version number

> Upgrade LMAX disruptor library from 3.0.1 to 3.1.1
> --
>
> Key: LOG4J2-307
> URL: https://issues.apache.org/jira/browse/LOG4J2-307
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-beta9
>
>
> Upgrade LMAX Disruptor library from 3.0.1 to 3.1.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



Re: jactor-logger

2013-08-26 Thread Christian Grobmeier
Am 26.08.13 16:55, schrieb Remko Popma:
> I just re-arranged and analyzed the results posted
> in https://github.com/cp149/jactor-logger. I did not actually rerun
> the perf tests. (That is on the todo list but quite a bit of work...) 
>
> Is this officially part of Logback? (Seemed a bit rough and
> work-in-progressy to me...)

No, not so far. Only whats on https://*github*.com/qos-ch/*logback*? is
officially logback
>
>
> On Mon, Aug 26, 2013 at 10:34 PM, Ralph Goers
> mailto:ralph.go...@dslextreme.com>> wrote:
>
> What about more threads?
>
> Sent from my iPhone
>
> On Aug 26, 2013, at 3:47 AM, Remko Popma  > wrote:
>
>> I took a look. Still a bit rough, but people have started to
>> integrate the disruptor into Logback. 
>> Unfortunately cp149 did not mention the software versions used,
>> what OS they ran the performance test on, or any detail on the
>> hardware they used (number of cores would be nice to know...), so
>> it is hard to say anything about theirperformance results.
>> I re-arranged the ranking by total throughput (threads x
>> throughput/thread) below.
>>
>> Observations:
>> 1. Log4j2 Async Appender does very well (beats Log4j2 Async
>> Loggers and Logback jactor in all multi-threaded scenarios but one)
>> 2. Logback Async disruptor roughly equivalent to Log4j2 Async
>> Loggers and Async Appender (but hard to tell)
>> 3. in the 2-thread scenario Logback Async disruptor is much
>> better than Log4j2 Async Loggers (strange... Noise?)
>> 4. Logback jactor (non-disruptor) appenders only do reasonably
>> well in 1 thread scenarios, performance degrades in multi-thread
>> scenarios
>>
>> My guess is this was run on Windows, my Windows performance
>> results have also been noisy and much less consistent than Unix
>> results.
>> (Which reminds me, I should re-run the tests as we've made
>> performance improvements and fixed memory leaks...)
>>
>> Ranking in total throughput (threads x throughput/thread):
>> 1. Log4j2: Async Appender (4 threads): 10,632,480 ops/sec.
>> 2. Logback: Async disruptor Appender (1 thread): 9,993,043 ops/sec.
>> 3. Log4j2: Loggers all async (4 threads): 9,922,628 ops/sec.
>> 4. Logback: Async disruptor Appender (4 threads): 9,204,316 ops/sec.
>> 5. Logback: Async jactor2 Appender (1 thread): 9,001,575 ops/sec.
>> 6. Logback: Async jactor Appender (1 thread): 8,482,989 ops/sec.
>> 7. Log4j2: Loggers all async (1 thread): 8,394,794 ops/sec.
>> 8. Logback: Async disruptor Appender (2 threads): 8,207,580 ops/sec.
>> 9. Log4j2: Async Appender (2 threads): 7,658,818 ops/sec.
>> 10. Log4j2: Async Appender (1 thread): 7,408,055 ops/sec.
>> 11. Logback: Async jactor2 Appender (4 threads): 5,363,908 ops/sec.
>> 12. Log4j2: Loggers all async (2 threads): 4,860,704 ops/sec.
>> 13. Logback: Async jactor Appender (4 threads): 4,637,032 ops/sec.
>> 14. Logback: Async jactor2 Appender (2 threads): 3,478,812 ops/sec.
>> 15. Logback: Async jactor Appender (2 threads): 2,973,170 ops/sec.
>>
>>
>> On Monday, August 26, 2013, Ralph Goers wrote:
>>
>> Remko - I thought you might want to look at this
>> - https://github.com/cp149/jactor-logger
>>
>> Ralph
>>
>



Re: jactor-logger

2013-08-26 Thread Remko Popma
Gary, yes versions matter. For cp149's stuff, I don't know what version of
Log4j2 they used, what version of Logback and what version of the
disruptor...

We should probably upgrade to 3.2 for trunk, btw, thanks for the reminder!


On Mon, Aug 26, 2013 at 11:20 PM, Gary Gregory wrote:

> Also, does the version of the disruptor jar matter? I see that we are not
> on the latest version 3.2.0 for trunk.
>
> Gary
>
>
> On Mon, Aug 26, 2013 at 6:47 AM, Remko Popma wrote:
>
>> I took a look. Still a bit rough, but people have started to integrate
>> the disruptor into Logback.
>>  Unfortunately cp149 did not mention the software versions used, what OS
>> they ran the performance test on, or any detail on the hardware they used
>> (number of cores would be nice to know...), so it is hard to say anything
>> about their performance results.
>> I re-arranged the ranking by total throughput (threads x
>> throughput/thread) below.
>>
>> Observations:
>> 1. Log4j2 Async Appender does very well (beats Log4j2 Async Loggers and
>> Logback jactor in all multi-threaded scenarios but one)
>> 2. Logback Async disruptor roughly equivalent to Log4j2 Async Loggers and
>> Async Appender (but hard to tell)
>> 3. in the 2-thread scenario Logback Async disruptor is much better than
>> Log4j2 Async Loggers (strange... Noise?)
>> 4. Logback jactor (non-disruptor) appenders only do reasonably well in 1
>> thread scenarios, performance degrades in multi-thread scenarios
>>
>> My guess is this was run on Windows, my Windows performance results have
>> also been noisy and much less consistent than Unix results.
>> (Which reminds me, I should re-run the tests as we've made performance
>> improvements and fixed memory leaks...)
>>
>> Ranking in total throughput (threads x throughput/thread):
>> 1. Log4j2: Async Appender (4 threads): 10,632,480 ops/sec.
>> 2. Logback: Async disruptor Appender (1 thread): 9,993,043 ops/sec.
>> 3. Log4j2: Loggers all async (4 threads): 9,922,628 ops/sec.
>> 4. Logback: Async disruptor Appender (4 threads): 9,204,316 ops/sec.
>> 5. Logback: Async jactor2 Appender (1 thread): 9,001,575 ops/sec.
>> 6. Logback: Async jactor Appender (1 thread): 8,482,989 ops/sec.
>> 7. Log4j2: Loggers all async (1 thread): 8,394,794 ops/sec.
>> 8. Logback: Async disruptor Appender (2 threads): 8,207,580 ops/sec.
>> 9. Log4j2: Async Appender (2 threads): 7,658,818 ops/sec.
>> 10. Log4j2: Async Appender (1 thread): 7,408,055 ops/sec.
>> 11. Logback: Async jactor2 Appender (4 threads): 5,363,908 ops/sec.
>> 12. Log4j2: Loggers all async (2 threads): 4,860,704 ops/sec.
>> 13. Logback: Async jactor Appender (4 threads): 4,637,032 ops/sec.
>> 14. Logback: Async jactor2 Appender (2 threads): 3,478,812 ops/sec.
>> 15. Logback: Async jactor Appender (2 threads): 2,973,170 ops/sec.
>>
>>
>> On Monday, August 26, 2013, Ralph Goers wrote:
>>
>>> Remko - I thought you might want to look at this -
>>> https://github.com/cp149/jactor-logger
>>>
>>> Ralph
>>>
>>
>
>
> --
> 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: jactor-logger

2013-08-26 Thread Remko Popma
I just re-arranged and analyzed the results posted in
https://github.com/cp149/jactor-logger. I did not actually rerun the perf
tests. (That is on the todo list but quite a bit of work...)

Is this officially part of Logback? (Seemed a bit rough and
work-in-progressy to me...)


On Mon, Aug 26, 2013 at 10:34 PM, Ralph Goers wrote:

> What about more threads?
>
> Sent from my iPhone
>
> On Aug 26, 2013, at 3:47 AM, Remko Popma  wrote:
>
> I took a look. Still a bit rough, but people have started to integrate the
> disruptor into Logback.
> Unfortunately cp149 did not mention the software versions used, what OS
> they ran the performance test on, or any detail on the hardware they used
> (number of cores would be nice to know...), so it is hard to say anything
> about their performance results.
> I re-arranged the ranking by total throughput (threads x
> throughput/thread) below.
>
> Observations:
> 1. Log4j2 Async Appender does very well (beats Log4j2 Async Loggers and
> Logback jactor in all multi-threaded scenarios but one)
> 2. Logback Async disruptor roughly equivalent to Log4j2 Async Loggers and
> Async Appender (but hard to tell)
> 3. in the 2-thread scenario Logback Async disruptor is much better than
> Log4j2 Async Loggers (strange... Noise?)
> 4. Logback jactor (non-disruptor) appenders only do reasonably well in 1
> thread scenarios, performance degrades in multi-thread scenarios
>
> My guess is this was run on Windows, my Windows performance results have
> also been noisy and much less consistent than Unix results.
> (Which reminds me, I should re-run the tests as we've made performance
> improvements and fixed memory leaks...)
>
> Ranking in total throughput (threads x throughput/thread):
> 1. Log4j2: Async Appender (4 threads): 10,632,480 ops/sec.
> 2. Logback: Async disruptor Appender (1 thread): 9,993,043 ops/sec.
> 3. Log4j2: Loggers all async (4 threads): 9,922,628 ops/sec.
> 4. Logback: Async disruptor Appender (4 threads): 9,204,316 ops/sec.
> 5. Logback: Async jactor2 Appender (1 thread): 9,001,575 ops/sec.
> 6. Logback: Async jactor Appender (1 thread): 8,482,989 ops/sec.
> 7. Log4j2: Loggers all async (1 thread): 8,394,794 ops/sec.
> 8. Logback: Async disruptor Appender (2 threads): 8,207,580 ops/sec.
> 9. Log4j2: Async Appender (2 threads): 7,658,818 ops/sec.
> 10. Log4j2: Async Appender (1 thread): 7,408,055 ops/sec.
> 11. Logback: Async jactor2 Appender (4 threads): 5,363,908 ops/sec.
> 12. Log4j2: Loggers all async (2 threads): 4,860,704 ops/sec.
> 13. Logback: Async jactor Appender (4 threads): 4,637,032 ops/sec.
> 14. Logback: Async jactor2 Appender (2 threads): 3,478,812 ops/sec.
> 15. Logback: Async jactor Appender (2 threads): 2,973,170 ops/sec.
>
>
> On Monday, August 26, 2013, Ralph Goers wrote:
>
>> Remko - I thought you might want to look at this -
>> https://github.com/cp149/jactor-logger
>>
>> Ralph
>>
>


[jira] [Comment Edited] (LOG4J2-364) WebLookup

2013-08-26 Thread Gary Gregory (JIRA)

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

Gary Gregory edited comment on LOG4J2-364 at 8/26/13 2:53 PM:
--

The doc changes (lookups.xml) break PDF generation.

  was (Author: garydgregory):
The doc changes (lookups.xml) breaks PDF generation.
  
> WebLookup
> -
>
> Key: LOG4J2-364
> URL: https://issues.apache.org/jira/browse/LOG4J2-364
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Core
>Reporter: David Nault
> Fix For: 2.0-beta9
>
> Attachments: WebLookup.java
>
>
> Add a "web" lookup plugin for resolving a webapp's root directory. 
> Investigate whether it can be included in BaseConfiguration's list of 
> hard-wired plugins.
> Motivated by email thread:
> 
> http://mail-archives.apache.org/mod_mbox/logging-log4j-user/201308.mbox/%3cd39a34d2-d584-4ddb-b121-407aa25e2...@criticalpath.net%3e

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Resolved] (LOG4J2-333) Match artifact ids with Maven module names

2013-08-26 Thread Gary Gregory (JIRA)

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

Gary Gregory resolved LOG4J2-333.
-

   Resolution: Fixed
Fix Version/s: 2.0-beta9
 Assignee: Gary Gregory

> Match artifact ids with Maven module names
> --
>
> Key: LOG4J2-333
> URL: https://issues.apache.org/jira/browse/LOG4J2-333
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API, Core, Flume Appender, JCL Bridge, JMX, log4j 1.2 
> emulation, SLF4J Bridge, Taglib
>Affects Versions: 2.0-beta8
>Reporter: Hervé Boutemy
>Assignee: Gary Gregory
>Priority: Blocker
> Fix For: 2.0-beta9
>
>
> actual directory names don't match artifact ids:
> {noformat}$ grep "^   api/pom.xml:  log4j-api
> core/pom.xml:  log4j-core
> dist/pom.xml:  log4j-distribution
> flume-ng/pom.xml:  log4j-flume-ng
> jcl-bridge/pom.xml:  log4j-jcl
> jmx-gui/pom.xml:  log4j-jmx-gui
> log4j12-api/pom.xml:  log4j-1.2-api
> log4j-to-slf4j/pom.xml:  log4j-to-slf4j
> osgi/pom.xml:  log4j-osgi
> samples/pom.xml:  log4j-samples
> slf4j-impl/pom.xml:  log4j-slf4j-impl
> taglib/pom.xml:  log4j-taglib{noformat}
> the only exception is log4j-to-slf4j
> doing so will cause you problems with automatic calculations done by Maven 
> for site: you're going to fight against Maven, which is good neither for you 
> nor Maven (I already heard a lot about "maven site plugin is broken"...) :)
> you should really rename directories in svn to match artifactIds (which will 
> cause less trouble than renaming artifact ids to match directory names IMHO)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
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-333) Match artifact ids with Maven module names

2013-08-26 Thread Gary Gregory (JIRA)

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

Gary Gregory edited comment on LOG4J2-333 at 8/26/13 2:53 PM:
--

Hervé,

Committed revision 1517550.

Please verify and close, or propose more clean ups ;) Thank you/Merci!


Gary

  was (Author: garydgregory):
Hervé,

I committed the changes. Please verify and close, or propose more clean ups ;) 
Thank you/Merci!

Gary
  
> Match artifact ids with Maven module names
> --
>
> Key: LOG4J2-333
> URL: https://issues.apache.org/jira/browse/LOG4J2-333
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API, Core, Flume Appender, JCL Bridge, JMX, log4j 1.2 
> emulation, SLF4J Bridge, Taglib
>Affects Versions: 2.0-beta8
>Reporter: Hervé Boutemy
>Assignee: Gary Gregory
>Priority: Blocker
> Fix For: 2.0-beta9
>
>
> actual directory names don't match artifact ids:
> {noformat}$ grep "^   api/pom.xml:  log4j-api
> core/pom.xml:  log4j-core
> dist/pom.xml:  log4j-distribution
> flume-ng/pom.xml:  log4j-flume-ng
> jcl-bridge/pom.xml:  log4j-jcl
> jmx-gui/pom.xml:  log4j-jmx-gui
> log4j12-api/pom.xml:  log4j-1.2-api
> log4j-to-slf4j/pom.xml:  log4j-to-slf4j
> osgi/pom.xml:  log4j-osgi
> samples/pom.xml:  log4j-samples
> slf4j-impl/pom.xml:  log4j-slf4j-impl
> taglib/pom.xml:  log4j-taglib{noformat}
> the only exception is log4j-to-slf4j
> doing so will cause you problems with automatic calculations done by Maven 
> for site: you're going to fight against Maven, which is good neither for you 
> nor Maven (I already heard a lot about "maven site plugin is broken"...) :)
> you should really rename directories in svn to match artifactIds (which will 
> cause less trouble than renaming artifact ids to match directory names IMHO)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Reopened] (LOG4J2-364) WebLookup

2013-08-26 Thread Gary Gregory (JIRA)

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

Gary Gregory reopened LOG4J2-364:
-


The doc changes (lookups.xml) breaks PDF generation.

> WebLookup
> -
>
> Key: LOG4J2-364
> URL: https://issues.apache.org/jira/browse/LOG4J2-364
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Core
>Reporter: David Nault
> Fix For: 2.0-beta9
>
> Attachments: WebLookup.java
>
>
> Add a "web" lookup plugin for resolving a webapp's root directory. 
> Investigate whether it can be included in BaseConfiguration's list of 
> hard-wired plugins.
> Motivated by email thread:
> 
> http://mail-archives.apache.org/mod_mbox/logging-log4j-user/201308.mbox/%3cd39a34d2-d584-4ddb-b121-407aa25e2...@criticalpath.net%3e

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Resolved] (LOG4J2-371) mvn test won't build

2013-08-26 Thread Gary Gregory (JIRA)

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

Gary Gregory resolved LOG4J2-371.
-

   Resolution: Fixed
Fix Version/s: 2.0-beta9
 Assignee: Gary Gregory

This is already fixed in trunk.

> mvn test won't build
> 
>
> Key: LOG4J2-371
> URL: https://issues.apache.org/jira/browse/LOG4J2-371
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0-beta9
> Environment: Checked out revision 1517541.
> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: /usr/share/maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
>Reporter: Gus Heck
>Assignee: Gary Gregory
> Fix For: 2.0-beta9
>
>
> mvn test fails, evidently due to some re-named directories. 
> {code}
> Checked out revision 1517541.
> Guss-MacBook-Pro:log4j2 gus$ cd log4j/
> Guss-MacBook-Pro:log4j2 gus$ mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: /usr/share/maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
> Guss-MacBook-Pro:log4j2 gus$ cd log4j/
> Guss-MacBook-Pro:log4j gus$ mvn test
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project org.apache.logging.log4j:log4j:2.0-beta9-SNAPSHOT 
> (/Users/gus/projects/log4j2/log4j/pom.xml) has 10 errors
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/api of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/core of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/osgi of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/log4j12-api of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/slf4j-impl of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/jcl-bridge of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/flume-ng of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/taglib of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/jmx-gui of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] Child module /Users/gus/projects/log4j2/log4j/samples of 
> /Users/gus/projects/log4j2/log4j/pom.xml does not exist
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> Guss-MacBook-Pro:log4j gus$ ls
> BUILDING.txt  checkstyle.xml  log4j-flume-ng  
> log4j-taglib
> LICENSE.txt   findbugs-exclude-filter.xml log4j-jcl   
> log4j-to-slf4j
> NOTICE.txtlog4j-1.2-api   log4j-jmx-gui   
> pom.xml
> RELEASE-NOTES.txt log4j-api   log4j-osgi  
> src
> checkstyle-header.txt log4j-core  log4j-samples
> checkstyle-import-control.xml log4j-distribution  log4j-slf4j-impl
> Guss-MacBook-Pro:log4j gus$ 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Commented] (LOG4J2-333) Match artifact ids with Maven module names

2013-08-26 Thread Gary Gregory (JIRA)

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

Gary Gregory commented on LOG4J2-333:
-

Hervé,

I committed the changes. Please verify and close, or propose more clean ups ;) 
Thank you/Merci!

Gary

> Match artifact ids with Maven module names
> --
>
> Key: LOG4J2-333
> URL: https://issues.apache.org/jira/browse/LOG4J2-333
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API, Core, Flume Appender, JCL Bridge, JMX, log4j 1.2 
> emulation, SLF4J Bridge, Taglib
>Affects Versions: 2.0-beta8
>Reporter: Hervé Boutemy
>Priority: Blocker
>
> actual directory names don't match artifact ids:
> {noformat}$ grep "^   api/pom.xml:  log4j-api
> core/pom.xml:  log4j-core
> dist/pom.xml:  log4j-distribution
> flume-ng/pom.xml:  log4j-flume-ng
> jcl-bridge/pom.xml:  log4j-jcl
> jmx-gui/pom.xml:  log4j-jmx-gui
> log4j12-api/pom.xml:  log4j-1.2-api
> log4j-to-slf4j/pom.xml:  log4j-to-slf4j
> osgi/pom.xml:  log4j-osgi
> samples/pom.xml:  log4j-samples
> slf4j-impl/pom.xml:  log4j-slf4j-impl
> taglib/pom.xml:  log4j-taglib{noformat}
> the only exception is log4j-to-slf4j
> doing so will cause you problems with automatic calculations done by Maven 
> for site: you're going to fight against Maven, which is good neither for you 
> nor Maven (I already heard a lot about "maven site plugin is broken"...) :)
> you should really rename directories in svn to match artifactIds (which will 
> cause less trouble than renaming artifact ids to match directory names IMHO)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Created] (LOG4J2-371) mvn test won't build

2013-08-26 Thread Gus Heck (JIRA)
Gus Heck created LOG4J2-371:
---

 Summary: mvn test won't build
 Key: LOG4J2-371
 URL: https://issues.apache.org/jira/browse/LOG4J2-371
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta9
 Environment: Checked out revision 1517541.
Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: /usr/share/maven
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
Reporter: Gus Heck


mvn test fails, evidently due to some re-named directories. 

{code}
Checked out revision 1517541.
Guss-MacBook-Pro:log4j2 gus$ cd log4j/
Guss-MacBook-Pro:log4j2 gus$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: /usr/share/maven
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
Guss-MacBook-Pro:log4j2 gus$ cd log4j/
Guss-MacBook-Pro:log4j gus$ mvn test
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project org.apache.logging.log4j:log4j:2.0-beta9-SNAPSHOT 
(/Users/gus/projects/log4j2/log4j/pom.xml) has 10 errors
[ERROR] Child module /Users/gus/projects/log4j2/log4j/api of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/core of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/osgi of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/log4j12-api of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/slf4j-impl of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/jcl-bridge of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/flume-ng of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/taglib of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/jmx-gui of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] Child module /Users/gus/projects/log4j2/log4j/samples of 
/Users/gus/projects/log4j2/log4j/pom.xml does not exist
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
Guss-MacBook-Pro:log4j gus$ ls
BUILDING.txtcheckstyle.xml  log4j-flume-ng  
log4j-taglib
LICENSE.txt findbugs-exclude-filter.xml log4j-jcl   
log4j-to-slf4j
NOTICE.txt  log4j-1.2-api   log4j-jmx-gui   
pom.xml
RELEASE-NOTES.txt   log4j-api   log4j-osgi  
src
checkstyle-header.txt   log4j-core  log4j-samples
checkstyle-import-control.xml   log4j-distribution  log4j-slf4j-impl
Guss-MacBook-Pro:log4j gus$ 

{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



Re: jactor-logger

2013-08-26 Thread Gary Gregory
Also, does the version of the disruptor jar matter? I see that we are not
on the latest version 3.2.0 for trunk.

Gary


On Mon, Aug 26, 2013 at 6:47 AM, Remko Popma  wrote:

> I took a look. Still a bit rough, but people have started to integrate the
> disruptor into Logback.
> Unfortunately cp149 did not mention the software versions used, what OS
> they ran the performance test on, or any detail on the hardware they used
> (number of cores would be nice to know...), so it is hard to say anything
> about their performance results.
> I re-arranged the ranking by total throughput (threads x
> throughput/thread) below.
>
> Observations:
> 1. Log4j2 Async Appender does very well (beats Log4j2 Async Loggers and
> Logback jactor in all multi-threaded scenarios but one)
> 2. Logback Async disruptor roughly equivalent to Log4j2 Async Loggers and
> Async Appender (but hard to tell)
> 3. in the 2-thread scenario Logback Async disruptor is much better than
> Log4j2 Async Loggers (strange... Noise?)
> 4. Logback jactor (non-disruptor) appenders only do reasonably well in 1
> thread scenarios, performance degrades in multi-thread scenarios
>
> My guess is this was run on Windows, my Windows performance results have
> also been noisy and much less consistent than Unix results.
> (Which reminds me, I should re-run the tests as we've made performance
> improvements and fixed memory leaks...)
>
> Ranking in total throughput (threads x throughput/thread):
> 1. Log4j2: Async Appender (4 threads): 10,632,480 ops/sec.
> 2. Logback: Async disruptor Appender (1 thread): 9,993,043 ops/sec.
> 3. Log4j2: Loggers all async (4 threads): 9,922,628 ops/sec.
> 4. Logback: Async disruptor Appender (4 threads): 9,204,316 ops/sec.
> 5. Logback: Async jactor2 Appender (1 thread): 9,001,575 ops/sec.
> 6. Logback: Async jactor Appender (1 thread): 8,482,989 ops/sec.
> 7. Log4j2: Loggers all async (1 thread): 8,394,794 ops/sec.
> 8. Logback: Async disruptor Appender (2 threads): 8,207,580 ops/sec.
> 9. Log4j2: Async Appender (2 threads): 7,658,818 ops/sec.
> 10. Log4j2: Async Appender (1 thread): 7,408,055 ops/sec.
> 11. Logback: Async jactor2 Appender (4 threads): 5,363,908 ops/sec.
> 12. Log4j2: Loggers all async (2 threads): 4,860,704 ops/sec.
> 13. Logback: Async jactor Appender (4 threads): 4,637,032 ops/sec.
> 14. Logback: Async jactor2 Appender (2 threads): 3,478,812 ops/sec.
> 15. Logback: Async jactor Appender (2 threads): 2,973,170 ops/sec.
>
>
> On Monday, August 26, 2013, Ralph Goers wrote:
>
>> Remko - I thought you might want to look at this -
>> https://github.com/cp149/jactor-logger
>>
>> Ralph
>>
>


-- 
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: jactor-logger

2013-08-26 Thread Ralph Goers
What about more threads?

Sent from my iPhone

On Aug 26, 2013, at 3:47 AM, Remko Popma  wrote:

> I took a look. Still a bit rough, but people have started to integrate the 
> disruptor into Logback. 
> Unfortunately cp149 did not mention the software versions used, what OS they 
> ran the performance test on, or any detail on the hardware they used (number 
> of cores would be nice to know...), so it is hard to say anything about their 
> performance results.
> I re-arranged the ranking by total throughput (threads x throughput/thread) 
> below.
> 
> Observations:
> 1. Log4j2 Async Appender does very well (beats Log4j2 Async Loggers and 
> Logback jactor in all multi-threaded scenarios but one)
> 2. Logback Async disruptor roughly equivalent to Log4j2 Async Loggers and 
> Async Appender (but hard to tell)
> 3. in the 2-thread scenario Logback Async disruptor is much better than 
> Log4j2 Async Loggers (strange... Noise?)
> 4. Logback jactor (non-disruptor) appenders only do reasonably well in 1 
> thread scenarios, performance degrades in multi-thread scenarios
> 
> My guess is this was run on Windows, my Windows performance results have also 
> been noisy and much less consistent than Unix results.
> (Which reminds me, I should re-run the tests as we've made performance 
> improvements and fixed memory leaks...)
> 
> Ranking in total throughput (threads x throughput/thread):
> 1. Log4j2: Async Appender (4 threads): 10,632,480 ops/sec.
> 2. Logback: Async disruptor Appender (1 thread): 9,993,043 ops/sec.
> 3. Log4j2: Loggers all async (4 threads): 9,922,628 ops/sec.
> 4. Logback: Async disruptor Appender (4 threads): 9,204,316 ops/sec.
> 5. Logback: Async jactor2 Appender (1 thread): 9,001,575 ops/sec.
> 6. Logback: Async jactor Appender (1 thread): 8,482,989 ops/sec.
> 7. Log4j2: Loggers all async (1 thread): 8,394,794 ops/sec.
> 8. Logback: Async disruptor Appender (2 threads): 8,207,580 ops/sec.
> 9. Log4j2: Async Appender (2 threads): 7,658,818 ops/sec.
> 10. Log4j2: Async Appender (1 thread): 7,408,055 ops/sec.
> 11. Logback: Async jactor2 Appender (4 threads): 5,363,908 ops/sec.
> 12. Log4j2: Loggers all async (2 threads): 4,860,704 ops/sec.
> 13. Logback: Async jactor Appender (4 threads): 4,637,032 ops/sec.
> 14. Logback: Async jactor2 Appender (2 threads): 3,478,812 ops/sec.
> 15. Logback: Async jactor Appender (2 threads): 2,973,170 ops/sec.
> 
> 
> On Monday, August 26, 2013, Ralph Goers wrote:
>> Remko - I thought you might want to look at this - 
>> https://github.com/cp149/jactor-logger
>> 
>> Ralph


[jira] [Created] (LOG4J2-370) Log4j2 & OSGi How-To

2013-08-26 Thread Roland Weiglhofer (JIRA)
Roland Weiglhofer created LOG4J2-370:


 Summary: Log4j2 & OSGi How-To
 Key: LOG4J2-370
 URL: https://issues.apache.org/jira/browse/LOG4J2-370
 Project: Log4j 2
  Issue Type: Documentation
  Components: API, Core, JCL Bridge, log4j 1.2 emulation, SLF4J Bridge
Affects Versions: 2.0-beta9
 Environment: OSGi R5 (e.g. Apache Felix)
Reporter: Roland Weiglhofer
Priority: Minor


The Log4j2-manual should provide a Quick-Start for OSGi-developers.

Very important: It is not enough that the core library is located in the same 
folder as the api. If log4j2 is used in an OSGi-environment, you have to 
specify the dependencies on the core and on the api in your POM, otherwise the 
libraries are not added to the bundle-ClassLoader. This leads to the error: 
'StatusLogger Unable to locate a logging implementation, using SimpleLogger.'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Created] (LOG4J2-369) How to include the log4j2 lib jar into a jar with my application class and run it ?

2013-08-26 Thread wei wang (JIRA)
wei wang created LOG4J2-369:
---

 Summary: How to include the log4j2 lib jar into a jar with my 
application class and run it ?
 Key: LOG4J2-369
 URL: https://issues.apache.org/jira/browse/LOG4J2-369
 Project: Log4j 2
  Issue Type: Bug
Reporter: wei wang


I used ant to build a app.jar which has log4j2.xml in the jar, however when I 
run the jar, it will miss the log4j2-core***.jar and log4j2-api***.jar as the 
lib. But I need to distribute the lib together with my app.jar as one jar file 
and run the app.jar(with the exlib in the jar), please tell me how to do that?

I have tried simply pack the log4j2***.jar into the app.jar, but never print 
out any log, I think somehow must set the path inside jar to point the 
log4j2.properties in the log4j-***.jar file.

Thanks!


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



Re: jactor-logger

2013-08-26 Thread Remko Popma
I took a look. Still a bit rough, but people have started to integrate the
disruptor into Logback.
Unfortunately cp149 did not mention the software versions used, what OS
they ran the performance test on, or any detail on the hardware they used
(number of cores would be nice to know...), so it is hard to say anything
about their performance results.
I re-arranged the ranking by total throughput (threads x throughput/thread)
below.

Observations:
1. Log4j2 Async Appender does very well (beats Log4j2 Async Loggers and
Logback jactor in all multi-threaded scenarios but one)
2. Logback Async disruptor roughly equivalent to Log4j2 Async Loggers and
Async Appender (but hard to tell)
3. in the 2-thread scenario Logback Async disruptor is much better than
Log4j2 Async Loggers (strange... Noise?)
4. Logback jactor (non-disruptor) appenders only do reasonably well in 1
thread scenarios, performance degrades in multi-thread scenarios

My guess is this was run on Windows, my Windows performance results have
also been noisy and much less consistent than Unix results.
(Which reminds me, I should re-run the tests as we've made performance
improvements and fixed memory leaks...)

Ranking in total throughput (threads x throughput/thread):
1. Log4j2: Async Appender (4 threads): 10,632,480 ops/sec.
2. Logback: Async disruptor Appender (1 thread): 9,993,043 ops/sec.
3. Log4j2: Loggers all async (4 threads): 9,922,628 ops/sec.
4. Logback: Async disruptor Appender (4 threads): 9,204,316 ops/sec.
5. Logback: Async jactor2 Appender (1 thread): 9,001,575 ops/sec.
6. Logback: Async jactor Appender (1 thread): 8,482,989 ops/sec.
7. Log4j2: Loggers all async (1 thread): 8,394,794 ops/sec.
8. Logback: Async disruptor Appender (2 threads): 8,207,580 ops/sec.
9. Log4j2: Async Appender (2 threads): 7,658,818 ops/sec.
10. Log4j2: Async Appender (1 thread): 7,408,055 ops/sec.
11. Logback: Async jactor2 Appender (4 threads): 5,363,908 ops/sec.
12. Log4j2: Loggers all async (2 threads): 4,860,704 ops/sec.
13. Logback: Async jactor Appender (4 threads): 4,637,032 ops/sec.
14. Logback: Async jactor2 Appender (2 threads): 3,478,812 ops/sec.
15. Logback: Async jactor Appender (2 threads): 2,973,170 ops/sec.


On Monday, August 26, 2013, Ralph Goers wrote:

> Remko - I thought you might want to look at this -
> https://github.com/cp149/jactor-logger
>
> Ralph
>


[Bug 55481] New: Log4J Configuration in Virgo Jetty Server

2013-08-26 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=55481

Bug ID: 55481
   Summary: Log4J Configuration in Virgo Jetty Server
   Product: Log4j
   Version: unspecified
  Hardware: PC
OS: Windows Vista
Status: NEW
  Severity: normal
  Priority: P2
 Component: Configurator
  Assignee: log4j-dev@logging.apache.org
  Reporter: vijay.alla-non-e...@moodys.com

Log4J configuration in Virgo jetty server is not creating the logs files at
server side for deployed bundles.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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