Re: Status of Chainsaw

[Scott Deboy]

I continue to tweak it occasionally, not much lately. Not updating release
because I never got around to branding.

The dmg is for x86 but I've been updating snapshots on people.

It has a lot of good features now but has warts (timestamp parsing slowness
mostly).

I will continue to tweak it but I won't be porting it to log4j 2.  The fact
that it uses log4j 1 internally is an implementation detail in my mind, one
I would rather have changed out but never did.

Chainsaw doesn't need log4j 2 serial format compatibility go be useful. Its
primary use in my view is reading arbitrary text log files which it does
pretty well.

Scott
On Feb 7, 2016 10:31 PM, "Ralph Goers"  wrote:

> Log4j 1 is now at end of life. As I understand it Chainsaw is still
> targeted at Log4j 1.  The download page says the last build date was in
> 2006.  The OS X .dmg file doesn’t work as it is for the PowerPC, which
> Apple hasn’t supported in quite a while.
>
> I do see commits in pom.xml that suggest work was in progress to support
> Log4j 2 but that was in February 2013 - 3 years ago.
>
> What is the status of the project?
>
> Ralph
>
>
>
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>

Re: [VOTE] EOL for Log4j 1.x

[Scott Deboy]

+1
On Jul 11, 2015 8:29 AM, Ralph Goers ralph.go...@dslextreme.com wrote:

 +1

 Ralph

  On Jul 11, 2015, at 7:15 AM, Christian Grobmeier grobme...@apache.org
 wrote:
 
  Hello all,
 
  as previously discussed, this is a vote to label Log4j 1.x as EOL.
 
  This means:
 
  1. label Log4j 1.x as EOL on the main page
  2. Add a note to the Log4j 1.x download section that we are not
  maintaining this version anymore
  3. place a prominent EOL announcement on the Welcome page
  4. work with Apache Marketing/Publicity on a press release regarding the
  EOL
  5. announce the Log4j 1 EOL on our mailing lists and announce@ using
  this press release.
 
  This vote will stay open for at least 3 days.
 
  Here is my +1
 
  Thanks,
 
  Christian
 
  -
  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: [chainsaw] Code Signing Services

[Scott Deboy]

Yes - infra finally finished this!

I've already filed a jira. https://issues.apache.org/jira/browse/INFRA-8439

Maybe we will finally get this out the door.

Scott

Scott
On Oct 16, 2014 5:11 AM, Christian Grobmeier grobme...@gmail.com wrote:

 Hi all,

 specifically this is a question to Scott:
 wouldn't this:
 https://blogs.apache.org/infra/entry/code_signing_service_now_available
 solve the problems we had with releasing Chainsaw?

 Regards
 Christian

 --
   Christian Grobmeier
   grobme...@gmail.com

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

Requesting Chainsaw code signing cert

[Scott Deboy]

FYI, I filed https://issues.apache.org/jira/browse/INFRA-8439 -
Logging Services Chainsaw code signing support

Scott

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

Re: [5/7] git commit: Note correct signing key for distribution.

[Scott Deboy]

Chainsaw is actually the immediate need for the code signing cert.

Scott
 On Aug 29, 2014 9:19 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 Why can’t it be used to sign release artifacts?

 Ralph

 On Aug 29, 2014, at 7:55 PM, Matt Sicker boa...@gmail.com wrote:

 Oh that's definitely a different signing key. That's supposed to make it
 possible for Log4j to be embedded in Java WebStart and Applet programs that
 all rely on code signing for general security. I believe the idea is that
 the code can be signed by some build server during release to prevent
 leaking our key.


 On 29 August 2014 21:51, Ralph Goers ralph.go...@dslextreme.com wrote:

 What is the story with the ASF code signing key. Matt, I noticed that you
 added Log4j 2 to the Jira issue.

 Ralph

 On Aug 29, 2014, at 7:31 PM, mattsic...@apache.org wrote:

  Note correct signing key for distribution.
 
 
  Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
  Commit:
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/066e1855
  Tree:
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/066e1855
  Diff:
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/066e1855
 
  Branch: refs/heads/master
  Commit: 066e1855e7ed4a349904809f4bd866aa9ca85a2e
  Parents: a2c18b6
  Author: Matt Sicker mattsic...@apache.org
  Authored: Fri Aug 29 18:56:46 2014 -0500
  Committer: Matt Sicker mattsic...@apache.org
  Committed: Fri Aug 29 18:56:46 2014 -0500
 
  --
  src/site/apt/download.apt.vm | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
  --
 
 
 
 http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/066e1855/src/site/apt/download.apt.vm
  --
  diff --git a/src/site/apt/download.apt.vm b/src/site/apt/download.apt.vm
  index dea8abc..e4b2f26 100644
  --- a/src/site/apt/download.apt.vm
  +++ b/src/site/apt/download.apt.vm
  @@ -54,7 +54,8 @@ Download Apache Log4j 2
  % gpg --verify apache-log4j-${Log4jReleaseVersion}-bin.tar.gz.asc
  ---
 
  -Apache Log4j 2 is signed by Ralph Goers  B3D8E1BA
  +~~Apache Log4j 2 is signed by Ralph Goers  B3D8E1BA
  +Apache Log4j ${Log4jReleaseVersion} is signed by Matt Sicker
 (FA1C814D)
 
  Alternatively, you can verify the MD5 signature on the files. A
 unix program called md5 or md5sum is included
  in many unix distributions.
  @@ -76,4 +77,4 @@ log4j-api-${Log4jReleaseVersion}.jar
  log4j-core-${Log4jReleaseVersion}.jar
  ---
 
  -  You can do this from the command line or a manifest file.
  \ No newline at end of file
  +  You can do this from the command line or a manifest file.
 


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




 --
 Matt Sicker boa...@gmail.com

Re: [VOTE] Switch Log4j2 to Git

[Scott Deboy]

+1
On Aug 5, 2014 7:18 AM, Matt Sicker boa...@gmail.com wrote:

 This topic was brought up elsewhere, so I'd like to propose a vote on
 switching to Git.

 +1 for me

 --
 Matt Sicker boa...@gmail.com

Re: Finding free ports

[Scott Deboy]

+1

On 6/26/14, Gary Gregory garydgreg...@gmail.com wrote:
 Or you could not run tests in parallel and keep it simple. This is not a
 problem that needs solving and make the code harder to understand and
 maintain.

 Gary


 On Thu, Jun 26, 2014 at 4:50 PM, Matt Sicker boa...@gmail.com wrote:

 A neat improvement to the port finder thing would be a way for it to work
 over multiple JVMs. That is, it won't work reliably when you use the fork
 option in surefire. The only workaround I know would be to use different
 starting ports for every test (separated by about 50-100 ports perhaps?).
 Kind of hard to enforce a lock or singleton across VMs without some
 networking code which would get a bit complicated. Then again, maybe not
 so
 much. I might try this out sometime.


 On 26 June 2014 10:00, Gary Gregory garydgreg...@gmail.com wrote:

 I got rid of the new finder class in favor of the existing one. If I
 reuse the one from Mina it does not work due to port range issues.

 Gary

 Gary


  Original message 
 From: Matt Sicker
 Date:06/25/2014 11:02 (GMT-05:00)
 To: Log4J Developers List
 Subject: Re: Finding free ports

 I think AvailablePortFinder was a class I copied from Camel.


 On 24 June 2014 23:24, Gary Gregory garydgreg...@gmail.com wrote:

 We have two ways of finding free socket ports:

 - org.apache.logging.log4j.test.AvailablePortFinder has been around for
 a while, and
 - org.apache.logging.log4j.core.net.FreePortFinder which is a new class
 I refactored out of a bunch of duplicate code in the Flume tests.

 We need to pick on way of doing this. FreePortFinder gets my vote
 because it is simpler.

 Thoughts?

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




 --
 Matt Sicker boa...@gmail.com




 --
 Matt Sicker boa...@gmail.com




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: debug output

[Scott Deboy]

+1
On Jun 15, 2014 4:05 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 Do we need the builders?  As I said, I prefer only one way for creating
 plugins.

 Ralph

 On Jun 15, 2014, at 2:49 PM, Remko Popma remko.po...@gmail.com wrote:

 I see. I agree that the original format is much nicer.

 Matt, do you think you can achieve this with the builders?

 Sent from my iPhone

 On 2014/06/16, at 1:29, Ralph Goers ralph.go...@dslextreme.com wrote:

 While you improved some of the existing messages, you really didm’t
 address what I wanted fixed. The previous debug logs would have had
 messages similar to:

 Calling createLayout on class
 org.apache.logging.log4j.core.layout.PatternLayout for element
 PatternLayout with params(pattern=%d{HH:mm:ss.SSS} [%t] %-5level
 %logger{36} - %msg%n,
 Configuration(D:\rista\eclipsekws\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps\log4j2.0-test\WEB-INF\classes\test-log4j.xml),
 null, charset=null, alwaysWriteExceptions=null)

 Calling createAppender on class
 org.apache.logging.log4j.core.appender.ConsoleAppender for element Console
 with params(PatternLayout(%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
 %msg%n), null, target=SYSTEM_OUT, name=console, follow=null,
 ignoreExceptions=null)

 Calling createAppenderRef on class
 org.apache.logging.log4j.core.config.AppenderRef for element appender-ref
 with params(ref=console, level=null, null)
 2013-09-20 15:06:55,749 DEBUG Calling createLogger on class
 org.apache.logging.log4j.core.config.LoggerConfig$RootLogger for element
 root with params(additivity=null, level=error, includeLocation=null,
 AppenderRef={console}, Properties={},
 Configuration(D:\rista\eclipsekws\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps\log4j2.0-test\WEB-INF\classes\test-log4j.xml),
 null)

 The current log emits stuff like:

 2014-06-15 09:07:19,432 DEBUG Building Plugin[name=layout,
 class=org.apache.logging.log4j.core.layout.XmlLayout]. Searching for
 builder factory method...
 2014-06-15 09:07:19,435 DEBUG No builder factory method found in class
 org.apache.logging.log4j.core.layout.XmlLayout.
 2014-06-15 09:07:19,435 DEBUG Still building Plugin[name=layout,
 class=org.apache.logging.log4j.core.layout.XmlLayout]. Searching for
 factory method...
 2014-06-15 09:07:19,436 DEBUG Found factory method [createLayout]: public
 static org.apache.logging.log4j.core.layout.XmlLayout
 org.apache.logging.log4j.core.layout.XmlLayout.createLayout(boolean,boolean,boolean,boolean,java.nio.charset.Charset).
 2014-06-15 09:07:19,436 DEBUG Generating parameters for factory method
 [createLayout]...
 2014-06-15 09:07:19,456 DEBUG Attribute(locationInfo=false) - no value
 specified, using default.
 2014-06-15 09:07:19,456 DEBUG Attribute(properties=false) - no value
 specified, using default.
 2014-06-15 09:07:19,457 DEBUG Attribute(complete=true) - no value
 specified, using default.
 2014-06-15 09:07:19,457 DEBUG Attribute(compact=false) - no value
 specified, using default.
 2014-06-15 09:07:19,457 DEBUG Attribute(charset=UTF-8) - no value
 specified, using default.
 2014-06-15 09:07:19,587 DEBUG Built Plugin[name=layout] OK from factory
 method.
 2014-06-15 09:07:19,588 DEBUG Building Plugin[name=appender,
 class=org.apache.logging.log4j.core.appender.FileAppender]. Searching for
 builder factory method...
 2014-06-15 09:07:19,588 DEBUG No builder factory method found in class
 org.apache.logging.log4j.core.appender.FileAppender.
 2014-06-15 09:07:19,589 DEBUG Still building Plugin[name=appender,
 class=org.apache.logging.log4j.core.appender.FileAppender]. Searching for
 factory method...
 2014-06-15 09:07:19,589 DEBUG Found factory method [createAppender]:
 public static org.apache.logging.log4j.core.appender.FileAppender
 org.apache.logging.log4j.core.appender.FileAppender.createAppender(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,org.apache.logging.log4j.core.Layout,org.apache.logging.log4j.core.Filter,java.lang.String,java.lang.String,org.apache.logging.log4j.core.config.Configuration).
 2014-06-15 09:07:19,589 DEBUG Generating parameters for factory method
 [createAppender]...
 2014-06-15 09:07:19,595 DEBUG
 Attribute(fileName=target/XmlCompleteFileAppenderTest.log)
 2014-06-15 09:07:19,596 DEBUG Attribute(append=false)
 2014-06-15 09:07:19,596 DEBUG Attribute(locking=null)
 2014-06-15 09:07:19,596 DEBUG Attribute(name=XmlFile)
 2014-06-15 09:07:19,597 DEBUG Attribute(immediateFlush=false)
 2014-06-15 09:07:19,597 DEBUG Attribute(ignoreExceptions=null)
 2014-06-15 09:07:19,597 DEBUG Attribute(bufferedIo=null)
 2014-06-15 09:07:19,598 DEBUG Attribute(bufferSize=null)
 2014-06-15 09:07:19,598 DEBUG
 XMLLayout(org.apache.logging.log4j.core.layout.XmlLayout@5eef9f84)
 2014-06-15 09:07:19,598 DEBUG Attribute(advertise=null)
 2014-06-15 09:07:19,599 DEBUG Attribute(advertiseUri=null)
 2014-06-15 09:07:19,599 DEBUG
 

Re: [jira] [Commented] (LOG4J2-665) Unable to connect from log4j2 Client GUI to my application

[Scott Deboy]

I'd suggest trying the latest developer snapshot of Chainsaw, available at
http://people.apache.org/~sdeboy

Scott
 On Jun 11, 2014 8:56 AM, Arthur Hsieh (JIRA) j...@apache.org wrote:


 [
 https://issues.apache.org/jira/browse/LOG4J2-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027940#comment-14027940
 ]

 Arthur Hsieh commented on LOG4J2-665:
 -

 No worries, and thank you for spending the time to clarify my questions.

 Just one last question, is it normal that under the log4j2 tab, i see
 LoggerContext: sun.misc.Launcher$AppClassLoader@3b26456a instead of
 LoggerContext: AsyncLoggerContext.  The reason why I ask this is because
 the screenshot shown on
 http://logging.apache.org/log4j/2.x/manual/jmx.html#ClientGUI shows the
 AynscLoggerContext, and the contents seem like output of actual logs..

 Thanks once again, i'll definitely checkout chainsaw.  Cheers.

  Unable to connect from log4j2 Client GUI to my application
  --
 
  Key: LOG4J2-665
  URL: https://issues.apache.org/jira/browse/LOG4J2-665
  Project: Log4j 2
   Issue Type: Bug
   Components: JMX
 Affects Versions: 2.0-rc1
  Environment: OS: OSX Mavericks 10.9.3
  IDE: Netbeans 8.0 (Build 201403101706)
  Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08
  log4j: 2.0rc1
 Reporter: Arthur Hsieh
  Attachments: Screen Shot 2014-06-10 at 15.41.36.png, Screen Shot
 2014-06-10 at 15.42.33.png, log4j2.xml
 
 
  I am unable to connect from the log4j2 Client GUI, regardless of whether
 running it as a JConsole Plug-in, or running it as a standalone application.
  Below are details of what I've used in my attempts:
  My application
  - ran from Netbeans, with these VM arguments:
  -Djava.security.policy=~/Downloads/policy
 -Djavax.management.builder.initial= -Dcom.sun.management.jmxremote
 -Dcom.sun.management.jmxremote.port=9010
 -Dcom.sun.management.jmxremote.local.only=false
 -Dcom.sun.management.jmxremote.authenticate=false
 -Dcom.sun.management.jmxremote.ssl=false
  - I've tried various ports: 9010, 1099, 33445 etc
  - Content of my policy file (I've allowed everything):
  grant {
  permission java.security.AllPermission;
  };
  Running the Client GUI as a JConsole Plug-in
  - command I used to execute:
  jconsole -pluginpath
 ~/Downloads/Software/Development/Java/log4j/2.0/rc1/apache-log4j-2.0-rc1-bin/log4j-core-2.0-rc1.jar:~/Downloads/Software/Development/Java/log4j/2.0/rc1/apache-log4j-2.0-rc1-bin/log4j-jmx-gui-2.0-rc1.jar
  - The JConsole starts without issue, but I don't see the Log4j2 tab as
 per the manual (http://logging.apache.org/log4j/2.x/manual/jmx.html)
  Running the Client GUI as a Stand-alone Application
  - command I used to execute (I'm running this from the directory where
 the JARs are:
  java -cp log4j-core-2.0-rc1.jar:log4j-jmx-gui-2.0-rc1.jar
 org.apache.logging.log4j.jmx.gui.ClientGUI localhost:9010
  - however, i getting a java.lang.NoClassDefFoundError:
  Exception in thread AWT-EventQueue-0 java.lang.NoClassDefFoundError:
 org/apache/logging/log4j/status/StatusLogger
  at
 org.apache.logging.log4j.core.jmx.Server.clinit(Server.java:59)
  at
 org.apache.logging.log4j.jmx.gui.Client.getStatusLoggerAdmin(Client.java:143)
  at
 org.apache.logging.log4j.jmx.gui.ClientGUI.addWidgetForLoggerContext(ClientGUI.java:109)
  at
 org.apache.logging.log4j.jmx.gui.ClientGUI.populateWidgets(ClientGUI.java:98)
  at
 org.apache.logging.log4j.jmx.gui.ClientGUI.init(ClientGUI.java:81)
  at
 org.apache.logging.log4j.jmx.gui.ClientGUI$2.run(ClientGUI.java:276)
  at
 java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
  at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
  at java.awt.EventQueue.access$200(EventQueue.java:103)
  at java.awt.EventQueue$3.run(EventQueue.java:694)
  at java.awt.EventQueue$3.run(EventQueue.java:692)
  at java.security.AccessController.doPrivileged(Native Method)
  at
 java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
  at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
  at
 java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
  at
 java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
  at
 java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
  at
 java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
  at
 java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
  at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
  Caused by: java.lang.ClassNotFoundException:
 org.apache.logging.log4j.status.StatusLogger
  at 

[jira] [Commented] (LOG4J2-665) Unable to connect from log4j2 Client GUI to my application

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028637#comment-14028637
 ] 

Scott Deboy commented on LOG4J2-665:


I'd suggest trying the latest developer snapshot of Chainsaw - lots of new 
features, and is available at http://people.apache.org/~sdeboy

 Unable to connect from log4j2 Client GUI to my application
 --

 Key: LOG4J2-665
 URL: https://issues.apache.org/jira/browse/LOG4J2-665
 Project: Log4j 2
  Issue Type: Bug
  Components: JMX
Affects Versions: 2.0-rc1
 Environment: OS: OSX Mavericks 10.9.3
 IDE: Netbeans 8.0 (Build 201403101706)
 Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08
 log4j: 2.0rc1
Reporter: Arthur Hsieh
 Attachments: Screen Shot 2014-06-10 at 15.41.36.png, Screen Shot 
 2014-06-10 at 15.42.33.png, log4j2.xml


 I am unable to connect from the log4j2 Client GUI, regardless of whether 
 running it as a JConsole Plug-in, or running it as a standalone application.
 Below are details of what I've used in my attempts:
 My application
 - ran from Netbeans, with these VM arguments:
 -Djava.security.policy=~/Downloads/policy -Djavax.management.builder.initial= 
 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 
 -Dcom.sun.management.jmxremote.local.only=false 
 -Dcom.sun.management.jmxremote.authenticate=false 
 -Dcom.sun.management.jmxremote.ssl=false
 - I've tried various ports: 9010, 1099, 33445 etc
 - Content of my policy file (I've allowed everything):
 grant {
 permission java.security.AllPermission;
 };
 Running the Client GUI as a JConsole Plug-in
 - command I used to execute:
 jconsole -pluginpath 
 ~/Downloads/Software/Development/Java/log4j/2.0/rc1/apache-log4j-2.0-rc1-bin/log4j-core-2.0-rc1.jar:~/Downloads/Software/Development/Java/log4j/2.0/rc1/apache-log4j-2.0-rc1-bin/log4j-jmx-gui-2.0-rc1.jar
 - The JConsole starts without issue, but I don't see the Log4j2 tab as per 
 the manual (http://logging.apache.org/log4j/2.x/manual/jmx.html)
 Running the Client GUI as a Stand-alone Application
 - command I used to execute (I'm running this from the directory where the 
 JARs are:
 java -cp log4j-core-2.0-rc1.jar:log4j-jmx-gui-2.0-rc1.jar 
 org.apache.logging.log4j.jmx.gui.ClientGUI localhost:9010
 - however, i getting a java.lang.NoClassDefFoundError:
 Exception in thread AWT-EventQueue-0 java.lang.NoClassDefFoundError: 
 org/apache/logging/log4j/status/StatusLogger
 at org.apache.logging.log4j.core.jmx.Server.clinit(Server.java:59)
 at 
 org.apache.logging.log4j.jmx.gui.Client.getStatusLoggerAdmin(Client.java:143)
 at 
 org.apache.logging.log4j.jmx.gui.ClientGUI.addWidgetForLoggerContext(ClientGUI.java:109)
 at 
 org.apache.logging.log4j.jmx.gui.ClientGUI.populateWidgets(ClientGUI.java:98)
 at 
 org.apache.logging.log4j.jmx.gui.ClientGUI.init(ClientGUI.java:81)
 at 
 org.apache.logging.log4j.jmx.gui.ClientGUI$2.run(ClientGUI.java:276)
 at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
 at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
 at java.awt.EventQueue.access$200(EventQueue.java:103)
 at java.awt.EventQueue$3.run(EventQueue.java:694)
 at java.awt.EventQueue$3.run(EventQueue.java:692)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
 java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
 at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
 at 
 java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
 at 
 java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
 at 
 java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
 at 
 java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
 at 
 java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
 at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
 Caused by: java.lang.ClassNotFoundException: 
 org.apache.logging.log4j.status.StatusLogger
 at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 ... 20 more



--
This message was sent by Atlassian JIRA
(v6.2#6252

Re: Working on support for the properties file format.

[Scott Deboy]

We shouldn't close feature requests as won't fix. Someone may come along
later and decide to implement it.

It's ok to say no one is planning on working on the feature, and remind the
submitter that patches are welcome.

Scott

Scott
On Jun 9, 2014 6:46 AM, Paul Benedict pbened...@apache.org wrote:

 I remember a ticket (dunno which one) being closed out as Won't Fix for
 the properties format. Are you gong to reopen it since you're working on
 the feature?


 Cheers,
 Paul


 On Mon, Jun 9, 2014 at 8:43 AM, Matt Sicker boa...@gmail.com wrote:



 On Sunday, 8 June 2014, Remko Popma remko.po...@gmail.com wrote:

 With xml, you'd wrap all property ... tags in a properties
 encapsulating list element, but perhaps that is not needed in this format?

 So, instead of:
 log4j2.properties.property.key=value
 we could have:
 log4j2.property.key=value

 I like it.


 Also (and this is just a matter of taste), can we use appender and
 logger instead of the plural appenders/loggers?

 Also would prefer that. Both would require hard coded plugins instead of
 generic lookups, though. Unless maybe we added @PluginAliases for them :)


 What would the config for a root logger look like?

 That one is already implicit in the code. If you configure a logger
 named root, that's changed to  and treated as the root logger. Probably
 deserves some documentation, though.


 One more thing: do we still need the .name attribute?
 This seems a bit redundant:
 log4j2.appender.File.name=File
 Perhaps better to remove it so we won't have to deal with cases like
 this:
 log4j2.appender.File.name=NotFile



 Sent from my iPhone

 No, I guess not. But it could be optional because logger configs have
 long names.



 On 2014/06/09, at 8:02, Matt Sicker boa...@gmail.com wrote:

 I was thinking about that. It would make sense.

 I'm trying to figure out how to do this generically so that special
 cases don't need to be created. This file format is very limited, that's
 for sure.


 On 8 June 2014 17:10, Ralph Goers ralph.go...@dslextreme.com wrote:

 One thing you could do is remove the type attribute by doing:

 log4j2.appenders.STDOUT=Console

 Ralph


 On Jun 8, 2014, at 1:57 PM, Matt Sicker boa...@gmail.com wrote:

 https://paste.apache.org/e4m6

 Damn quick fingers.


 On 8 June 2014 15:57, Matt Sicker boa...@gmail.com wrote:

 Actually, what I'm trying to do first is convert the log4j-test1 file
 into a properties file before going anywhere with this. Basically, it'll
 have to be more like the XML strict format. Here's how I've converted it
 (as you can see, this file format sucks):



 On 8 June 2014 15:20, Matt Sicker boa...@gmail.com wrote:

 So far it's awkward, but so was the original format.


 On 8 June 2014 15:07, Paul Benedict pbened...@apache.org wrote:

 Ooops. Yes, XSL. The use of the XSL is to show that it's really possible
 to convert an XML file into a flat file that's useable.


 Cheers,
 Paul


 On Sun, Jun 8, 2014 at 2:40 PM, Matt Sicker boa...@gmail.com wrote:

 Of course XML is the better format. Like I said, I don't even use the
 properties file format. However, plenty of people still do, so it seems
 beneficial to allow it in some form.

 Do you mean an XSL file?


 On 8 June 2014 14:21, Paul Benedict pbened...@apache.org wrote:

 I still think XML is a better format. But if you do allow property
 files, consider first an XSD file that converts XML to properties. Because
 if you can accomplish that, you will have proven to yourself that the
 property file can represent everything an XML file can.
  On Jun 8, 2014 2:00 PM, Matt Sicker boa...@gmail.com wrote:

 I'm only working on this because it sounds interesting and has been
 requested by several people. I personally never use this file format in
 Log4j 1, so I'm not entirely sure on how to best maintain compatibility or
 similarity to the old format.



 --
 Matt Sicker boa...@gmail.com

Re: [VOTE Results] Log4j 2 logo

[Scott Deboy]

+1
On Jun 6, 2014 10:07 PM, Matt Sicker boa...@gmail.com wrote:

 I like both logos, so I'm good with however you guys would like to go.
 Vote or not.


 On 6 June 2014 20:57, Remko Popma remko.po...@gmail.com wrote:

 Scott, Matt, what do you think?


 On Sat, Jun 7, 2014 at 10:48 AM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 However, I am perfectly happy going with A even though I voted for D. If
 others who voted for D feel the same way we can just declare A the winner

 Sent from my iPhone

 On Jun 6, 2014, at 6:44 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 We should start a new vote thread if that is how we want to go.

 Sent from my iPhone

 On Jun 6, 2014, at 6:43 PM, Bruce Brouwer bruce.brou...@gmail.com
 wrote:

 Sorry, I meant to say *without* D as an option. I don't mind a quick
 vote between A and D. Here's my vote:

 A


 On Fri, Jun 6, 2014 at 9:14 PM, Remko Popma remko.po...@gmail.com
 wrote:

 Personally I don't mind either A or D.
 If the tool says D, I'm fine with D. If there's doubt, then let's have
 another quick vote between these two.

 Sent from my iPhone

 On 2014/06/07, at 10:06, Gary Gregory garydgreg...@gmail.com wrote:

 Well, I am happy to reconsider since D is my last place vote ;-) I just
 don't get the whole fish/Jesus thing...

 Gary


 On Fri, Jun 6, 2014 at 4:03 PM, Ralph Goers ralph.go...@dslextreme.com
  wrote:


 Below are the results from STV as calculated by
 http://paul-lockett.co.uk/stv.html.  This indicates that D is the
 winning logo.  However, after looking at the votes it isn’t clear to me 
 why
 A isn’t the winner as it had more first and second place votes.  also, if
 you go through the votes and rank A and D based on which is ranked highest
 in each vote you would get A - 4,  D - 3.

 Thoughts?

 Ralph


 SINGLE TRANSFERABLE VOTE COUNTER
 *Candidates=9 Seats=1 Votes=7 Quota=3.5*
 Raw votes
 vote 1: (D) (A) (B) (I) (E) (F) (H) (G) (C)
 vote 2: (D) (B) (A) (H) (C) (I) (E) (F) (G)
 vote 3: (H) (E) (F) (A) (B) (C) (I) (G) (D)
 vote 4: (G) (C) (D) (I) (H) (F) (A) (B) (E)
 vote 5: (H) (G) (I) (A) (E) (F) (B) (D) (C)
 vote 6: (A) (C) (B) (H) (G) (D) (I) (E) (F)
 vote 7: (A) (B) (D) (H) (C) (E) (F) (G) (I)
 *Round 1 votes*
 vote 1: (D) (A) (B) (I) (E) (F) (H) (G) (C) vote value = 1
 vote 2: (D) (B) (A) (H) (C) (I) (E) (F) (G) vote value = 1
 vote 3: (H) (E) (F) (A) (B) (C) (I) (G) (D) vote value = 1
 vote 4: (G) (C) (D) (I) (H) (F) (A) (B) (E) vote value = 1
 vote 5: (H) (G) (I) (A) (E) (F) (B) (D) (C) vote value = 1
 vote 6: (A) (C) (B) (H) (G) (D) (I) (E) (F) vote value = 1
 vote 7: (A) (B) (D) (H) (C) (E) (F) (G) (I) vote value = 1
 A = 2
 B = 0
 C = 0
 D = 2
 E = 0
 F = 0
 G = 1
 H = 2
 I = 0

 Fewest votes won by a candidate = 1.
 Number of candidates with the fewest votes = 1.
 G is eliminated.
 *Round 2 votes*
 vote 1: (D) (A) (H) vote value = 1
 vote 2: (D) (A) (H) vote value = 1
 vote 3: (H) (A) (D) vote value = 1
 vote 4: (D) (H) (A) vote value = 1
 vote 5: (H) (A) (D) vote value = 1
 vote 6: (A) (H) (D) vote value = 1
 vote 7: (A) (D) (H) vote value = 1
 A = 2
 B = 0
 C = 0
 D = 3
 E = 0
 F = 0
 G = 0
 H = 2
 I = 0

 Fewest votes won by a candidate = 2.
 Number of candidates with the fewest votes = 2.
 The tiebreaker loser is A.
 A is eliminated.
 *Round 3 votes*
 vote 1: (D) (H) vote value = 1
 vote 2: (D) (H) vote value = 1
 vote 3: (H) (D) vote value = 1
 vote 4: (D) (H) vote value = 1
 vote 5: (H) (D) vote value = 1
 vote 6: (H) (D) vote value = 1
 vote 7: (D) (H) vote value = 1
 A = 0
 B = 0
 C = 0
 D = 4
 E = 0
 F = 0
 G = 0
 H = 3
 I = 0

 Most votes currently held by a candidate = 4.
 Number of candidates with the greatest number of votes = 1.
 D has exceeded the quota and is elected. If there are seats remaining
 to be filled, the surplus will now be reallocated.
 *The election is complete and the elected candidates are (D).*


 On Jun 6, 2014, at 12:25 PM, Christian Grobmeier grobme...@gmail.com
 wrote:

 My vote: ABDHCEFGI

 Thanks!

 On 3 Jun 2014, at 22:08, Ralph Goers wrote:

 It is time to select a logo. The list of candidates can be found at
 https://wiki.apache.org/logging/Log4jLogoNominations as those having
 at least two supporters and are arbitrarily identified as A through I.

 This vote will use STV to calculate the results.  This means your vote
 should consist of from 1 to 9 letters identifying the logos in order of
 preference from first to last.

 The key idea to keep in mind is that the ordering of your votes is
 crucial. Those who you *really* want to be elected should be at the
 beginning/start of the list. For example:

 Aragorn, Frodo, Bilbo, Sam, Sauron, Gandalf, Treebeard, Gollum, Gimli

 means that you really want Aragorn to be elected (he’s your primary
 preferred person), followed by Frodo (you want Frodo on the board more 
 than
 you want Bilbo, Sam and Sauron, but not as much as you want Aragorn),
 followed by Bilbo, etc…

 In this vote only the top logo will be selected but STV will identify
 the 

Re: [VOTE] Log4j 2 logo

[Scott Deboy]

And mine:

DBAHCIEFG


On 6/3/14, Ralph Goers ralph.go...@dslextreme.com wrote:
 In case it is not clear, the names (Aragorn, etc) below are for some other
 fictional vote to illustrate how to vote

 Here is my vote:

 DABIEFHGC

 Ralph

 On Jun 3, 2014, at 1:08 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 It is time to select a logo. The list of candidates can be found at
 https://wiki.apache.org/logging/Log4jLogoNominations as those having at
 least two supporters and are arbitrarily identified as A through I.

 This vote will use STV to calculate the results.  This means your vote
 should consist of from 1 to 9 letters identifying the logos in order of
 preference from first to last.

 The key idea to keep in mind is that the ordering of your votes is
 crucial. Those who you *really* want to be elected should be at the
 beginning/start of the list. For example:

   Aragorn, Frodo, Bilbo, Sam, Sauron, Gandalf, Treebeard, Gollum, Gimli

 means that you really want Aragorn to be elected (he’s your primary
 preferred person), followed by Frodo (you want Frodo on the board more
 than you want Bilbo, Sam and Sauron, but not as much as you want Aragorn),
 followed by Bilbo, etc…

 In this vote only the top logo will be selected but STV will identify the
 winner using all the votes.

 This vote will remain open for 72 hours. In accordance with the rules
 listed in LOG4J2-316 votes of all Logging committers are binding.



 -
 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: Can any PMCs or chairs take a look at this?

[Scott Deboy]

Nope, it just shows my personal repositories, even though I am part of
the 'Apache' organization in GitHub.

On 4/14/14, Matt Sicker boa...@gmail.com wrote:
 https://travis-ci.org/apache/logging-log4j2

 If you log in with your GitHub account, does it give you any administrative
 options? Particularly from the upper right corner gearbox thing.

 --
 Matt Sicker boa...@gmail.com


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

Re: org.apache.log4j.net.XMLSocketReceiver from v1

[Scott Deboy]

We need to add receivers to log4j2 :)

Dcott
On Mar 25, 2014 5:19 AM, Gary Gregory garydgreg...@gmail.com wrote:

 Hi All:

 Our server uses v1's org.apache.log4j.net.XMLSocketReceiver.

 I do not see a v2 equivalent.

 Thoughts?

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: Are there any plans to add more log4languages?

[Scott Deboy]

Many of those already exist outside of Apache.

Scott
On Mar 14, 2014 2:29 PM, Matt Sicker boa...@gmail.com wrote:

 I see we have log4j, log4net, log4php, and log4cxx. How about Python,
 Ruby, Perl, etc.? Anything incubating? Anyone interested in working on one?

 --
 Matt Sicker boa...@gmail.com

Re: Health

[Scott Deboy]

Hi Ralph,

Glad to hear you're getting better!

Scott

On 2/21/14, Gary Gregory garydgreg...@gmail.com wrote:
 Ralph,

 It is great to hear that you are out of the hospital! Please do take care
 of yourself and don't overdo it ;) Log4J can wait... :)

 Gary


 On Fri, Feb 21, 2014 at 12:19 AM, Ralph Goers
 ralph.go...@dslextreme.comwrote:

 I just wanted to let you all know that I am out of the hospital and am
 now
 continuing to get better at home. I still require oxygen so I have a bit
 of
 a ways to go, but at least I now have access to my computer.

 Ralph
 -
 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
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: [VOTE] Log4j 2.0-rc1 RC2

[Scott Deboy]

 in the
 Automatic Configuration section Thanks to Michael Diamond, Matt Sicker.
 o LOG4J2-408:  Fixed error in documentation code example in
 manual/eventlogging.html Thanks to Dongqing Hu, Matt Sicker.
 o LOG4J2-451:  Fixed typo in documentation: system property should be
 log4j2.loggerContextFactory Thanks to Vinay Pothnis, Matt Sicker.
 o LOG4J2-443:  Fixed issue where log4j2 LoggerContext did not show up
 in
 JMX GUI or JConsole. Thanks to Colin Froggatt, Tudor Har.
 o LOG4J2-485:  Fixed issue where toString methods that perform logging
 could deadlock AsyncAppender.
 o LOG4J2-445:  ResolverUtil cannot find packages in file URLs which
 include the '+' character. Thanks to Anthony Baldocchi.
 o LOG4J2-430:  Use the formatted Message in RFC5424Layout for
 non-StructuredDataMessages. Thanks to David Gstir.
 o LOG4J2-459:  Set external context when constructing the
 LoggerContext.
 o LOG4J2-466:  Cannot load log4j2 config file if path contains plus '+'
 characters. Thanks to Jan Tepke.
 o LOG4J2-462:  Fix LogEvent to never return null Level, fixes
 LevelPatternConverter.format may throw NPE. Thanks to Daisuke Baba.
 o LOG4J2-465:  Fix LogEvent to never return null Level, fixes
 ThresholdFilter throws NPE. Thanks to Daisuke Baba.
 o LOG4J2-471:  Fixed issue where toString methods that perform logging
 could deadlock AsyncLogger. Thanks to Anthony Baldocchi.
 o LOG4J2-478:  The message and ndc fields are not JavaScript escaped in
 JSONLayout. Thanks to Michael Friedmann..
 o LOG4J2-455:  RingBufferLogEvent should return Message timestamp for
 TimestampMessage messages. Thanks to Robin Zhang Tao.
 o LOG4J2-477:  NPE in ClassLoaderContextSelector. Thanks to Tal Liron.
 o LOG4J2-454:  TimeBasedTriggeringPolicy should use event time millis.
 Thanks to Robin Zhang Tao.
 o LOG4J2-472:  BaseConfiguration class does not properly implement
 Configuration interface. Thanks to Tal Liron.
 o LOG4J2-447:  XMLLayout does not include marker name. Thanks to Jeff
 Hudren, Mark Paluch, Scott Deboy.
 o LOG4J2-323:  Resolved memory leak by releasing reference to
 ThreadLocal when AsyncLogger is stopped.
 o LOG4J2-425:  Resolved memory leak by populating
 AsyncLoggerConfigHelper ring buffer via EventTranslatorTwoArg,
 eliminating
 the need for a ThreadLocal.
 o LOG4J2-417:  Fix Event Level / LoggerConfig Level table at the
 architecture documentation page.
 o LOG4J2-404:  @EnterpriseNumber was missing in the ID of structured
 data when RFC5424Layout is used Thanks to Kamal Bahadur.
 o LOG4J2-379:  Fixed issue that prevented Log4J from working in Google
 App Engine.

 Changes:
 o Renamed the org.apache.logging.log4j.core.appender.db.nosql.mongo
 package to org.apache.logging.log4j.core.appender.db.nosql.mongodb.
 o Renamed the org.apache.logging.log4j.core.appender.db.nosql.couch
 package to org.apache.logging.log4j.core.appender.db.nosql.couchdb.
 o LOG4J2-507:  Space Level numbers by 100 instead of 1.
 o LOG4J2-41:  Add support for custom logging levels. Thanks to Nick
 Williams.
 o LOG4J2-490:  Update EasyMock to version 3.2. Thanks to Matt Sicker.
 o LOG4J2-453:  Update Flume Appender to use Flume 1.4.0.
 o LOG4J2-528:  Rename package
 org.apache.logging.log4j.core.appender.rolling.helper to
 org.apache.logging.log4j.core.appender.rolling.action.
 o LOG4J2-532:  Resource leak in Flume appender when it cannot create a
 BerkeleyDB db.

 *Please test and cast your votes.*
 [ ] +1, release the artifacts
 [ ] -1, don't release because...

 The vote will remain open for 72 hours (or more if required).

 *Tag:*
 http://svn.apache.org/viewvc/logging/log4j/log4j2/tags/log4j-2.0-rc1/

 *SVN revision:* 1566354

 *Website:* http://people.apache.org/~nickwilliams/log4j/

 *Artifacts:*
 https://repository.apache.org/content/repositories/orgapachelogging-1002/

 The artifacts may be downloaded using
 wget -e robots=off --cut-dirs=3 -r -p -np --no-check-certificate
 https://repository.apache.org/content/repositories/orgapachelogging-1002/org/apache/logging/log4j/

 *Description:*

 2.0-rc1 RC2

 *Details:*

 The following artifacts have been staged to the org.apache.logging-1002
 (u:nickwilliams,
 a:69.180.246.95)https://repository.apache.org/content/repositories/orgapachelogging-1002
  repository.


 archetype-catalog.xmlhttps://repository.apache.org/content/repositories/orgapachelogging-1002/archetype-catalog.xml
 log4j-jmx-gui-2.0-rc1-javadoc.jarhttps://repository.apache.org/content/repositories/orgapachelogging-1002/org/apache/logging/log4j/log4j-jmx-gui/2.0-rc1/log4j-jmx-gui-2.0-rc1-javadoc.jar

 log4j-jmx-gui-2.0-rc1.jarhttps://repository.apache.org/content/repositories/orgapachelogging-1002/org/apache/logging/log4j/log4j-jmx-gui/2.0-rc1/log4j-jmx-gui-2.0-rc1.jar

 log4j-jmx-gui-2.0-rc1-sources.jarhttps://repository.apache.org/content/repositories/orgapachelogging-1002/org/apache/logging/log4j/log4j-jmx-gui/2.0-rc1/log4j-jmx-gui-2.0-rc1-sources.jar

 log4j-jmx-gui-2.0-rc1.jar.aschttps://repository.apache.org/content/repositories/orgapachelogging

Re: [VOTE] Log4j 2.0-rc1 RC2

[Scott Deboy]

I'll check it out..apologies!

On 2/11/14, Remko Popma remko.po...@gmail.com wrote:
 Gentle reminder: we need one more PMC vote to be able to release.

 On Tuesday, February 11, 2014, Christian Grobmeier grobme...@gmail.com
 wrote:

 I think Rat is wrong on the jquery license.

 They have included a header, but its not identified by rat.
 MIT is a clear yes for me. We have several other portions of MIT code
 inside AL code (i.e. commons compress if i recall correctly).

 If we want to put it into the NOTICE file we need to make sure to add
 bootstrap.min.js
 and prettify.min.js as well (both AL 2.0)

 I would not use a CDN because people might download it for a reason -
 maybe they
 have no real connection where they want to work with it.



 On 11 Feb 2014, at 3:20, Gary Gregory wrote:

  This should be documented clearly in our build (in this case, in the
 POM).

 Is the JQuery license compatible with ours?

 If you read https://www.apache.org/legal/resolved.html#category-a as a
 yes  then the files RAT complains about can be excluded from the
 report.
 If you read it as a no, then we cannot include JQuery.

 It reads like a yes to me.

 The next question is: Do we need to add JQuery to our NOTICE file?

 Gary





 On Mon, Feb 10, 2014 at 8:46 PM, Remko Popma remko.po...@gmail.com
 wrote:

  I agree with Nick.
 Didn't we discuss this before, for the beta-9 release (and came to the
 same conclusion)?


 On Tuesday, February 11, 2014, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

  I'm not sure what our policy is, either, but there's nothing we can do
 about it. We can't modify the license header of those files--that
 would
 be
 in violation of the license under which JQuery is made available. And
 ceasing to use JQuery would make the site not very good anymore.

 Either way, since this is JS for the site and not source code for
 Log4j,
 and since those files have been there for a very long time, I
 certainly
 don't think it should hold up this release.

 Nick

 On Feb 10, 2014, at 4:12 PM, Gary Gregory wrote:

 RAT complains:

 ***

 Unapproved licenses:

 src/site/resources/js/jquery.js
 src/site/resources/js/jquery.min.js

 ***

 I'm not sure what our policy is for this kind of issue.

 Gary



 On Mon, Feb 10, 2014 at 2:56 PM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:


 On Feb 9, 2014, at 1:56 PM, Nick Williams wrote:

 *This is a vote to release Log4j 2.0-rc1, the twelfth release of
 Log4j
 2.0.*

 snip /

 *Please test and cast your votes.*
 [x] +1, release the artifacts

 [ ] -1, don't release because...


 Nick




 -
 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: [VOTE] Log4j 2.0-rc1 RC2

[Scott Deboy]

+1

(site looks good, tag built fine with mvn install, artifacts look good)

Scott

On 2/11/14, Scott Deboy scott.de...@gmail.com wrote:
 I'll check it out..apologies!

 On 2/11/14, Remko Popma remko.po...@gmail.com wrote:
 Gentle reminder: we need one more PMC vote to be able to release.

 On Tuesday, February 11, 2014, Christian Grobmeier grobme...@gmail.com
 wrote:

 I think Rat is wrong on the jquery license.

 They have included a header, but its not identified by rat.
 MIT is a clear yes for me. We have several other portions of MIT code
 inside AL code (i.e. commons compress if i recall correctly).

 If we want to put it into the NOTICE file we need to make sure to add
 bootstrap.min.js
 and prettify.min.js as well (both AL 2.0)

 I would not use a CDN because people might download it for a reason -
 maybe they
 have no real connection where they want to work with it.



 On 11 Feb 2014, at 3:20, Gary Gregory wrote:

  This should be documented clearly in our build (in this case, in the
 POM).

 Is the JQuery license compatible with ours?

 If you read https://www.apache.org/legal/resolved.html#category-a as a
 yes  then the files RAT complains about can be excluded from the
 report.
 If you read it as a no, then we cannot include JQuery.

 It reads like a yes to me.

 The next question is: Do we need to add JQuery to our NOTICE file?

 Gary





 On Mon, Feb 10, 2014 at 8:46 PM, Remko Popma remko.po...@gmail.com
 wrote:

  I agree with Nick.
 Didn't we discuss this before, for the beta-9 release (and came to the
 same conclusion)?


 On Tuesday, February 11, 2014, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

  I'm not sure what our policy is, either, but there's nothing we can
 do
 about it. We can't modify the license header of those files--that
 would
 be
 in violation of the license under which JQuery is made available. And
 ceasing to use JQuery would make the site not very good anymore.

 Either way, since this is JS for the site and not source code for
 Log4j,
 and since those files have been there for a very long time, I
 certainly
 don't think it should hold up this release.

 Nick

 On Feb 10, 2014, at 4:12 PM, Gary Gregory wrote:

 RAT complains:

 ***

 Unapproved licenses:

 src/site/resources/js/jquery.js
 src/site/resources/js/jquery.min.js

 ***

 I'm not sure what our policy is for this kind of issue.

 Gary



 On Mon, Feb 10, 2014 at 2:56 PM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:


 On Feb 9, 2014, at 1:56 PM, Nick Williams wrote:

 *This is a vote to release Log4j 2.0-rc1, the twelfth release of
 Log4j
 2.0.*

 snip /

 *Please test and cast your votes.*
 [x] +1, release the artifacts

 [ ] -1, don't release because...


 Nick




 -
 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: CouchDb vs CouchDB

[Scott Deboy]

I do want to remind everyone that vetoes are only valid if they are backed
by a technical justification.

Scott
On Feb 7, 2014 8:07 AM, Nick Williams nicho...@nicholaswilliams.net
wrote:

 I'm not convinced it really makes a difference, but it's better than
 couchdb, so if the majority wants couchbase it I won't veto it. Be sure to
 change the test package name, too.

 Nick

 On Feb 7, 2014, at 10:03 AM, Scott Deboy wrote:

 +1 to couchbase
 On Feb 7, 2014 7:54 AM, Christian Grobmeier grobme...@gmail.com wrote:

 On 7 Feb 2014, at 16:19, Nick Williams wrote:

  It doesn't so much matter because the XML element names are case
 insensitive, but if we change the plugin name for CouchDB we should
 probably also change it for MongoDB. There's a reason I did that, I just
 can't remember what it was...

 I don't see any compelling reason to rename the package. The package
 name for MongoDB is mongo. I don't like combining multiple words into a
 single package name segment, because we can't camel case them (bad practice
 to have cap letters in package names). Show me another NoSQL database with
 the word couch in it and I'll reconsider. :-)


 couchbase maybe?



 N

 On Feb 7, 2014, at 9:12 AM, Christian Grobmeier wrote:

  also the packagename is just couch, but it should better be couchdb.
 The name couch is misleading imho

 On 7 Feb 2014, at 16:11, Christian Grobmeier wrote:

  Hi

 one minor thing in ClouchDBProvider:

 * The Apache CouchDB implementation of {@link NoSQLProvider}.
 */
 @Plugin(name = CouchDb, category = Core, printObject = true)
 public final class CouchDBProvider

 The name of this plugin is CouchDb while the correct name of the
 product
 is CouchDB: couchdb.apache.org
 Also our class and the comments do use the correct name. Just the
 plugin
 name is lower case.

 Any objections if I would change the plugin name to CouchDB instead of
 CouchDb?

 Cheers



 ---
 http://www.grobmeier.de
 The Zen Programmer: http://bit.ly/12lC6DL
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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



 ---
 http://www.grobmeier.de
 The Zen Programmer: http://bit.ly/12lC6DL
 @grobmeier
 GPG: 0xA5CC90DB

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

Re: CouchDb vs CouchDB

[Scott Deboy]

I would appreciate if there wasn't even a threat of veto.

I would like to see folks ask questions and talk about concerns, and then
only mention a veto when there is no other recourse.
On Feb 7, 2014 8:14 AM, Nick Williams nicho...@nicholaswilliams.net
wrote:

 Yep. I would've accompanied any veto with technical justification. Since I
 can't come up with a technical justification for renaming it to couchbase,
 I won't veto it. :-)

 N

 On Feb 7, 2014, at 10:09 AM, Scott Deboy wrote:

 I do want to remind everyone that vetoes are only valid if they are backed
 by a technical justification.

 Scott
 On Feb 7, 2014 8:07 AM, Nick Williams nicho...@nicholaswilliams.net
 wrote:

 I'm not convinced it really makes a difference, but it's better than
 couchdb, so if the majority wants couchbase it I won't veto it. Be sure to
 change the test package name, too.

 Nick

 On Feb 7, 2014, at 10:03 AM, Scott Deboy wrote:

 +1 to couchbase
 On Feb 7, 2014 7:54 AM, Christian Grobmeier grobme...@gmail.com
 wrote:

 On 7 Feb 2014, at 16:19, Nick Williams wrote:

  It doesn't so much matter because the XML element names are case
 insensitive, but if we change the plugin name for CouchDB we should
 probably also change it for MongoDB. There's a reason I did that, I just
 can't remember what it was...

 I don't see any compelling reason to rename the package. The package
 name for MongoDB is mongo. I don't like combining multiple words into a
 single package name segment, because we can't camel case them (bad practice
 to have cap letters in package names). Show me another NoSQL database with
 the word couch in it and I'll reconsider. :-)


 couchbase maybe?



 N

 On Feb 7, 2014, at 9:12 AM, Christian Grobmeier wrote:

  also the packagename is just couch, but it should better be
 couchdb.
 The name couch is misleading imho

 On 7 Feb 2014, at 16:11, Christian Grobmeier wrote:

  Hi

 one minor thing in ClouchDBProvider:

 * The Apache CouchDB implementation of {@link NoSQLProvider}.
 */
 @Plugin(name = CouchDb, category = Core, printObject = true)
 public final class CouchDBProvider

 The name of this plugin is CouchDb while the correct name of the
 product
 is CouchDB: couchdb.apache.org
 Also our class and the comments do use the correct name. Just the
 plugin
 name is lower case.

 Any objections if I would change the plugin name to CouchDB instead
 of CouchDb?

 Cheers



 ---
 http://www.grobmeier.de
 The Zen Programmer: http://bit.ly/12lC6DL
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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



 ---
 http://www.grobmeier.de
 The Zen Programmer: http://bit.ly/12lC6DL
 @grobmeier
 GPG: 0xA5CC90DB

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

Re: CouchDb vs CouchDB

[Scott Deboy]

+1 to couchbase
On Feb 7, 2014 7:54 AM, Christian Grobmeier grobme...@gmail.com wrote:

 On 7 Feb 2014, at 16:19, Nick Williams wrote:

  It doesn't so much matter because the XML element names are case
 insensitive, but if we change the plugin name for CouchDB we should
 probably also change it for MongoDB. There's a reason I did that, I just
 can't remember what it was...

 I don't see any compelling reason to rename the package. The package name
 for MongoDB is mongo. I don't like combining multiple words into a single
 package name segment, because we can't camel case them (bad practice to
 have cap letters in package names). Show me another NoSQL database with the
 word couch in it and I'll reconsider. :-)


 couchbase maybe?



 N

 On Feb 7, 2014, at 9:12 AM, Christian Grobmeier wrote:

  also the packagename is just couch, but it should better be couchdb.
 The name couch is misleading imho

 On 7 Feb 2014, at 16:11, Christian Grobmeier wrote:

  Hi

 one minor thing in ClouchDBProvider:

 * The Apache CouchDB implementation of {@link NoSQLProvider}.
 */
 @Plugin(name = CouchDb, category = Core, printObject = true)
 public final class CouchDBProvider

 The name of this plugin is CouchDb while the correct name of the
 product
 is CouchDB: couchdb.apache.org
 Also our class and the comments do use the correct name. Just the plugin
 name is lower case.

 Any objections if I would change the plugin name to CouchDB instead of
 CouchDb?

 Cheers



 ---
 http://www.grobmeier.de
 The Zen Programmer: http://bit.ly/12lC6DL
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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



 ---
 http://www.grobmeier.de
 The Zen Programmer: http://bit.ly/12lC6DL
 @grobmeier
 GPG: 0xA5CC90DB

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

Re: Logger setLevel?

[Scott Deboy]

Add setlevel. I also think appender belongs in Api. Yes?
On Jan 31, 2014 10:01 AM, Gary Gregory garydgreg...@gmail.com wrote:

 Porting from v1...

 We do not have Logger setLevel(Level) because it is not in the LCD API
 (Slf4j no, Logback yes, JUL yes).

 This sure makes it a pain to port from v1.

 What are the choices?

 - I hard code everything to the Core Logger API, possible if inflexible.
 - I add a util method that checks the Logger instance to see if it is a
 Core Logger or if it is a Slf4j logger that wraps a logback logger? Bleh.

 Or, we can add setLevel and have it propagate the call down. Then we can
 discuss whether a missing API in the underlying system means a noop or an
 exception. Like JRE Collections do.

 Thoughts?

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: Logger setLevel?

[Scott Deboy]

Re: appenders, I was thinking about Remko's response here:

http://stackoverflow.com/questions/21303746/migrating-from-log4j-1-2-to-log4j-2-how-to-get-list-of-all-appenders-and-rolli


On 1/31/14, Gary Gregory garydgreg...@gmail.com wrote:
 On Fri, Jan 31, 2014 at 1:05 PM, Scott Deboy scott.de...@gmail.com wrote:

 Add setlevel. I also think appender belongs in Api. Yes?


 Appenders are in the Core. That would be a big change.

 Another surprise: There is no Logger.getLevel().

 Gary


 On Jan 31, 2014 10:01 AM, Gary Gregory garydgreg...@gmail.com wrote:

 Porting from v1...

 We do not have Logger setLevel(Level) because it is not in the LCD API
 (Slf4j no, Logback yes, JUL yes).

 This sure makes it a pain to port from v1.

 What are the choices?

 - I hard code everything to the Core Logger API, possible if inflexible.
 - I add a util method that checks the Logger instance to see if it is a
 Core Logger or if it is a Slf4j logger that wraps a logback logger?
 Bleh.

 Or, we can add setLevel and have it propagate the call down. Then we can
 discuss whether a missing API in the underlying system means a noop or
 an
 exception. Like JRE Collections do.

 Thoughts?

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: Enums and Custom Levels - completed.

[Scott Deboy]

So I assume we could build on this by adding the ability to generate these
custom levels from the config, with no user provided class required?


On Jan 26, 2014 12:58 AM, Ralph Goers ralph.go...@dslextreme.com wrote:

 I have completed the work on custom levels.  It uses a variation of
Nick’s “extensible enum” class.  The major difference with what he proposed
is that the custom enums must be declared in a class annotated with
@Plugin(name=“” category=“Level”) for them to be usable during
configuration.

 Are their any objections to me checking this in?  I’ll be doing the
commit at around noon Pacific Daylight Time if I don’t hear any.

 Ralph



 On Jan 25, 2014, at 7:08 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:

 I am working on the implementation of custom levels now.  I should have
it done today.

 Ralph

 On Jan 24, 2014, at 7:07 PM, Remko Popma remko.po...@gmail.com wrote:

 What is the best way to make progress on the custom levels
implementation?

 Do we re-open LOG4J-41 or start a fresh Jira ticket? For implementation
ideas, do we attach files to Jira, or create a branch?

 Remko

 On Saturday, January 25, 2014, Gary Gregory garydgreg...@gmail.com
wrote:

 On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma remko.po...@gmail.com
wrote:

 Gary,

 The hard-coded levels were proposed because it seemed that the
extensible enum idea raised by Nick was not going to be accepted.
 My original position was that Markers could fulfill the requirement
but Nick and yourself made it clear that this was not satisfactory.

 With extensible enums and markers off the table it seemed that the
hard-coded levels was the only alternative, and discussion ensued about
what these levels should be called and what strength they should have.

 During this discussion, several people, including me, repeatedly
expressed strong reservations about adding pre-defined levels, but by this
time I think people were thinking there was no alternative.

 It looked like we were getting stuck, with half the group moving in
one direction (add pre-defined levels!) and the other half wanting to
move in another direction (don't add pre-defined levels!). I asked that
we re-reviewed our assumptions and try to reach a solution that would
satisfy all users.

 We then decided to explore the option of using extensible enums
again. This is still ongoing, but I haven't seen anyone arguing against
this idea since we started this thread.

 Hard-coded levels and the extensible enum are different solutions to
the same problem.


 Hello All:

 Absolutely not. See my DEFCON example.
 Talking about an extensible enum is mixing design and
implementation, we are talking about 'custom' and/or 'extensible' levels.
 Custom/Extensible levels can be designed to serve one or all of:

 - Allow inserting custom levels between built-in levels.
 - Allow for domain specific levels outside of the concept of built-in
levels, the DEFCON example.
 - Should the custom levels themselves be extensible?

 Gary


 The extensible enum solution satisfies all of us who are opposed to
adding pre-defined levels, while also satisfying the original requirement
raised by Nick and yourself. Frankly I don't understand why you would still
want the pre-defined levels.

 Remko



 On Sat, Jan 25, 2014 at 12:53 AM, Gary Gregory garydgreg...@gmail.com
wrote:

 On Thu, Jan 23, 2014 at 10:45 PM, Remko Popma remko.po...@gmail.com
wrote:

 Gary,

 I think that's a very cool idea!
 Much more flexible, powerful and elegant than pre-defined levels
could ever be.


 As I wrote: I am discussing custom levels here with the
understanding that this is a separate topic from what the built-in levels
are.

 I'm not sure why you want to make the features mutually exclusive.
(Some) others agree that these are different features.

 I see two topics:

 - What are the default levels for a 21st century logging framework.
Do we simply blindly copy Log4j 1? Or do we look at frameworks from
different languages and platforms for inspiration?
 - How (not if, I think we all agree) should we allow for custom
levels.

 Gary

 It definitely makes sense to design the extensible enum with this
potential usage in mind.

 Remko


 On Friday, January 24, 2014, Gary Gregory garydgreg...@gmail.com
wrote:

 I am discussing custom levels here with the understanding that
this is a separate topic from what the built-in levels are. Here is how I
convinced myself that custom levels are a “good thing”.

 No matter which built-in levels exits, I may want custom levels.
For example, I want my app to use the following levels DEFCON1, DEFCON2,
DEFCON3, DEFCON4, and DEFCON5. This might be for one part of my app or a
whole subsystem, no matter, I want to use the built-in levels in addition
to the DEFCON levels. It is worth mentioning that if I want that feature
only as a user, I can “skin” levels in a layout and assign any label to the
built-in levels. If I am also a developer, I want to use DEFCON levels in
the source code.


 At 

Re: Enums and Custom Levels - completed.

[Scott Deboy]

Are these serialization-wise going to be the same as standard levels?

Receivers and apps like Chainsaw would benefit from not requiring the
originating level class be included in the classpath.

I'm thinking about socketreceiver and to a lesser extent
logfilepatternreceiver.

Scott
 On Jan 26, 2014 7:28 AM, Scott Deboy scott.de...@gmail.com wrote:

 So I assume we could build on this by adding the ability to generate these
 custom levels from the config, with no user provided class required?


 On Jan 26, 2014 12:58 AM, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 
  I have completed the work on custom levels.  It uses a variation of
 Nick's extensible enum class.  The major difference with what he proposed
 is that the custom enums must be declared in a class annotated with
 @Plugin(name= category=Level) for them to be usable during
 configuration.
 
  Are their any objections to me checking this in?  I'll be doing the
 commit at around noon Pacific Daylight Time if I don't hear any.
 
  Ralph
 
 
 
  On Jan 25, 2014, at 7:08 AM, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 
  I am working on the implementation of custom levels now.  I should have
 it done today.
 
  Ralph
 
  On Jan 24, 2014, at 7:07 PM, Remko Popma remko.po...@gmail.com wrote:
 
  What is the best way to make progress on the custom levels
 implementation?
 
  Do we re-open LOG4J-41 or start a fresh Jira ticket? For
 implementation ideas, do we attach files to Jira, or create a branch?
 
  Remko
 
  On Saturday, January 25, 2014, Gary Gregory garydgreg...@gmail.com
 wrote:
 
  On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma remko.po...@gmail.com
 wrote:
 
  Gary,
 
  The hard-coded levels were proposed because it seemed that the
 extensible enum idea raised by Nick was not going to be accepted.
  My original position was that Markers could fulfill the requirement
 but Nick and yourself made it clear that this was not satisfactory.
 
  With extensible enums and markers off the table it seemed that the
 hard-coded levels was the only alternative, and discussion ensued about
 what these levels should be called and what strength they should have.
 
  During this discussion, several people, including me, repeatedly
 expressed strong reservations about adding pre-defined levels, but by this
 time I think people were thinking there was no alternative.
 
  It looked like we were getting stuck, with half the group moving in
 one direction (add pre-defined levels!) and the other half wanting to
 move in another direction (don't add pre-defined levels!). I asked that
 we re-reviewed our assumptions and try to reach a solution that would
 satisfy all users.
 
  We then decided to explore the option of using extensible enums
 again. This is still ongoing, but I haven't seen anyone arguing against
 this idea since we started this thread.
 
  Hard-coded levels and the extensible enum are different solutions to
 the same problem.
 
 
  Hello All:
 
  Absolutely not. See my DEFCON example.
  Talking about an extensible enum is mixing design and
 implementation, we are talking about 'custom' and/or 'extensible' levels.
  Custom/Extensible levels can be designed to serve one or all of:
 
  - Allow inserting custom levels between built-in levels.
  - Allow for domain specific levels outside of the concept of built-in
 levels, the DEFCON example.
  - Should the custom levels themselves be extensible?
 
  Gary
 
 
  The extensible enum solution satisfies all of us who are opposed to
 adding pre-defined levels, while also satisfying the original requirement
 raised by Nick and yourself. Frankly I don't understand why you would still
 want the pre-defined levels.
 
  Remko
 
 
 
  On Sat, Jan 25, 2014 at 12:53 AM, Gary Gregory 
 garydgreg...@gmail.com wrote:
 
  On Thu, Jan 23, 2014 at 10:45 PM, Remko Popma 
 remko.po...@gmail.com wrote:
 
  Gary,
 
  I think that's a very cool idea!
  Much more flexible, powerful and elegant than pre-defined levels
 could ever be.
 
 
  As I wrote: I am discussing custom levels here with the
 understanding that this is a separate topic from what the built-in levels
 are.
 
  I'm not sure why you want to make the features mutually exclusive.
 (Some) others agree that these are different features.
 
  I see two topics:
 
  - What are the default levels for a 21st century logging framework.
 Do we simply blindly copy Log4j 1? Or do we look at frameworks from
 different languages and platforms for inspiration?
  - How (not if, I think we all agree) should we allow for custom
 levels.
 
  Gary
 
  It definitely makes sense to design the extensible enum with this
 potential usage in mind.
 
  Remko
 
 
  On Friday, January 24, 2014, Gary Gregory garydgreg...@gmail.com
 wrote:
 
  I am discussing custom levels here with the understanding that
 this is a separate topic from what the built-in levels are. Here is how I
 convinced myself that custom levels are a good thing.
 
  No matter which built-in levels exits, I may want

Re: Enums and Custom Levels - completed.

[Scott Deboy]

Is there a way to generate code/update the Levels enumeration so a new
Level class isn't required?

Would be great to be able to use logger.detail(Detail message);

Is that what you're thinking of, Remko?

On 1/26/14, Ralph Goers ralph.go...@dslextreme.com wrote:
 I haven’t done anything to directly do that. However, custom levels need to
 be mapped to the standard levels in several places. It would be simple to
 add support for that wherever you want it.  Level.StdLevel.getStdLevel() is
 the method used to do that.

 Ralph

 On Jan 26, 2014, at 7:45 AM, Scott Deboy scott.de...@gmail.com wrote:

 Are these serialization-wise going to be the same as standard levels?

 Receivers and apps like Chainsaw would benefit from not requiring the
 originating level class be included in the classpath.

 I'm thinking about socketreceiver and to a lesser extent
 logfilepatternreceiver.

 Scott
 On Jan 26, 2014 7:28 AM, Scott Deboy scott.de...@gmail.com wrote:
 So I assume we could build on this by adding the ability to generate these
 custom levels from the config, with no user provided class required?



 On Jan 26, 2014 12:58 AM, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 
  I have completed the work on custom levels.  It uses a variation of
  Nick’s “extensible enum” class.  The major difference with what he
  proposed is that the custom enums must be declared in a class annotated
  with @Plugin(name=“” category=“Level”) for them to be usable during
  configuration.
 
  Are their any objections to me checking this in?  I’ll be doing the
  commit at around noon Pacific Daylight Time if I don’t hear any.
 
  Ralph
 
 
 
  On Jan 25, 2014, at 7:08 AM, Ralph Goers ralph.go...@dslextreme.com
  wrote:
 
  I am working on the implementation of custom levels now.  I should have
  it done today.
 
  Ralph
 
  On Jan 24, 2014, at 7:07 PM, Remko Popma remko.po...@gmail.com
  wrote:
 
  What is the best way to make progress on the custom levels
  implementation?
 
  Do we re-open LOG4J-41 or start a fresh Jira ticket? For
  implementation ideas, do we attach files to Jira, or create a branch?
 
  Remko
 
  On Saturday, January 25, 2014, Gary Gregory garydgreg...@gmail.com
  wrote:
 
  On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma remko.po...@gmail.com
  wrote:
 
  Gary,
 
  The hard-coded levels were proposed because it seemed that the
  extensible enum idea raised by Nick was not going to be accepted.
  My original position was that Markers could fulfill the requirement
  but Nick and yourself made it clear that this was not satisfactory.
 
  With extensible enums and markers off the table it seemed that the
  hard-coded levels was the only alternative, and discussion ensued
  about what these levels should be called and what strength they
  should have.
 
  During this discussion, several people, including me, repeatedly
  expressed strong reservations about adding pre-defined levels, but
  by this time I think people were thinking there was no alternative.
 
  It looked like we were getting stuck, with half the group moving in
  one direction (add pre-defined levels!) and the other half wanting
  to move in another direction (don't add pre-defined levels!). I
  asked that we re-reviewed our assumptions and try to reach a
  solution that would satisfy all users.
 
  We then decided to explore the option of using extensible enums
  again. This is still ongoing, but I haven't seen anyone arguing
  against this idea since we started this thread.
 
  Hard-coded levels and the extensible enum are different solutions to
  the same problem.
 
 
  Hello All:
 
  Absolutely not. See my DEFCON example.
  Talking about an extensible enum is mixing design and
  implementation, we are talking about 'custom' and/or 'extensible'
  levels.
  Custom/Extensible levels can be designed to serve one or all of:
 
  - Allow inserting custom levels between built-in levels.
  - Allow for domain specific levels outside of the concept of built-in
  levels, the DEFCON example.
  - Should the custom levels themselves be extensible?
 
  Gary
 
 
  The extensible enum solution satisfies all of us who are opposed to
  adding pre-defined levels, while also satisfying the original
  requirement raised by Nick and yourself. Frankly I don't understand
  why you would still want the pre-defined levels.
 
  Remko
 
 
 
  On Sat, Jan 25, 2014 at 12:53 AM, Gary Gregory
  garydgreg...@gmail.com wrote:
 
  On Thu, Jan 23, 2014 at 10:45 PM, Remko Popma
  remko.po...@gmail.com wrote:
 
  Gary,
 
  I think that's a very cool idea!
  Much more flexible, powerful and elegant than pre-defined levels
  could ever be.
 
 
  As I wrote: I am discussing custom levels here with the
  understanding that this is a separate topic from what the built-in
  levels are.
 
  I'm not sure why you want to make the features mutually exclusive.
  (Some) others agree that these are different features.
 
  I see two topics:
 
  - What are the default levels for a 21st century

Re: Enums and Custom Levels - completed.

[Scott Deboy]

Yes that's what I was thinking.

Scott
On Jan 26, 2014 3:18 PM, Remko Popma remko.po...@gmail.com wrote:

 Scott,
 The way I interpreted Gary's idea was that based on user-specified custom
 levels, we would generate an extension of the Logger interface that has a
 method for each of the custom levels (well, actually 14 methods for each
 level :-) ).
 I haven't really thought about how users would specify their custom
 levels, as long as the tool can know what methods to generate.

 We could go one step further and generate the Level subclass from
 configuration as well. I suppose that would entail adding a new Levels
 element, with sub-elements like Level name=DETAIL intLevel=450 /...
 Is that what you are thinking of?

 I would be fine with that too, but would like to first focus on generating
 the extended Logger interface.



 On Mon, Jan 27, 2014 at 5:29 AM, Scott Deboy scott.de...@gmail.comwrote:

 Is there a way to generate code/update the Levels enumeration so a new
 Level class isn't required?

 Would be great to be able to use logger.detail(Detail message);

 Is that what you're thinking of, Remko?

 On 1/26/14, Ralph Goers ralph.go...@dslextreme.com wrote:
  I haven't done anything to directly do that. However, custom levels
 need to
  be mapped to the standard levels in several places. It would be simple
 to
  add support for that wherever you want it.
  Level.StdLevel.getStdLevel() is
  the method used to do that.
 
  Ralph
 
  On Jan 26, 2014, at 7:45 AM, Scott Deboy scott.de...@gmail.com wrote:
 
  Are these serialization-wise going to be the same as standard levels?
 
  Receivers and apps like Chainsaw would benefit from not requiring the
  originating level class be included in the classpath.
 
  I'm thinking about socketreceiver and to a lesser extent
  logfilepatternreceiver.
 
  Scott
  On Jan 26, 2014 7:28 AM, Scott Deboy scott.de...@gmail.com wrote:
  So I assume we could build on this by adding the ability to generate
 these
  custom levels from the config, with no user provided class required?
 
 
 
  On Jan 26, 2014 12:58 AM, Ralph Goers ralph.go...@dslextreme.com
  wrote:
  
   I have completed the work on custom levels.  It uses a variation of
   Nick's extensible enum class.  The major difference with what he
   proposed is that the custom enums must be declared in a class
 annotated
   with @Plugin(name= category=Level) for them to be usable
 during
   configuration.
  
   Are their any objections to me checking this in?  I'll be doing the
   commit at around noon Pacific Daylight Time if I don't hear any.
  
   Ralph
  
  
  
   On Jan 25, 2014, at 7:08 AM, Ralph Goers ralph.go...@dslextreme.com
 
   wrote:
  
   I am working on the implementation of custom levels now.  I should
 have
   it done today.
  
   Ralph
  
   On Jan 24, 2014, at 7:07 PM, Remko Popma remko.po...@gmail.com
   wrote:
  
   What is the best way to make progress on the custom levels
   implementation?
  
   Do we re-open LOG4J-41 or start a fresh Jira ticket? For
   implementation ideas, do we attach files to Jira, or create a
 branch?
  
   Remko
  
   On Saturday, January 25, 2014, Gary Gregory 
 garydgreg...@gmail.com
   wrote:
  
   On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma 
 remko.po...@gmail.com
   wrote:
  
   Gary,
  
   The hard-coded levels were proposed because it seemed that the
   extensible enum idea raised by Nick was not going to be accepted.
   My original position was that Markers could fulfill the
 requirement
   but Nick and yourself made it clear that this was not
 satisfactory.
  
   With extensible enums and markers off the table it seemed that
 the
   hard-coded levels was the only alternative, and discussion ensued
   about what these levels should be called and what strength they
   should have.
  
   During this discussion, several people, including me, repeatedly
   expressed strong reservations about adding pre-defined levels,
 but
   by this time I think people were thinking there was no
 alternative.
  
   It looked like we were getting stuck, with half the group moving
 in
   one direction (add pre-defined levels!) and the other half
 wanting
   to move in another direction (don't add pre-defined levels!). I
   asked that we re-reviewed our assumptions and try to reach a
   solution that would satisfy all users.
  
   We then decided to explore the option of using extensible enums
   again. This is still ongoing, but I haven't seen anyone arguing
   against this idea since we started this thread.
  
   Hard-coded levels and the extensible enum are different
 solutions to
   the same problem.
  
  
   Hello All:
  
   Absolutely not. See my DEFCON example.
   Talking about an extensible enum is mixing design and
   implementation, we are talking about 'custom' and/or 'extensible'
   levels.
   Custom/Extensible levels can be designed to serve one or all of:
  
   - Allow inserting custom levels between built-in levels.
   - Allow for domain specific levels outside

Re: Enums and Custom Levels - completed.

[Scott Deboy]

I have one goal: to remove my request for new built in levels by allowing
the levels to be defined strictly via configuration. I agree there may be
some hurdles but that's my goal.

I'd like to avoid the requirement that users provide their own level
implementation or use a different API.

Scott
 On Jan 26, 2014 3:52 PM, Nick Williams nicho...@nicholaswilliams.net
wrote:

 Generating a logger /interface/ is going to be hard. Sure, writing the
 code automatically will be a piece of cake. But then what do we do with
 that code? The user needs to program against it. So we have to have a
 command-line utility or Maven/Ant plug-in to generate the source
 pre-compile. However, since the vast majority of users are using IDEs,
 those IDEs will still warn them about the interface not existing until they
 have run the utility to generate the source.

 I think a better approach would be to allow the user to define an
 interface that /must/ extend Logger. That interface may contain any methods
 that match the following signatures (the interface must have at least one
 method and there is no limit to the number of methods it may have):

 void(Marker, Message)
 void(Marker, Message, Throwable t)
 void(Marker, Object)
 void(Marker, Object, Throwable t)
 void(Marker, String)
 void(Marker, String, Object...)
 void(Marker, String throwable)
 void(Message)
 void(Message, Throwable t)
 void(Object)
 void(Object, Throwable t)
 void(String)
 void(String, Object...)
 void(String throwable)

 Each method /must/ be annotated with @LoggingLevel(name = levelName).
 Now LogManager has a few new methods:

 T extends Logger T getCustomLogger(ClassT loggerClass)
 T extends Logger T getCustomLogger(ClassT loggerClass, Class?)
 T extends Logger T getCustomLogger(ClassT loggerClass, Class?,
 MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass, MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass, Object)
 T extends Logger T getCustomLogger(ClassT loggerClass, Object,
 MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass, String)
 T extends Logger T getCustomLogger(ClassT loggerClass, String,
 MessageFactory)

 The user can then obtain such a logger like so, etc.:

 MyLogger logger = LogManager.getCustomLogger(MyLogger.class);

 Log4j will generate an implementation of MyLogger that extends the default
 implementation, cache that implementation so that it doesn't have to be
 implemented again, and then instantiate/cache the logger instance like
 normal.

 Make sense?

 N

 On Jan 26, 2014, at 5:32 PM, Scott Deboy wrote:

 Yes that's what I was thinking.

 Scott
 On Jan 26, 2014 3:18 PM, Remko Popma remko.po...@gmail.com wrote:

 Scott,
 The way I interpreted Gary's idea was that based on user-specified custom
 levels, we would generate an extension of the Logger interface that has a
 method for each of the custom levels (well, actually 14 methods for each
 level :-) ).
 I haven't really thought about how users would specify their custom
 levels, as long as the tool can know what methods to generate.

 We could go one step further and generate the Level subclass from
 configuration as well. I suppose that would entail adding a new Levels
 element, with sub-elements like Level name=DETAIL intLevel=450 /...
 Is that what you are thinking of?

 I would be fine with that too, but would like to first focus on
 generating the extended Logger interface.



 On Mon, Jan 27, 2014 at 5:29 AM, Scott Deboy scott.de...@gmail.comwrote:

 Is there a way to generate code/update the Levels enumeration so a new
 Level class isn't required?

 Would be great to be able to use logger.detail(Detail message);

 Is that what you're thinking of, Remko?

 On 1/26/14, Ralph Goers ralph.go...@dslextreme.com wrote:
  I haven’t done anything to directly do that. However, custom levels
 need to
  be mapped to the standard levels in several places. It would be simple
 to
  add support for that wherever you want it.
  Level.StdLevel.getStdLevel() is
  the method used to do that.
 
  Ralph
 
  On Jan 26, 2014, at 7:45 AM, Scott Deboy scott.de...@gmail.com
 wrote:
 
  Are these serialization-wise going to be the same as standard levels?
 
  Receivers and apps like Chainsaw would benefit from not requiring the
  originating level class be included in the classpath.
 
  I'm thinking about socketreceiver and to a lesser extent
  logfilepatternreceiver.
 
  Scott
  On Jan 26, 2014 7:28 AM, Scott Deboy scott.de...@gmail.com wrote:
  So I assume we could build on this by adding the ability to generate
 these
  custom levels from the config, with no user provided class required?
 
 
 
  On Jan 26, 2014 12:58 AM, Ralph Goers ralph.go...@dslextreme.com
  wrote:
  
   I have completed the work on custom levels.  It uses a variation of
   Nick’s “extensible enum” class.  The major difference with what he
   proposed is that the custom enums must be declared in a class
 annotated
   with @Plugin(name=“” category=“Level

Re: Enums and Custom Levels - completed.

[Scott Deboy]

Couldn't we no-op instead of throw if the same identical level were
registered?

If those levels were then added to the same custom level class from the
config, could we use that single class in the logger calls?
 On Jan 26, 2014 5:15 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 I am certain I could create a LevelPlugin that would allow you to define
 one or more Levels in the configuration, but to use that Level the user
 would have to code:

 logger.log(Level.toLevel(DIAG), hello world);

 In order to directly reference the level it has to be declared as a static
 from somewhere and it can only be instantiated a single time, so creating
 it from the configuration will prevent that.

 Ralph

 On Jan 26, 2014, at 4:03 PM, Scott Deboy scott.de...@gmail.com wrote:

 I have one goal: to remove my request for new built in levels by allowing
 the levels to be defined strictly via configuration. I agree there may be
 some hurdles but that's my goal.

 I'd like to avoid the requirement that users provide their own level
 implementation or use a different API.

 Scott
  On Jan 26, 2014 3:52 PM, Nick Williams nicho...@nicholaswilliams.net
 wrote:

 Generating a logger /interface/ is going to be hard. Sure, writing the
 code automatically will be a piece of cake. But then what do we do with
 that code? The user needs to program against it. So we have to have a
 command-line utility or Maven/Ant plug-in to generate the source
 pre-compile. However, since the vast majority of users are using IDEs,
 those IDEs will still warn them about the interface not existing until they
 have run the utility to generate the source.

 I think a better approach would be to allow the user to define an
 interface that /must/ extend Logger. That interface may contain any methods
 that match the following signatures (the interface must have at least one
 method and there is no limit to the number of methods it may have):

 void(Marker, Message)
 void(Marker, Message, Throwable t)
 void(Marker, Object)
 void(Marker, Object, Throwable t)
 void(Marker, String)
 void(Marker, String, Object...)
 void(Marker, String throwable)
 void(Message)
 void(Message, Throwable t)
 void(Object)
 void(Object, Throwable t)
 void(String)
 void(String, Object...)
 void(String throwable)

 Each method /must/ be annotated with @LoggingLevel(name = levelName).
 Now LogManager has a few new methods:

 T extends Logger T getCustomLogger(ClassT loggerClass)
 T extends Logger T getCustomLogger(ClassT loggerClass, Class?)
 T extends Logger T getCustomLogger(ClassT loggerClass, Class?,
 MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass, MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass, Object)
 T extends Logger T getCustomLogger(ClassT loggerClass, Object,
 MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass, String)
 T extends Logger T getCustomLogger(ClassT loggerClass, String,
 MessageFactory)

 The user can then obtain such a logger like so, etc.:

 MyLogger logger = LogManager.getCustomLogger(MyLogger.class);

 Log4j will generate an implementation of MyLogger that extends the
 default implementation, cache that implementation so that it doesn't have
 to be implemented again, and then instantiate/cache the logger instance
 like normal.

 Make sense?

 N

 On Jan 26, 2014, at 5:32 PM, Scott Deboy wrote:

 Yes that's what I was thinking.

 Scott
 On Jan 26, 2014 3:18 PM, Remko Popma remko.po...@gmail.com wrote:

 Scott,
 The way I interpreted Gary's idea was that based on user-specified
 custom levels, we would generate an extension of the Logger interface that
 has a method for each of the custom levels (well, actually 14 methods for
 each level :-) ).
 I haven't really thought about how users would specify their custom
 levels, as long as the tool can know what methods to generate.

 We could go one step further and generate the Level subclass from
 configuration as well. I suppose that would entail adding a new Levels
 element, with sub-elements like Level name=DETAIL intLevel=450 /...
 Is that what you are thinking of?

 I would be fine with that too, but would like to first focus on
 generating the extended Logger interface.



 On Mon, Jan 27, 2014 at 5:29 AM, Scott Deboy scott.de...@gmail.comwrote:

 Is there a way to generate code/update the Levels enumeration so a new
 Level class isn't required?

 Would be great to be able to use logger.detail(Detail message);

 Is that what you're thinking of, Remko?

 On 1/26/14, Ralph Goers ralph.go...@dslextreme.com wrote:
  I haven't done anything to directly do that. However, custom levels
 need to
  be mapped to the standard levels in several places. It would be
 simple to
  add support for that wherever you want it.
  Level.StdLevel.getStdLevel() is
  the method used to do that.
 
  Ralph
 
  On Jan 26, 2014, at 7:45 AM, Scott Deboy scott.de...@gmail.com
 wrote:
 
  Are these serialization-wise going to be the same as standard levels

Re: Using Custom Levels with a Custom/Wrapper Interface

[Scott Deboy]

If there is a way to support this strictly through configuration that would
be ideal.

I'm trying to find a way to remove my request for additional built in
levels but through configuration instead of adding them ourselves.

Scott
Scott
On Jan 26, 2014 7:38 PM, Nick Williams nicho...@nicholaswilliams.net
wrote:

 Here's a split-off thread for discussing how we can make using custom
 levels easier. Some on the team have expressed a desire to make it even
 easier. Given hypothetical custom levels DIAG and NOTE, the following would
 be nice to have:

 logger.note(message);
 logger.diag(message);
 etc.

 We're to discuss how best to approach this. My proposal (from previous
 email):

  Allow the user to define an interface that /must/ extend Logger. That
 interface may contain any methods that match the following signatures (the
 interface must have at least one method and there is no limit to the number
 of methods it may have):
 
  void [methodName](Marker, Message)
  void [methodName](Marker, Message, Throwable t)
  void [methodName](Marker, Object)
  void [methodName](Marker, Object, Throwable t)
  void [methodName](Marker, String)
  void [methodName](Marker, String, Object...)
  void [methodName](Marker, String throwable)
  void [methodName](Message)
  void [methodName](Message, Throwable t)
  void [methodName](Object)
  void [methodName](Object, Throwable t)
  void [methodName](String)
  void [methodName](String, Object...)
  void [methodName](String throwable)
 
  Each method /must/ be annotated with @LoggingLevel(name = levelName).
 Now LogManager has a few new methods:
 
  T extends Logger T getCustomLogger(ClassT loggerClass)
  T extends Logger T getCustomLogger(ClassT loggerClass, Class?)
  T extends Logger T getCustomLogger(ClassT loggerClass, Class?,
 MessageFactory)
  T extends Logger T getCustomLogger(ClassT loggerClass,
 MessageFactory)
  T extends Logger T getCustomLogger(ClassT loggerClass, Object)
  T extends Logger T getCustomLogger(ClassT loggerClass, Object,
 MessageFactory)
  T extends Logger T getCustomLogger(ClassT loggerClass, String)
  T extends Logger T getCustomLogger(ClassT loggerClass, String,
 MessageFactory)
 
  The user can then obtain such a logger like so, etc.:
 
  MyLogger logger = LogManager.getCustomLogger(MyLogger.class);
 
  Log4j will generate an implementation of MyLogger that extends the
 default implementation, cache that implementation so that it doesn't have
 to be implemented again, and then instantiate/cache the logger instance
 like normal.

 Others have suggested deriving the level name from the method name instead
 of using an annotation. That's a viable alternative.

 Matt Sicker asked:

  And can't getCustomLogger also provide a default method that uses the
 getClassName method?

 I think you misunderstand the purpose of the ClassT argument. It has
 nothing to do with the logger name--it's the class of the Logger interface
 to automatically implement.

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

Re: Using Custom Levels with a Custom/Wrapper Interface

[Scott Deboy]

Yes, I would like to declare in the config:

Level: NOTICE, value: 232

And in Java code be able to use logger.notice(some message).

But I think that'd require invokedynamic..which would probably
require..javassist/ASM?

I'd be ok with anything that's really close to that :)

Scott


On 1/26/14, Ralph Goers ralph.go...@dslextreme.com wrote:
 Scott would like users to add a level definition to the logging
 configuration and have everything else happen auto-magically.  That would
 happen at run-time which is a bit late since the methods need to be
 available at compile time.

 I believe Scott said he would be fine if users had to do

 logger.log(SomeClass.SomeLevel, message);

 but even that requires SomeClass to be available at compile time.

 So what Scott says he would like and what Nick is proposing are two
 different things.

 Ralph



 On Jan 26, 2014, at 8:09 PM, Remko Popma remko.po...@gmail.com wrote:

 I actually thought that Nick's idea was the answer to that: users create a
 custom interface, something like this:

 public interface MyLogger extends Logger {
 @LoggingLevel(name=DIAG)
 void diag(String message);
 // optional other methods
 }

 They get an instance of this interface by calling:
 LogManager.getCustomLogger(MyLogger.class);

 LogManager has access to the processed configuration. The config has
 LevelsLevel name=DIAG intValue=450 elements. During configuration
 processing, the custom Level instances are created and registered, so on
 the first call to LogManager.getCustomLogger(MyLogger.class), the MyLogger
 instance is created and cached. Also, at this point the annotations are
 parsed to see what Level instance the MyLogger implementation will pass to
 the Logger.log(Level, String) method when the diag method is called.

 What is still open in this scenario is how the instance is created. Proxy?
 Or generate source  compile? Or use a byte code library?

 On Monday, January 27, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 I am going to have to echo what Nick said.  If you can think of a way to
 make

 logger.log(SomeClass.SomeLevel, hello world);

 work without actually creating SomeClass then please share!

 Ralph

 On Jan 26, 2014, at 7:45 PM, Nick Williams nicho...@nicholaswilliams.net
 wrote:

 It would not be possible to do this strictly through configuration
 because the user needs a compiled interface to code against. Where is
 that compiled interface to come from?

 Nick

 On Jan 26, 2014, at 9:40 PM, Scott Deboy wrote:

 If there is a way to support this strictly through configuration that
 would be ideal.

 I'm trying to find a way to remove my request for additional built in
 levels but through configuration instead of adding them ourselves.

 Scott
 Scott

 On Jan 26, 2014 7:38 PM, Nick Williams nicho...@nicholaswilliams.net
 wrote:
 Here's a split-off thread for discussing how we can make using custom
 levels easier. Some on the team have expressed a desire to make it even
 easier. Given hypothetical custom levels DIAG and NOTE, the following
 would be nice to have:

 logger.note(message);
 logger.diag(message);
 etc.

 We're to discuss how best to approach this. My proposal (from previous
 email):

  Allow the user to define an interface that /must/ extend Logger. That
  interface may contain any methods that match the following signatures
  (the interface must have at least one method and there is no limit to
  the number of methods it may have):
 
  void [methodName](Marker, Message)
  void [methodName](Marker, Message, Throwable t)
  void [methodName](Marker, Object)
  void [methodName](Marker, Object, Throwable t)
  void [methodName](Marker, String)
  void [methodName](Marker, String, Object...)
  void [methodName](Marker, String throwable)
  void [methodName](Message)
  void [methodName](Message, Throwable t)
  void [methodName](Object)
  void [methodName](Object, Throwable t)
  void [methodName](String)
  void [methodName](String, Object...)
  void [methodName](String throwable)
 
  Each method /must/ be annotated with @LoggingLevel(name =
  levelName). Now LogManager has a few new methods:
 
  T extends Logger T getCustomLogger(ClassT loggerClass)
  T extends Logger T getCustomLogger(ClassT loggerClass, Class?)
  T extends Logger T getCustomLogger(ClassT loggerClass, Class?,
  MessageFactory)
  T extends Logger T getCustomLogger(ClassT loggerClass,
  MessageFactory)
  T extends Logger T getCustomLogger(ClassT loggerClass, Object)
  T extends Logger T getCustomLogger(ClassT loggerClass, Object,
  MessageFactory)
  T extends Logger T getCustomLogger(ClassT loggerClass, String)
  T extends Logger T getCustomLogger(ClassT loggerClass, String,
  MessageFactory)
 
  The user can then obtain such a logger like so, etc.:
 
  MyLogger logger = LogManager.getCustomLogger(MyLogger.class);
 
  Log4j will generate an implementation of MyLogger that extends the
  default implementation, cache that implementation so that it doesn't
  have to be implemented

Re: Levels added in revision 1560602

[Scott Deboy]

 consultants don't like the
 giant logs.

 Gary


 On Fri, Jan 24, 2014 at 3:56 PM, Christian Grobmeier 
 grobme...@gmail.com wrote:
 On 24 Jan 2014, at 21:47, Paul Benedict wrote:

 We should ensure that both the Javadocs and the user guide explain
 recommended usages for these. Mailing lists are for the most die-hard
 development fans. :-)

 +1

 Recommendations and documentation are/is absolutely necessary.

 I will happily go through the mailing list to look how you use the
 various log levels.
 But you also should know that I have read a ton of mails on this topic
 the past
 two days and I am still unsure how *you* use the log levels. I am still
 stuck with my own usage,
 and that is in my opinion the point why we can't reach an agreement
 easily.





 On Fri, Jan 24, 2014 at 2:38 PM, Gary Gregory garydgreg...@gmail.com
 wrote:

 There have been descriptions of what the levels are for... see Ralph '
 message, many of mine and others. I know it can be tedious to go back
 through various threads but the info is there. If you want more info,
 feel
 free to ask ;)

 Gary


  Original message 
 From: Christian Grobmeier
 Date:01/24/2014 14:20 (GMT-05:00)
 To: Log4J Developers List
 Subject: Re: Levels added in revision 1560602

 What I miss in this discussion are actually good examples of what the
 (new) log levels are intended for.

 In example, Gary mentioned he is on a wireshark level with  trace.
 That's fine, because it would give some idea when to use verbose (maybe
 entering method).

 Maybe I missed it when what I ask for was already written,
 but I believe if we can give concrete example how log levels should be
 used then we are a step further.

 I was asked quite a log what should be logged with which level.

 I think making the difference between trace and debug is already
 difficult for a lot of users.
 In the past two years i asked a lot of people how they log.

 The answer was: exceptions on error, the rest on debug.

 What we lack is a good recommendation how log levels should be used.
 Something which is on our front page and which lets the average Java
 programmer fully
 understand when he uses what, and maybe even why.

 If we have something like that it is much easier to argue pro/contra
 the new log levels.





 On 24 Jan 2014, at 18:36, Scott Deboy wrote:

 To be fair, I think we represent a reasonable fraction of the
 users..some won't touch new predefined levels, some will use it -
 that's the reason for adding it - we hit a significant portion of use
 cases with small additional number of built-in levels.

 The two solutions don't provide the same thing, do they?  If they do,
 I wouldn't be pressing the issue.

 If there is a way for us, via annotations or whatever mechanism we
 define for 'custom levels', to add support easily for the newly
 pre-defined levels, then we should do it.

 Specifically, I'm ok with any mechanism (even using the new custom
 level mechanism, but provide by log4j itself), where log4j users are
 able to call:

 logger.notice(something);

 Anything else and it won't meet my expectations for usability.

 By the way, while we're at it, let's remove fatal.

 Scott


 On 1/24/14, Remko Popma remko.po...@gmail.com wrote:
 I'm not questioning your experience, and I believe you when you say
 that
 the proposed levels would be a perfect match for your current work
 environment.

 However, out of the eight people that participated in the discussion
 on
 adding levels, four expressed strong reservations about adding
 pre-defined
 levels. We are all programmers on this list. So I think we can
 reasonable
 assume that a large fraction of users would also not like this
 change.

 On top of that, we have a more powerful and elegant alternative
 solution
 that makes adding pre-defined levels unnecessary.
 Sorry, but I veto the commit.




 On Sat, Jan 25, 2014 at 1:49 AM, Gary Gregory
 garydgreg...@gmail.comwrote:

 On Thu, Jan 23, 2014 at 10:18 PM, Ralph Goers
 ralph.go...@dslextreme.comwrote:

 Gary, although Remko hasn’t said it I think he is implying that
 he is
 vetoing the code commit. Unfortunately, unless you can convince
 Remko
 otherwise you are going to have to revert the commit.

 Remko, if that isn’t your intention then please say so as it will
 save
 Gary a bunch of work.


 Hello, hello,

 Wow, what a pickle of religious debate this has turned into!

 Before I do indeed do more work:





 Ralph

 On Jan 23, 2014, at 6:34 PM, Remko Popma remko.po...@gmail.com
 wrote:



 I wish you had a story of some kind to show why you are so strongly
 opposed to the new levels. I just wonder then why you are not
 arguing for
 fewer levels? Is 6 levels just the perfect number in your mind? If
 you
 designed a new logging system right now in a clean room approach,
 what
 would you devise?

 FWIW, I do consider Log4j2 a brand new system, granting us the
 freedom to
 break APIs with version 1, which we've obviously done, but not in a
 way
 that will make

Re: Using Custom Levels with a Custom/Wrapper Interface

[Scott Deboy]

Could we leverage Rhino? :)

Scott

On 1/26/14, Nicholas Williams nicho...@nicholaswilliams.net wrote:
 Scott, invokedynamic and javassist...those are all /runtime/ things. The
 user needs Logger#notice to be available at compile time. Those are not
 compatible.

 Nick

 Sent from my iPhone, so please forgive brief replies and frequent typos

 On Jan 26, 2014, at 22:37, Scott Deboy scott.de...@gmail.com wrote:

 Yes, I would like to declare in the config:

 Level: NOTICE, value: 232

 And in Java code be able to use logger.notice(some message).

 But I think that'd require invokedynamic..which would probably
 require..javassist/ASM?

 I'd be ok with anything that's really close to that :)

 Scott


 On 1/26/14, Ralph Goers ralph.go...@dslextreme.com wrote:
 Scott would like users to add a level definition to the logging
 configuration and have everything else happen auto-magically.  That
 would
 happen at run-time which is a bit late since the methods need to be
 available at compile time.

 I believe Scott said he would be fine if users had to do

 logger.log(SomeClass.SomeLevel, message);

 but even that requires SomeClass to be available at compile time.

 So what Scott says he would like and what Nick is proposing are two
 different things.

 Ralph



 On Jan 26, 2014, at 8:09 PM, Remko Popma remko.po...@gmail.com wrote:

 I actually thought that Nick's idea was the answer to that: users create
 a
 custom interface, something like this:

 public interface MyLogger extends Logger {
@LoggingLevel(name=DIAG)
void diag(String message);
// optional other methods
 }

 They get an instance of this interface by calling:
 LogManager.getCustomLogger(MyLogger.class);

 LogManager has access to the processed configuration. The config has
 LevelsLevel name=DIAG intValue=450 elements. During
 configuration
 processing, the custom Level instances are created and registered, so
 on
 the first call to LogManager.getCustomLogger(MyLogger.class), the
 MyLogger
 instance is created and cached. Also, at this point the annotations are
 parsed to see what Level instance the MyLogger implementation will pass
 to
 the Logger.log(Level, String) method when the diag method is called.

 What is still open in this scenario is how the instance is created.
 Proxy?
 Or generate source  compile? Or use a byte code library?

 On Monday, January 27, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 I am going to have to echo what Nick said.  If you can think of a way
 to
 make

 logger.log(SomeClass.SomeLevel, hello world);

 work without actually creating SomeClass then please share!

 Ralph

 On Jan 26, 2014, at 7:45 PM, Nick Williams
 nicho...@nicholaswilliams.net
 wrote:

 It would not be possible to do this strictly through configuration
 because the user needs a compiled interface to code against. Where is
 that compiled interface to come from?

 Nick

 On Jan 26, 2014, at 9:40 PM, Scott Deboy wrote:

 If there is a way to support this strictly through configuration that
 would be ideal.

 I'm trying to find a way to remove my request for additional built in
 levels but through configuration instead of adding them ourselves.

 Scott
 Scott

 On Jan 26, 2014 7:38 PM, Nick Williams
 nicho...@nicholaswilliams.net
 wrote:
 Here's a split-off thread for discussing how we can make using custom
 levels easier. Some on the team have expressed a desire to make it
 even
 easier. Given hypothetical custom levels DIAG and NOTE, the following
 would be nice to have:

 logger.note(message);
 logger.diag(message);
 etc.

 We're to discuss how best to approach this. My proposal (from
 previous
 email):

 Allow the user to define an interface that /must/ extend Logger.
 That
 interface may contain any methods that match the following
 signatures
 (the interface must have at least one method and there is no limit
 to
 the number of methods it may have):

 void [methodName](Marker, Message)
 void [methodName](Marker, Message, Throwable t)
 void [methodName](Marker, Object)
 void [methodName](Marker, Object, Throwable t)
 void [methodName](Marker, String)
 void [methodName](Marker, String, Object...)
 void [methodName](Marker, String throwable)
 void [methodName](Message)
 void [methodName](Message, Throwable t)
 void [methodName](Object)
 void [methodName](Object, Throwable t)
 void [methodName](String)
 void [methodName](String, Object...)
 void [methodName](String throwable)

 Each method /must/ be annotated with @LoggingLevel(name =
 levelName). Now LogManager has a few new methods:

 T extends Logger T getCustomLogger(ClassT loggerClass)
 T extends Logger T getCustomLogger(ClassT loggerClass, Class?)
 T extends Logger T getCustomLogger(ClassT loggerClass, Class?,
 MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass,
 MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass, Object)
 T extends Logger T getCustomLogger(ClassT loggerClass, Object,
 MessageFactory)
 T extends Logger T getCustomLogger

Re: Using Custom Levels with a Custom/Wrapper Interface

[Scott Deboy]

Of course, they'd have to use rhino, or something else...which doesn't
help.  Where's duck typing when you need it :)

On 1/26/14, Scott Deboy scott.de...@gmail.com wrote:
 Could we leverage Rhino? :)

 Scott

 On 1/26/14, Nicholas Williams nicho...@nicholaswilliams.net wrote:
 Scott, invokedynamic and javassist...those are all /runtime/ things. The
 user needs Logger#notice to be available at compile time. Those are not
 compatible.

 Nick

 Sent from my iPhone, so please forgive brief replies and frequent typos

 On Jan 26, 2014, at 22:37, Scott Deboy scott.de...@gmail.com wrote:

 Yes, I would like to declare in the config:

 Level: NOTICE, value: 232

 And in Java code be able to use logger.notice(some message).

 But I think that'd require invokedynamic..which would probably
 require..javassist/ASM?

 I'd be ok with anything that's really close to that :)

 Scott


 On 1/26/14, Ralph Goers ralph.go...@dslextreme.com wrote:
 Scott would like users to add a level definition to the logging
 configuration and have everything else happen auto-magically.  That
 would
 happen at run-time which is a bit late since the methods need to be
 available at compile time.

 I believe Scott said he would be fine if users had to do

 logger.log(SomeClass.SomeLevel, message);

 but even that requires SomeClass to be available at compile time.

 So what Scott says he would like and what Nick is proposing are two
 different things.

 Ralph



 On Jan 26, 2014, at 8:09 PM, Remko Popma remko.po...@gmail.com
 wrote:

 I actually thought that Nick's idea was the answer to that: users
 create
 a
 custom interface, something like this:

 public interface MyLogger extends Logger {
@LoggingLevel(name=DIAG)
void diag(String message);
// optional other methods
 }

 They get an instance of this interface by calling:
 LogManager.getCustomLogger(MyLogger.class);

 LogManager has access to the processed configuration. The config has
 LevelsLevel name=DIAG intValue=450 elements. During
 configuration
 processing, the custom Level instances are created and registered, so
 on
 the first call to LogManager.getCustomLogger(MyLogger.class), the
 MyLogger
 instance is created and cached. Also, at this point the annotations
 are
 parsed to see what Level instance the MyLogger implementation will
 pass
 to
 the Logger.log(Level, String) method when the diag method is called.

 What is still open in this scenario is how the instance is created.
 Proxy?
 Or generate source  compile? Or use a byte code library?

 On Monday, January 27, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 I am going to have to echo what Nick said.  If you can think of a way
 to
 make

 logger.log(SomeClass.SomeLevel, hello world);

 work without actually creating SomeClass then please share!

 Ralph

 On Jan 26, 2014, at 7:45 PM, Nick Williams
 nicho...@nicholaswilliams.net
 wrote:

 It would not be possible to do this strictly through configuration
 because the user needs a compiled interface to code against. Where is
 that compiled interface to come from?

 Nick

 On Jan 26, 2014, at 9:40 PM, Scott Deboy wrote:

 If there is a way to support this strictly through configuration
 that
 would be ideal.

 I'm trying to find a way to remove my request for additional built
 in
 levels but through configuration instead of adding them ourselves.

 Scott
 Scott

 On Jan 26, 2014 7:38 PM, Nick Williams
 nicho...@nicholaswilliams.net
 wrote:
 Here's a split-off thread for discussing how we can make using
 custom
 levels easier. Some on the team have expressed a desire to make it
 even
 easier. Given hypothetical custom levels DIAG and NOTE, the
 following
 would be nice to have:

 logger.note(message);
 logger.diag(message);
 etc.

 We're to discuss how best to approach this. My proposal (from
 previous
 email):

 Allow the user to define an interface that /must/ extend Logger.
 That
 interface may contain any methods that match the following
 signatures
 (the interface must have at least one method and there is no limit
 to
 the number of methods it may have):

 void [methodName](Marker, Message)
 void [methodName](Marker, Message, Throwable t)
 void [methodName](Marker, Object)
 void [methodName](Marker, Object, Throwable t)
 void [methodName](Marker, String)
 void [methodName](Marker, String, Object...)
 void [methodName](Marker, String throwable)
 void [methodName](Message)
 void [methodName](Message, Throwable t)
 void [methodName](Object)
 void [methodName](Object, Throwable t)
 void [methodName](String)
 void [methodName](String, Object...)
 void [methodName](String throwable)

 Each method /must/ be annotated with @LoggingLevel(name =
 levelName). Now LogManager has a few new methods:

 T extends Logger T getCustomLogger(ClassT loggerClass)
 T extends Logger T getCustomLogger(ClassT loggerClass,
 Class?)
 T extends Logger T getCustomLogger(ClassT loggerClass,
 Class?,
 MessageFactory)
 T extends Logger T getCustomLogger(ClassT loggerClass

Re: Enums and Custom Levels

[Scott Deboy]

If levels are just a name and a value why require a class at all? What
about just having it defined in the configuration.
On Jan 25, 2014 4:37 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 Because we don't know the class name that the Level belongs to.  It is
 referenced in the configuration just as DIAG, not
 org.apache.logging.test.ExtendedLevel.DIAG.

 In any case I fixed it.  I just annotated the new Level as a Plugin and
 then look up all the Level plugins in BaseConfiguration. Simply calling the
 getEnumConstants method on each of the classes does the trick.

 Ralph



 On Jan 25, 2014, at 4:26 PM, Paul Benedict pbened...@apache.org wrote:

 If you made it a requirement for the constructor to register, why not just
 instantiate each level as you encounter it in the config?


 On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:

 Hmm. It seems I am going to have to do something to force the
 registration as the custom level class hasn't been constructed before the
 levels are referenced in the configuration.

 Ralph

 On Jan 25, 2014, at 3:43 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 In the constructor each of them calls Levels.addLevel(this).

 Ralph

 On Jan 25, 2014, at 2:21 PM, Remko Popma remko.po...@gmail.com wrote:

 Interesting! So, users would add custom levels by creating a new enum
 that implements the Level interface? How does the new enum get registered?
 In config or in code?

 Just trying to understand how it works...

 (With Nick's class I understood how that would work: users would extend
 the Level class and pass an instance of that class to the Logger.log()
 methods; in config they could specify the new Level name, and the
 Level.toLevel(String, Level) method would find the custom instance in a
 static HashMap in the Level superclass.)

 On Sunday, January 26, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 Here is what I am implementing:

 1. Level is now an Interface.  This allows the vast amount of code to
 continue to work.
 2. The current Level enum has been renamed to StdLevel. It implements
 the Level interface.
 3. A new class named Levels is in the spi package of the API. It
 contains a ConcurrentMap containing all the registered Levels as well as
 the static methods that were previously part of the Level enum.

 For the most part the conversion to this has been pretty easy.  The most
 frustrating part was that I had to move the toLevel methods from what was
 the Level enum to the Levels class as static methods are not allowed in
 interfaces until Java 8. This meant I had to modify several classes to use
 Levels.toLevel instead of Level.toLevel.  In addition, a few classes were
 using the valueOf enum method. Those were converted to use Levels.getLevel.

 The few places were Level is actually used as an enum were also pretty
 easy to handle as in those cases the custom levels need to be converted to
 a StdLevel and then that enum is used.

 Unless anyone objects I plan on committing this later today once I
 finish it and create some tests and documentation.

 Ralph



 On Jan 25, 2014, at 12:49 PM, Nicholas Williams 
 nicho...@nicholaswilliams.net wrote:

 No, of course, everyone seems to agree that custom levels should be
 permitted. But I never heard agreement on whether we were going the
 extensible enum route or the Level-as-interface route. The camp still
 seemed to disagree on that.

 Nick

 Sent from my iPhone, so please forgive brief replies and frequent typos

 On Jan 25, 2014, at 11:20, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 I have not heard anyone disagree with allowing custom Levels.  The
 disagreement I am hearing is over adding new pre-defined levels.

 Ralph

 On Jan 25, 2014, at 7:29 AM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 I may have missed something. Did we decide on an approach? Last I heard,
 the camp was still split: Some wanted to go with my extensible enum, others
 wanted to change Level to an interface and make a Levels enum.

 So I'm a bit confused. Which implementation are you working on?

 Nick

 On Jan 25, 2014, at 7:08 AM, Ralph Goers wrote:

 I am working on the implementation of custom levels now.  I should have
 it done today.

 Ralph

 On Jan 24, 2014, at 7:07 PM, Remko Popma remko.po...@gmail.com wrote:

 What is the best way to make progress on the custom levels
 implementation?

 Do we re-open LOG4J-41 or start a fresh Jira ticket? For implementation
 ideas, do we attach files to Jira, or create a branch?

 Remko

 On Saturday, January 25, 2014, Gary Gregory garydgreg...@gmail.com
 wrote:

 On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma remko.po...@gmail.comwrote:

 Gary,

 The hard-coded levels were proposed because it seemed that the
 extensible enum idea raised by Nick was not going to be accepted.
 My original position was that Markers could fulfill the requirement but
 Nick and yourself made it clear that this was not satisfactory.

 With extensible enums 

Re: Enums and Custom Levels

[Scott Deboy]

There's no way to add support for users to define level entries (name and
value pairs as a new element in the config) and have us do the work to make
those valid? That would get get rid of my request for additional levels,
right?
On Jan 25, 2014 6:15 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 The class is needed because it is a name and a value (two items) that has
 to be represented as a single parameter to Logger methods.  Using raw int
 or String is not a good alternative.

 Ralph

 On Jan 25, 2014, at 4:54 PM, Scott Deboy scott.de...@gmail.com wrote:

 If levels are just a name and a value why require a class at all? What
 about just having it defined in the configuration.
 On Jan 25, 2014 4:37 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 Because we don't know the class name that the Level belongs to.  It is
 referenced in the configuration just as DIAG, not
 org.apache.logging.test.ExtendedLevel.DIAG.

 In any case I fixed it.  I just annotated the new Level as a Plugin and
 then look up all the Level plugins in BaseConfiguration. Simply calling the
 getEnumConstants method on each of the classes does the trick.

 Ralph



 On Jan 25, 2014, at 4:26 PM, Paul Benedict pbened...@apache.org wrote:

 If you made it a requirement for the constructor to register, why not
 just instantiate each level as you encounter it in the config?


 On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:

 Hmm. It seems I am going to have to do something to force the
 registration as the custom level class hasn't been constructed before the
 levels are referenced in the configuration.

 Ralph

 On Jan 25, 2014, at 3:43 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 In the constructor each of them calls Levels.addLevel(this).

 Ralph

 On Jan 25, 2014, at 2:21 PM, Remko Popma remko.po...@gmail.com wrote:

 Interesting! So, users would add custom levels by creating a new enum
 that implements the Level interface? How does the new enum get registered?
 In config or in code?

 Just trying to understand how it works...

 (With Nick's class I understood how that would work: users would extend
 the Level class and pass an instance of that class to the Logger.log()
 methods; in config they could specify the new Level name, and the
 Level.toLevel(String, Level) method would find the custom instance in a
 static HashMap in the Level superclass.)

 On Sunday, January 26, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 Here is what I am implementing:

 1. Level is now an Interface.  This allows the vast amount of code to
 continue to work.
 2. The current Level enum has been renamed to StdLevel. It implements
 the Level interface.
 3. A new class named Levels is in the spi package of the API. It
 contains a ConcurrentMap containing all the registered Levels as well as
 the static methods that were previously part of the Level enum.

 For the most part the conversion to this has been pretty easy.  The
 most frustrating part was that I had to move the toLevel methods from what
 was the Level enum to the Levels class as static methods are not allowed in
 interfaces until Java 8. This meant I had to modify several classes to use
 Levels.toLevel instead of Level.toLevel.  In addition, a few classes were
 using the valueOf enum method. Those were converted to use Levels.getLevel.

 The few places were Level is actually used as an enum were also pretty
 easy to handle as in those cases the custom levels need to be converted to
 a StdLevel and then that enum is used.

 Unless anyone objects I plan on committing this later today once I
 finish it and create some tests and documentation.

 Ralph



 On Jan 25, 2014, at 12:49 PM, Nicholas Williams 
 nicho...@nicholaswilliams.net wrote:

 No, of course, everyone seems to agree that custom levels should be
 permitted. But I never heard agreement on whether we were going the
 extensible enum route or the Level-as-interface route. The camp still
 seemed to disagree on that.

 Nick

 Sent from my iPhone, so please forgive brief replies and frequent typos

 On Jan 25, 2014, at 11:20, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 I have not heard anyone disagree with allowing custom Levels.  The
 disagreement I am hearing is over adding new pre-defined levels.

 Ralph

 On Jan 25, 2014, at 7:29 AM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 I may have missed something. Did we decide on an approach? Last I
 heard, the camp was still split: Some wanted to go with my extensible enum,
 others wanted to change Level to an interface and make a Levels enum.

 So I'm a bit confused. Which implementation are you working on?

 Nick

 On Jan 25, 2014, at 7:08 AM, Ralph Goers wrote:

 I am working on the implementation of custom levels now.  I should have
 it done today.

 Ralph

 On Jan 24, 2014, at 7:07 PM, Remko Popma remko.po...@gmail.com wrote:

 What is the best way to make progress on the custom levels
 implementation?

 Do we re-open

Re: Enums and Custom Levels

[Scott Deboy]

Great! That plus support for defining custom levels from the config (with
no custom class required) would mean we would have found a solution that I
believe resolves everyone's issues.

Scott
On Jan 25, 2014 6:52 PM, Remko Popma remko.po...@gmail.com wrote:

 I've started to think about how to implement Gary's idea to use these
 custom levels to generate code that would add methods to the Logger
 interface, but I think I'll wait a little to see what form the custom
 levels take.


 On Sun, Jan 26, 2014 at 11:45 AM, Remko Popma remko.po...@gmail.comwrote:

 These are the switches I found:
 * log4j-1.2-api: org.apache.log4j.Category - just FYI, it looks like this
 switch is missing the FATAL level... is this a bug?
 * log4j-api: org.apache.logging.log4j.status.StatusLogger
 * log4j-core: org.apache.logging.log4j.core.net.Severity
 * log4j-core: org.apache.logging.log4j.core.pattern.LevelPatternConverter
 - perhaps just return level  + level.toString(); ?
 * log4j-to-slf4j: org.apache.logging.slf4j.SLF4JLogger



 On Sun, Jan 26, 2014 at 11:41 AM, Ralph Goers ralph.go...@dslextreme.com
  wrote:

 I am not sure what you mean by this.  I have already succeeded in adding
 custom level names to the configuration and making them be valid.  I am
 just trying to clean it up a bit based on what Nick is suggesting.

 Ralph

 On Jan 25, 2014, at 6:30 PM, Scott Deboy scott.de...@gmail.com wrote:

 There's no way to add support for users to define level entries (name
 and value pairs as a new element in the config) and have us do the work to
 make those valid? That would get get rid of my request for additional
 levels, right?
 On Jan 25, 2014 6:15 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 The class is needed because it is a name and a value (two items) that
 has to be represented as a single parameter to Logger methods.  Using raw
 int or String is not a good alternative.

 Ralph

 On Jan 25, 2014, at 4:54 PM, Scott Deboy scott.de...@gmail.com wrote:

 If levels are just a name and a value why require a class at all? What
 about just having it defined in the configuration.
 On Jan 25, 2014 4:37 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 Because we don’t know the class name that the Level belongs to.  It is
 referenced in the configuration just as “DIAG”, not
 “org.apache.logging.test.ExtendedLevel.DIAG”.

 In any case I fixed it.  I just annotated the new Level as a Plugin
 and then look up all the Level plugins in BaseConfiguration. Simply 
 calling
 the getEnumConstants method on each of the classes does the trick.

 Ralph



 On Jan 25, 2014, at 4:26 PM, Paul Benedict pbened...@apache.org
 wrote:

 If you made it a requirement for the constructor to register, why not
 just instantiate each level as you encounter it in the config?


 On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers 
 ralph.go...@dslextreme.com wrote:

 Hmm. It seems I am going to have to do something to force the
 registration as the custom level class hasn’t been constructed before the
 levels are referenced in the configuration.

 Ralph

 On Jan 25, 2014, at 3:43 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 In the constructor each of them calls Levels.addLevel(this).

 Ralph

 On Jan 25, 2014, at 2:21 PM, Remko Popma remko.po...@gmail.com
 wrote:

 Interesting! So, users would add custom levels by creating a new enum
 that implements the Level interface? How does the new enum get 
 registered?
 In config or in code?

 Just trying to understand how it works...

 (With Nick's class I understood how that would work: users would
 extend the Level class and pass an instance of that class to the
 Logger.log() methods; in config they could specify the new Level name, 
 and
 the Level.toLevel(String, Level) method would find the custom instance 
 in a
 static HashMap in the Level superclass.)

 On Sunday, January 26, 2014, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 Here is what I am implementing:

 1. Level is now an Interface.  This allows the vast amount of code
 to continue to work.
 2. The current Level enum has been renamed to StdLevel. It
 implements the Level interface.
 3. A new class named Levels is in the spi package of the API. It
 contains a ConcurrentMap containing all the registered Levels as well as
 the static methods that were previously part of the Level enum.

 For the most part the conversion to this has been pretty easy.  The
 most frustrating part was that I had to move the toLevel methods from 
 what
 was the Level enum to the Levels class as static methods are not 
 allowed in
 interfaces until Java 8. This meant I had to modify several classes to 
 use
 Levels.toLevel instead of Level.toLevel.  In addition, a few classes 
 were
 using the valueOf enum method. Those were converted to use 
 Levels.getLevel.

 The few places were Level is actually used as an enum were also
 pretty easy to handle as in those cases the custom levels need to be
 converted to a StdLevel and then that enum is used.

 Unless

Re: Enums and Custom Levels

[Scott Deboy]

They can already do the same thing with loggers right?

Scott
On Jan 25, 2014 10:19 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 A malicious app could do

 for (int i=0; i  10; ++i) {
   new Level(“Level” + i, 1000 + i){};
 }

 Sure idiots can do lots of bad things but I don’t think Levels should be
 quite that flexible.

 Ralph

 On Jan 25, 2014, at 9:39 PM, Remko Popma remko.po...@gmail.com wrote:

 I don't think client code can do new Level(){} as the constructor requires
 String and int arguments.

 By the way, I am unclear on what went wrong with the enum approach you
 originally took.
 You said:
 StdLevel isn’t a Level because it can’t extend it if it is an enum,
 so I can’t initialize the levels using that.

 I don't understand. StdLevel implements the Level interface, right? So
 what do you mean by it can't extend it?

 The reason I ask is that for the code generation, real java enums may be
 easier to deal with than the extensible enum approach.


 On Sun, Jan 26, 2014 at 2:30 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:

 Out of curiosity, what exactly is the benefit of declaring the class
 abstract when it has a protected constructor?  It seems like all you are
 accomplishing is making the instantiation syntax uglier. It also bothers me
 that open code can just do a new Level(){} - which will do nothing but
 cause problems.  I’m beginning to think that we should require an
 annotation on the Level declaration of the extension class to avoid that.

 Ralph

 On Jan 25, 2014, at 9:13 PM, Remko Popma remko.po...@gmail.com wrote:

 Ralph,
 I copied Nick's code _as is_ and had no compile errors.
 The class is abstract, but instances are defined in the static block as:
 OFF = new Level(OFF, 0) {}; // note the {}: this creates an anonymous
 concrete subclass

 I agree that read access needs to be synchronized as well, not just write
 access (the constructor).
 I experimented with several options:
 * synchronizing on plain Object in both constructor and when accessing
 the static Map(s)
 * a ReentrantReadWriteLock
 * a lock-free implementation

 I decided against ReentrantReadWriteLock as it has more overhead than
 plain synchronized access and the write access (in the constructors) is
 going to be extremely rare: not worth paying the overhead in the more
 common reads. It is also cumbersome to code.

 The lock-free implementation uses an AtomicInteger for the ordinals, and
 an AtomicReference for the MapString, Level.
 In the constructor, create a new MapString, Level instance based on the
 old copy, add the new instance, and try to call compareAndSet to replace
 the old instance with the new instance. Retry on failure.

 Finally, simply synchronizing on the constructorLock object in the
 Level.toLevel() and Level.values() methods may be simplest.

 Which of the last two is best depends on how often the toLevel() and
 values() levels are called.
 It turns out they are only called during reconfiguration, so no real need
 to optimize these methods.
 I would argue that simple synchronization may be best in this case.

 Remko



 On Sun, Jan 26, 2014 at 1:49 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:

 As I am working on this I just want to point out a number of issues with
 the code below:

 1. The class is abstract. The static block is doing a bunch of new
 Level() invocations which obviously generate compile errors on an abstract
 class.  I had to make it be a non-abstract class.
 2. As I pointed out before there is no way to access the “standard”
 levels as an enum. I have addressed that.
 3. Although the constructor is synchronized access to the Map is not.
 Trying to get from the map while a Level is being added will result in a
 ConcurrentModificationException. I am using a ConcurrentMap instead.
 3. The constructor requires synchronization because it is modifying both
 the map and the ordinal. However, since this isn’t an enum the ordinal
 value is of dubious value. Removing that would allow the removal of the
 synchronization in the constructor. I am considering that but I haven’t
 done it yet.
 4. Your example of creating the extension shows doing a new Level().
 This doesn’t work because a) the class is abstract and b) the constructor
 is protected. I am leaving the constructor protected so extension will
 require doing new ExtendedLevel(name, value) and creating a constructor.
 Not requiring that means applications can do a new Level() anywhere and I
 am opposed to allowing that.

 Ralph

 On Jan 23, 2014, at 12:42 AM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

  Okay, I finally got a minute to read all of these emails, and...
 
  EVERYBODY FREEZE!
 
  What if I could get you an extensible enum that required no interface
 changes and no binary-incompatible changes at all? Sound too good to be
 true? I proposed this months ago (LOG4J2-41) and it got shot down multiple
 times, but as of now I've heard THREE people say extensible enum in this
 thread, so 

Re: Levels added in revision 1560602

[Scott Deboy]

,
 theses are I know I can change my code now to use the new levels.
 Granted, I am an advanced user. But like any system, I started using a
 few
 features and then more and more.

 We do use TRACE for some method entry and exit. And we use DEBUG a lot.
 But we need a level, among other things, for wire level hex dumps in all
 the different parts of the systems where many loggers are used. A level
 between TRACE and DEBUG would be a perfect solution. I and others have
 made
 a good case for the NOTICE level as well, which some wanted as CONFIG.

 I see the new levels as a refinement based on experience.

 Is this now a religious debate in which there is 0 chance of convincing
 you? Or is there 1 chance?


 The proposed levels can easily confuse users or get in the way of users
 wanting to use these names at different strengths or with a different
 intended usage.


 Whaaat? How can you presume to know users like that? Give people more
 credit than that, we are talking about programmers here. For our end
 users,
 our support folks tell them Set the level to X and run the program, then
 send us the log where they use a GUI to generate log config files. Our
 consultants (some are programmers) that go onsite, know the software and
 what the levels mean. They and the users will be ecstatic if I say that
 the
 giant logs given by DEBUG will be smaller because all the hex dumps will
 be
 at the VERBOSE levels. The TRACE level is for developers debugging very
 low
 level code. FWIW, we had started to use different loggers for hex dumps
 but
 this was hard to enforce and harder to configure, so no more of that.

 So before I revert anything please answer these questions and try to
 convince _me_ :)

 Alternatively, feel free to reply with I VETO this commit and will
 revert the commit.

 Thank you kindly for considering these opinions,

 Gary



 The fact that changes for these levels have already been committed is
 IMHO not an argument in its favor. On the contrary, I was surprised at
 the
 timing of this commit: it was clear that many people were opposed to
 this
 approach. To me it was also clear that we had started exploring
 extensible
 enums as a mechanism that would allow us to *avoid* adding pre-defined
 levels.


 To repeat my position: I don't think these levels should be added to the
 Log4J API.

 Remko

 On Friday, January 24, 2014, Remko Popma remko.po...@gmail.com wrote:

 I'm fine with Nick's proposal to have two separate votes.
 Remko

 On Friday, January 24, 2014, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 There has obviously been some serious discussion about these topics.
 We're not going to come to a total agreement on this. I propose:

 - We have a committers-only vote in the Enums and Custom Levels
 thread on whether to make Level an extensible enum.
 - AFTER having that vote, we have a committers-only vote in this
 thread
 on whether to add these three levels.
 - We only roll back this revision AFTER the second vote is complete
 and
 IF the vote rejects the new levels.

 Nick

 On Jan 23, 2014, at 7:58 AM, Paul Benedict wrote:

 On Thu, Jan 23, 2014 at 11:54 AM, Scott Deboy
 scott.de...@gmail.comwrote:

 We don't need to scuttle the new levels to support extensible levels.



 Of course. The two things are not technically related. That's not what
 this is about, though. Since there are camps for and against the new
 levels, I was hoping the extensible enum feature would bring about a
 compromise.



 Gary's change is essentially a 'usability enhancement' - if anything
 close to 80% of the folks who might want custom levels can use new
 built-in levels, that's an API win in my book.  Custom levels help
 the
 other 20%, and I'm supportive of that.

 Also please keep in mind this doesn't really add to our maintenance
 burden, which I think may be contributing to the concern about adding
 new levels.  Gary already did the heavy lifting, and the change to
 something other than an enum for levels would just be a bit more work
 because of this addition.

 Scott

 On 1/23/14, Paul Benedict pbened...@apache.org wrote:
  Let's not lose sight why the extensible enum discussion occurred.
  Speaking solely for myself, I am not fond of the new logging
  levels;
 but I
  don't want the framework from preventing them. The intention behind
 this
  proposal was to get agreement by scuttling the new levels but
 allowing
  anyone to add them in their own private code.
 
 


 Paul






 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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

Re: Levels added in revision 1560602

[Scott Deboy]

I think the 'levels=severity' model broke down a bit when we added
TRACE, and FATAL is never used, so I think it's reasonable to say
there isn't a strict severity we can use even today - which is why we
have so few levels (trying to stick to the severity model).

By the way, we should remove FATAL, yes?
Scott

On 1/24/14, Paul Benedict pbened...@apache.org wrote:
 I agree. When anyone starts talking about types of informational messages
 or types of debug information, those should be distinguished with
 markers.

 My mental model is this:
 levels = severity
 markers = kinds/types



 On Fri, Jan 24, 2014 at 1:57 PM, Ralph Goers
 ralph.go...@dslextreme.comwrote:

 I would tend to agree with the way you are using them.

 I do see a a need for DIAG (or whatever other name you like).  We don’t
 tend to use a lot of info messages as those are just nice to know things
 but probably wouldn’t aid a lot in problem diagnosis.  OTOH, DEBUG tends
 to
 log everything except method entry and exit.  This is typically much more
 than what operators or users need to determine what might have caused a
 problem.  INFO could be used for this but I’m not sure that the name
 “Informational” lends itself to people thinking it will contain messages
 to
 aid in problem diagnosis. The only issue I see with adding a DIAG level
 is
 getting programmers to actually use it properly - but I don’t think that
 is
 our problem.

 I do agree with the notion that logging configuration or initialization
 is
 important, but as I’ve stated I think the best way to do that is with
 Markers.  The same technique that was mentioned previously about creating
 specific loggers for that is easy to do with Markers - see EventLogger
 for
 an example.

 Ralph


 On Jan 24, 2014, at 11:39 AM, Paul Benedict pbened...@apache.org wrote:

 This is how I use today's levels:

 TRACE - entry and exit of methods, raw and extremely detailed data dumps
 DEBUG - status and configuration to view while application is running for
 developer inspection purposes
 INFO - application state changes that an operator may need to know to
 inspect health of program
 WARN - failure/exception that can be recovered (alternate choice of
 action
 does exist)
 ERROR - failure/exception that can't be recovered from (the normal case)
 FATAL - failure/exception that is known to render the application
 unusable

 Paul


 On Fri, Jan 24, 2014 at 1:20 PM, Christian Grobmeier
 grobme...@gmail.comwrote:

 What I miss in this discussion are actually good examples of what the
 (new) log levels are intended for.

 In example, Gary mentioned he is on a wireshark level with  trace.
 That's fine, because it would give some idea when to use verbose (maybe
 entering method).

 Maybe I missed it when what I ask for was already written,
 but I believe if we can give concrete example how log levels should be
 used then we are a step further.

 I was asked quite a log what should be logged with which level.

 I think making the difference between trace and debug is already
 difficult for a lot of users.
 In the past two years i asked a lot of people how they log.

 The answer was: exceptions on error, the rest on debug.

 What we lack is a good recommendation how log levels should be used.
 Something which is on our front page and which lets the average Java
 programmer fully
 understand when he uses what, and maybe even why.

 If we have something like that it is much easier to argue pro/contra
 the new log levels.






 On 24 Jan 2014, at 18:36, Scott Deboy wrote:

  To be fair, I think we represent a reasonable fraction of the
 users..some won't touch new predefined levels, some will use it -
 that's the reason for adding it - we hit a significant portion of use
 cases with small additional number of built-in levels.

 The two solutions don't provide the same thing, do they?  If they do,
 I wouldn't be pressing the issue.

 If there is a way for us, via annotations or whatever mechanism we
 define for 'custom levels', to add support easily for the newly
 pre-defined levels, then we should do it.

 Specifically, I'm ok with any mechanism (even using the new custom
 level mechanism, but provide by log4j itself), where log4j users are
 able to call:

 logger.notice(something);

 Anything else and it won't meet my expectations for usability.

 By the way, while we're at it, let's remove fatal.

 Scott


 On 1/24/14, Remko Popma remko.po...@gmail.com wrote:

 I'm not questioning your experience, and I believe you when you say
 that
 the proposed levels would be a perfect match for your current work
 environment.

 However, out of the eight people that participated in the discussion
 on
 adding levels, four expressed strong reservations about adding
 pre-defined
 levels. We are all programmers on this list. So I think we can
 reasonable
 assume that a large fraction of users would also not like this change.

 On top of that, we have a more powerful and elegant alternative
 solution
 that makes adding pre

Re: Levels added in revision 1560602

[Scott Deboy]

I don't think the two have to be mutually exclusive - we can enhance
'custom level' support via a new mechanism and add built-in support
for the new levels as well.

I personally don't think they're confusing, as folks have mentioned,
httpd uses them.

I used to think of levels as 'severities', but that's really only true
for a subset of levels we have now (trace isn't really a severity,
right? and fatal, well, it's never used), so my gut says these new
levels support the 80/20 rule for 'custom levels'

Chainsaw/ExpressionFilter etc (assuming log4j2 support) will have to
deal with this eventually (level  DEBUG) etc, but I don't think
that's a big deal.

Scott


On 1/23/14, Ralph Goers ralph.go...@dslextreme.com wrote:
 Remko, are you saying that if we make the changes proposed in the other
 thread that we should not add any of these levels to the new Level class?

 Ralph

 On Jan 23, 2014, at 1:22 AM, Remko Popma remko.po...@gmail.com wrote:

 Gary,

 Would you mind rolling back the changes you made in revision 1560602 (and
 perhaps r1560356)?
 This change added DIAG, VERBOSE, NOTICE log levels to many files.
 I don't think we all agreed on that approach and we have some promising
 ideas for an alternative solution that should satisfy everyone.

 Best regards,
 Remko


 -
 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: Levels added in revision 1560602

[Scott Deboy]

We don't need to scuttle the new levels to support extensible levels.

Gary's change is essentially a 'usability enhancement' - if anything
close to 80% of the folks who might want custom levels can use new
built-in levels, that's an API win in my book.  Custom levels help the
other 20%, and I'm supportive of that.

Also please keep in mind this doesn't really add to our maintenance
burden, which I think may be contributing to the concern about adding
new levels.  Gary already did the heavy lifting, and the change to
something other than an enum for levels would just be a bit more work
because of this addition.

Scott

On 1/23/14, Paul Benedict pbened...@apache.org wrote:
 Let's not lose sight why the extensible enum discussion occurred.
 Speaking solely for myself, I am not fond of the new logging levels; but I
 don't want the framework from preventing them. The intention behind this
 proposal was to get agreement by scuttling the new levels but allowing
 anyone to add them in their own private code.


 On Thu, Jan 23, 2014 at 11:39 AM, Gary Gregory
 garydgreg...@gmail.comwrote:

 Well said Scott.

 These are two separate features.

 Gary


  Original message 
 From: Scott Deboy
 Date:01/23/2014 11:49 (GMT-05:00)
 To: Log4J Developers List
 Subject: Re: Levels added in revision 1560602

 I don't think the two have to be mutually exclusive - we can enhance
 'custom level' support via a new mechanism and add built-in support
 for the new levels as well.

 I personally don't think they're confusing, as folks have mentioned,
 httpd uses them.

 I used to think of levels as 'severities', but that's really only true
 for a subset of levels we have now (trace isn't really a severity,
 right? and fatal, well, it's never used), so my gut says these new
 levels support the 80/20 rule for 'custom levels'

 Chainsaw/ExpressionFilter etc (assuming log4j2 support) will have to
 deal with this eventually (level  DEBUG) etc, but I don't think
 that's a big deal.

 Scott


 On 1/23/14, Ralph Goers ralph.go...@dslextreme.com wrote:
  Remko, are you saying that if we make the changes proposed in the other
  thread that we should not add any of these levels to the new Level
  class?
 
  Ralph
 
  On Jan 23, 2014, at 1:22 AM, Remko Popma remko.po...@gmail.com wrote:
 
  Gary,
 
  Would you mind rolling back the changes you made in revision 1560602
 (and
  perhaps r1560356)?
  This change added DIAG, VERBOSE, NOTICE log levels to many files.
  I don't think we all agreed on that approach and we have some
  promising
  ideas for an alternative solution that should satisfy everyone.
 
  Best regards,
  Remko
 
 
  -
  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




 --
 Cheers,
 Paul


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

Re: Enums and Custom Levels

[Scott Deboy]

I don't think we need a vote on the new level code..there's no good
technical reason to ask it to be removed, and it is likely to be
useful to some group of folks.

I think we're doing a good job on the other thread bouncing ideas of
how to handle extensible levels, and that conversation should continue
on that thread until we reach consensus, which I'm sure we will be
able to do.

Scott

On 1/23/14, Remko Popma remko.po...@gmail.com wrote:
 I'm fine with Nick's proposal to have two separate votes.
 Remko

 On Friday, January 24, 2014, Nick Williams nicho...@nicholaswilliams.net
 wrote:

 By a generic definition, this new Level is certainly an enum. And it's
 written in Java. No, it's not a Java-language official enum. But, as far
 as
 byte code goes, it's nearly identical to an official enum. Users who
 don't
 need custom levels will use it EXACTLY like they would use an enum. It's
 an
 improvement over a traditional enum only in that you can extend it. I see
 no downsides at all.

 There has obviously been some serious discussion about these topics.
 We're
 not going to come to a total agreement on this. I propose:

 - We have a committers-only vote in this thread on whether to make Level
 an extensible enum.
 - AFTER having that vote, we have a committers-only vote in the Levels
 added in revision 1560602 thread on whether to add the three levels that
 were added.
 - We only roll back 1560602 AFTER the second vote is complete and IF the
 vote rejects the new levels.

 Nick

 On Jan 23, 2014, at 6:23 AM, Ralph Goers wrote:

 I’m more in favor of this than what you had proposed. To be honest, with
 what you proposed I don’t see much value left in keeping the Level enum.

 Yes, I prefer using the enum (obviously, or I wouldn’t have implemented
 it
 that way), but if the consensus is to change it to a class, so be it.

 As for comments on the below, I think it needs a bit of tweaking (I
 wouldn’t use Hashtable) but it may be a better option than adding more
 levels.  Or we could add the extra levels but not add new methods for
 them
 to AbstractLogger.

 Ralph

 On Jan 23, 2014, at 7:49 AM, Paul Benedict pbened...@apache.org wrote:

 It's a neat idea but it's not a Java enum. I think one of Ralph's goal
 was
 to allow client code to use enums. I still think we should continue that
 path. At any rate, this will hopefully lead to a synthesis of ideas and
 agreement.


 On Thu, Jan 23, 2014 at 8:22 AM, Matt Sicker boa...@gmail.com wrote:

 Neat idea. I'd update it for proper concurrency, though. I could write a
 mock version of this to show what I mean.

 Matt Sicker

  On Jan 23, 2014, at 2:42, Nick Williams nicho...@nicholaswilliams.net
 wrote:
 
  Okay, I finally got a minute to read all of these emails, and...
 
  EVERYBODY FREEZE!
 
  What if I could get you an extensible enum that required no interface
 changes and no binary-incompatible changes at all? Sound too good to be
 true? I proposed this months ago (LOG4J2-41) and it got shot down
 multiple
 times, but as of now I've heard THREE people say extensible enum in
 this
 thread, so here it is, an extensible enum:
 
  public abstract class Level implements ComparableLevel, Serializable
  {
 public static final Level OFF;
 public static final Level FATAL;
 public static final Level ERROR;
 public static final Level WARN;
 public static final Level INFO;
 public static final Level DEBUG;
 public static final Level TRACE;
 public static final Level ALL;
 
 
 private static final long serialVersionUID = 0L;
 private static final HashtableString, Level map;
 private static final TreeMapInteger, Level values;
 private static final Object constructorLock;
 
 
 static {
 // static variables must be constructed in certain order
 constructorLock = new Object();
 map = new HashtableString, Level();
 values = new TreeMapInteger, Level();
 OFF = new Level(OFF, 0) {};
 FATAL = new Level(FATAL, 100) {};
 ERROR = new Level(ERROR, 200) {};
 WARN = new Level(WARN, 300) {};
 INFO = new Level(INFO, 400) {};
 DEBUG = new Level(DEBUG, 500) {};
 TRACE = new Level(TRACE, 600) {};
 ALL = new Level(ALL, Integer.MAX_VALUE) {};
 }
 
 
 private static int ordinals;
 
 
 private final String name;
 private final int intLevel;
 private final int ordinal;
 
 
 protected Level(String name, int intLevel) {
 if(name == null || name.length() == 0)
 throw new IllegalArgumentException(Illegal null Level
 constant);
 if(intLevel  0)
 throw new IllegalArgumentException(Illegal Level int less
 than zero.);
 synchronized (Level.constructorLock) {
 if(Level.map.containsKey(name.toUpperCase()))
 throw new IllegalArgumentException(Duplicate Level
 constant [ + name + ].);
 if(Level.values.containsKey(intLevel))
 throw new 

Re: Enums and Custom Levels

[Scott Deboy]

I understand folks may not 'prefer' to have the additional levels, but
if it won't cause us a maintenance burden (it won't), and it it's
already in place (it is) and it provides a simple mechanism for a
majority of the 'custom level' needs (very likely), there really isn't
much of a disagreement is there?

As I mentioned, other than statements of preference, I don't see what
technical reasons there would be for not wanting to provide this
simple mechanism to our end users.

If you want to vote, first let's have a 'discuss' thread where we
explain why folks are against something that's already implemented -
hopefully due to technical reasons, and not just personal preference.

Scott

On 1/23/14, Remko Popma remko.po...@gmail.com wrote:
 Scott, with all respect, I disagree.

 True, WRT extensible enum (this thread) I haven't seen anyone opposing this
 idea. We're still fine-tuning the implementation but I haven't seen anyone
 arguing against this. I don't mind making sure of that with a vote though.

 However, WRT the new levels (the other thread) I am not confident that we
 can reach consensus.

 If we follow the Apache process, the first vote will be open for 72 hours
 (correct me if I'm wrong) anyway. That should give everyone enough time to
 explain their position on the new levels before we start  the second vote.
 Who knows, perhaps we're all in agreement by that time...


 On Friday, January 24, 2014, Scott Deboy scott.de...@gmail.com wrote:

 I don't think we need a vote on the new level code..there's no good
 technical reason to ask it to be removed, and it is likely to be
 useful to some group of folks.

 I think we're doing a good job on the other thread bouncing ideas of
 how to handle extensible levels, and that conversation should continue
 on that thread until we reach consensus, which I'm sure we will be
 able to do.

 Scott

 On 1/23/14, Remko Popma remko.po...@gmail.com wrote:
  I'm fine with Nick's proposal to have two separate votes.
  Remko
 
  On Friday, January 24, 2014, Nick Williams 
 nicho...@nicholaswilliams.net
  wrote:
 
  By a generic definition, this new Level is certainly an enum. And it's
  written in Java. No, it's not a Java-language official enum. But, as
  far
  as
  byte code goes, it's nearly identical to an official enum. Users who
  don't
  need custom levels will use it EXACTLY like they would use an enum.
  It's
  an
  improvement over a traditional enum only in that you can extend it. I
 see
  no downsides at all.
 
  There has obviously been some serious discussion about these topics.
  We're
  not going to come to a total agreement on this. I propose:
 
  - We have a committers-only vote in this thread on whether to make
  Level
  an extensible enum.
  - AFTER having that vote, we have a committers-only vote in the
  Levels
  added in revision 1560602 thread on whether to add the three levels
 that
  were added.
  - We only roll back 1560602 AFTER the second vote is complete and IF
  the
  vote rejects the new levels.
 
  Nick
 
  On Jan 23, 2014, at 6:23 AM, Ralph Goers wrote:
 
  I’m more in favor of this than what you had proposed. To be honest,
  with
  what you proposed I don’t see much value left in keeping the Level
  enum.
 
  Yes, I prefer using the enum (obviously, or I wouldn’t have
  implemented
  it
  that way), but if the consensus is to change it to a class, so be it.
 
  As for comments on the below, I think it needs a bit of tweaking (I
  wouldn’t use Hashtable) but it may be a better option than adding more
  levels.  Or we could add the extra levels but not add new methods for
  them
  to AbstractLogger.
 
  Ralph
 
  On Jan 23, 2014, at 7:49 AM, Paul Benedict pbened...@apache.org
 wrote:
 
  It's a neat idea but it's not a Java enum. I think one of Ralph's goal
  was
  to allow client code to use enums. I still think we should continue
  that
  path. At any rate, this will hopefully lead to a synthesis of ideas
  and
  agreement.
 
 
  On Thu, Jan 23, 2014 at 8:22 AM, Matt Sicker boa...@gmail.com wrote:
 
  Neat idea. I'd update it for proper concurrency, though. I could write
  a
  mock version of this to show what I mean.
 
  Matt Sicker
 
   On Jan 23, 2014, at 2:42, Nick Williams 
 nicho...@nicholaswilliams.net
  wrote:
  
   Okay, I finally got a minute to read all of these emails, and...
  
   EVERYBODY FREEZE!
  
   What if I could get you an extensible enum that required no
   interface
  changes and no binary-incompatible changes at all? Sound too good to
  be
  true? I proposed this months ago (LOG4J2-41) and it got shot down
  multiple
  times, but as of now I've heard THREE people say extensible enum in
  this
  thread, so here it is, an extensible enum:
  
   public abstract class Level implements ComparableLevel,
   Serializable
   {
  public static final Level OFF;
  public static final Level FATAL;
  public static final Level ERROR;
  public static final Level WARN;
  public static final Level INFO

Re: software does not neutralize output that is logged

[Scott Deboy]

See http://logging.apache.org/log4j/2.x/manual/appenders.html#RewriteAppender

On 1/21/14, Saibabu Vallurupalli saibabu.vallurupa...@gmail.com wrote:
 First of all Thanks so much for you all for the quickest response for this
 posting. I am thinking of writing a wrapper class and update the source,
 but we have about 2400 Java classes in the application which needs to be
 updated and are using log4j logger. I am trying to explore the option to
 avoid modifying all these classes with some kind of ingestion. Any
 suggestions around will be greatly appreciated.

 Thank you,
 Sai



 On Tue, Jan 21, 2014 at 5:20 PM, Paul Benedict pbened...@apache.org
 wrote:

 This is not an unusual requirement. I've been at a company that tries to
 scrub log files from certain patterns (like SSN #s). Can that be done in
 log4j? I don't know. It would be interesting to know if 2.0 had some sort
 of filtering capability. Remko? Gary? Ralph?


 On Tue, Jan 21, 2014 at 4:16 PM, Saibabu Vallurupalli 
 saibabu.vallurupa...@gmail.com wrote:

 So, we wanted to inspect the message which is getting logged out to
 avoid
 possible security issues. So, what exactly I am looking is If I wanted
 to
 add a restriction on whats been logged. How can I achieve this?

 For example: log.info(user name+username+Password+password); // This
 is just an example if I see a message having password do not log it or
 take
 some action.

 Please advise.

 Thank you,
 Sai


 On Tue, Jan 21, 2014 at 5:12 PM, Remko Popma
 remko.po...@gmail.comwrote:

 Sorry, but I have no idea what you mean by neutralize out.
 What is currently happening and what would you like to happen instead?

 Sent from my iPhone

  On 2014/01/22, at 6:29, Saibabu Vallurupalli 
 saibabu.vallurupa...@gmail.com wrote:
 
  Hi,
 
  I am working on an issue related to logging. I our application we are
 using log4j for logging and we detected our software doesn't neutralize
 out
 properly. Now, Is there any way without modifying the entire source by
 going through each and every class we can achieve this functionality of
 inspecting the message getting logged and take appropriate action.
 
  We appreciate your support.
 
  Thank you,
  Sai
 

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





 --
 Cheers,
 Paul



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

Re: software does not neutralize output that is logged

[Scott Deboy]

This mechanism is also available in log4j 1.2:

https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/rewrite/RewriteAppender.html


On 1/21/14, Scott Deboy scott.de...@gmail.com wrote:
 See
 http://logging.apache.org/log4j/2.x/manual/appenders.html#RewriteAppender

 On 1/21/14, Saibabu Vallurupalli saibabu.vallurupa...@gmail.com wrote:
 First of all Thanks so much for you all for the quickest response for
 this
 posting. I am thinking of writing a wrapper class and update the source,
 but we have about 2400 Java classes in the application which needs to be
 updated and are using log4j logger. I am trying to explore the option to
 avoid modifying all these classes with some kind of ingestion. Any
 suggestions around will be greatly appreciated.

 Thank you,
 Sai



 On Tue, Jan 21, 2014 at 5:20 PM, Paul Benedict pbened...@apache.org
 wrote:

 This is not an unusual requirement. I've been at a company that tries to
 scrub log files from certain patterns (like SSN #s). Can that be done in
 log4j? I don't know. It would be interesting to know if 2.0 had some
 sort
 of filtering capability. Remko? Gary? Ralph?


 On Tue, Jan 21, 2014 at 4:16 PM, Saibabu Vallurupalli 
 saibabu.vallurupa...@gmail.com wrote:

 So, we wanted to inspect the message which is getting logged out to
 avoid
 possible security issues. So, what exactly I am looking is If I wanted
 to
 add a restriction on whats been logged. How can I achieve this?

 For example: log.info(user name+username+Password+password); //
 This
 is just an example if I see a message having password do not log it or
 take
 some action.

 Please advise.

 Thank you,
 Sai


 On Tue, Jan 21, 2014 at 5:12 PM, Remko Popma
 remko.po...@gmail.comwrote:

 Sorry, but I have no idea what you mean by neutralize out.
 What is currently happening and what would you like to happen instead?

 Sent from my iPhone

  On 2014/01/22, at 6:29, Saibabu Vallurupalli 
 saibabu.vallurupa...@gmail.com wrote:
 
  Hi,
 
  I am working on an issue related to logging. I our application we
  are
 using log4j for logging and we detected our software doesn't
 neutralize
 out
 properly. Now, Is there any way without modifying the entire source by
 going through each and every class we can achieve this functionality
 of
 inspecting the message getting logged and take appropriate action.
 
  We appreciate your support.
 
  Thank you,
  Sai
 

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





 --
 Cheers,
 Paul




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

Re: Web Issues, Logging Levels, and GA

[Scott Deboy]

Right, that's what I meant. One trace level.
On Jan 20, 2014 8:15 PM, Gary Gregory garydgreg...@gmail.com wrote:

 On Mon, Jan 20, 2014 at 11:08 PM, Scott Deboy scott.de...@gmail.comwrote:

 That looks good. Without all the trace levels IMO.


 Well, we'd want to keep the ONE TRACE level IMO:

 FATAL
 ERROR
 WARN
 NOTICE* (NOTE)
 INFO
 DIAGNOSE* (DIAG, DIAGNOSTIC)
 DEBUG
 VERBOSE*
 TRACE

 * New level.

 Gary




  Scott
  On Jan 20, 2014 7:49 PM, Gary Gregory garydgreg...@gmail.com wrote:

 On Mon, Jan 20, 2014 at 10:40 PM, Paul Benedict pbened...@apache.orgwrote:

 If you really want extra logging levels without the long debate, just
 go copy the logging levels of Apache HTTPD. They already figured out where
 to place all the extra levels you guys are discussing and they've been
 around for years. It will be a worthy precedent to copy.


 That would be 16 levels then?
 https://httpd.apache.org/docs/2.4/mod/core.html#loglevel

 Gary


 On Jan 20, 2014 9:09 PM, Gary Gregory garydgreg...@gmail.com wrote:

 On Mon, Jan 20, 2014 at 9:54 PM, Paul Benedict 
 pbened...@apache.orgwrote:

 I know we had the debate of extra logging levels for the past year.
 The extra levels are very subjective. If anyone needs more than our
 standard five, please just use markers. We should even have a whole page 
 on
 the site dedicated to such a solution.

 It really is impossible to get consensus on the subject. I never
 needed more then our standard levels and every proposal for more shows 
 the
 confusion that no one is really clear where they belong.


 I think that with Ralphs list, we are getting a nice
 solution/evolution.

 The great thing about the new levels is that no one is forcing
 developers to use the new levels, feel free to ignore them! ;)

 As a user, it is very easy to throttle how much log events you get,
 change DEBUG to VERBOSE and you're done.

 OTOH, achieving the same effect with makers is more work IMO for
 developers and users. So I look at markers as the workaround to the 
 'levels
 are not fine enough for my app' problem. Saying use markers is not a 
 fair
 comparison to change the level, from a dev and user POV. Yes, it's a
 solution but a much heavier one.

 Gary


 On Jan 18, 2014 2:27 PM, Gary Gregory garydgreg...@gmail.com
 wrote:

 On Sat, Jan 18, 2014 at 2:35 PM, Nicholas Williams 
 nicho...@nicholaswilliams.net wrote:

 To be clear, here's how I see it (assuming we adopted all levels
 proposed):

 FATAL  ERROR  WARN  CONFIG  INFO  VERBOSE  DEBUG  FINE 
 TRACE.


 Interesting, I would have swapped CONFIG and INFO.

 Can you talk a little more why CONFIG  INFO (and not INFO 
 CONFIG)?  For me, I would use VERBOSE for configuration logging.

 Gary



 CONFIG would map to INFO for slf4j. VERBOSE and FINE would both map
 to DEBUG.

 My motivation for FINE was similar to your motivation for VERBOSE:
 DEBUG isn't quite enough. In retrospect, I agree more with you that
 something is needed more on the INFO side of DEBUG rather than the 
 TRACE
 side. That would allow DEBUG to be used for what it's really meant 
 for. So
 I'm fine with VERBOSE instead.

 My reason for putting CONFIG between INFO and WARN is simple: I
 ALWAYS want to see config-related messages when the application 
 starts, but
 I don't always want to see INFO messages after it starts. And if 
 something
 re-configures while the application is running, I want to see that, 
 too.
 I've developed the habit of logging startup messages as WARNings, 
 which I
 don't like doing.

 Hope that helps some.

 Nick

 Sent from my iPhone from the Las Vegas airport, so please forgive
 brief replies and frequent typos

 On Jan 18, 2014, at 11:21, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 STEP?  No clue what that means.

 Gary, if you want to implement VERBOSE between INFO and DEBUG I’m
 OK with that, but what will that map to in SLF4J, etc.  DEBUG?

 And yes, something on the web site should document our recommended
 usage for levels and markers.

 Ralph


 On Jan 18, 2014, at 10:53 AM, Gary Gregory garydgreg...@gmail.com
 wrote:

 Ah, my view of VERBOSE is that it is _more_ information, hence INFO
  VERBOSE  DEBUG; while it sounds like Ralphs sees it as more DEBUG 
 data.

  For me DEBUG data is going to be already verbose, even more than
 'verbose'.

 What is interesting (to me) is that DEBUG is often misused based on
 this basic mix: debug messages can be for users *and/or* for 
 developers,
 there is no distinction in the audience.

 For example, as a user, I want to get data to help me debug my
 configuration and my process. As a developer, I want to debug the code.
 These can be two very different set of data.

 But we do not have DEBUG_USER and DEBUG_DEV levels. I would see
 INFO next to VERBOSE as useful to users. Then DEBUG and TRACE useful 
 for
 developers. Each app can have its convention of course, but it would be
 nice to have the distinction available through levels for developers 
 to use.

 I see TRACE as method entry

Re: Question about Log4jServletFilter in core.

[Scott Deboy]

+1 for a minimal jar with the servlet support.
On Jan 18, 2014 9:36 AM, Ralph Goers ralph.go...@dslextreme.com wrote:

 I’ve always had reservations about the servlet 3.0 automatic configuration
 because if the log4j jar is present it can’t be disabled or be modified by
 the end user. We’ve had some issues with Spring initialization and now
 LOG4J2-452 reinforces that.  I would propose that if we want to keep it
 that we move the minimum amount required into its own jar so that users
 have a choice as to whether it is automatically initialized.

 Am I the only one who feels this way?  Frankly, this and one other issue I
 plan to work on this weekend are the only things I see as blockers for a GA
 release.

 Ralph

 On Jan 17, 2014, at 8:25 PM, Nick Williams nicho...@nicholaswilliams.net
 wrote:

 Filter initialization is one of the last things to happen in web app
 startup. The ServletContainerInitializer sets the threads logger context so
 that web app startup procedures can use it. The filter's init() method
 clears it near the end of startup so that it doesn't bleed into another web
 app.

 Then, on web apps shutdown, destruction of filters is one of the first
 things to happen. The filter's destroy() sets the logger context so that
 the web app shutdown procedures can use it.

 Nick

 On Jan 17, 2014, at 10:17 PM, Matt Sicker wrote:

 Now I'm not sure if I'm interpreting this correctly, but init() clears the
 current thread's logger context, and destroy() sets it. What's up with
 this? Especially since it just gets set and cleared in the doFilter() bit.

 --
 Matt Sicker boa...@gmail.com

Re: Web Issues, Logging Levels, and GA

[Scott Deboy]

Expression filter from log4j 1 already supports all of this and hasn't had
to change for years. Markers could be supported as a property with almost
zero work.
On Jan 18, 2014 2:52 PM, Gary Gregory garydgreg...@gmail.com wrote:

 On Sat, Jan 18, 2014 at 5:26 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:

 We could address that by allowing a Markers attribute in all the same
 places a level attribute is supported.  The only issue with that is that
 this would be very limited since there are more ways to use Markers.  For
 example specifying

 logger name=“org.apache.foo” level=“info” markers=“CONFIG,INIT”

 would mean that only events that meet the level criteria and have a
 CONFIG or INIT marker would be logged.

 On the other hand we could do

 logger name=“org.apache.foo” level=“info” expression=“Marker == CONFIG
 || Marker == INIT”

 All this would require is someone to implement an ExpressionFilter and
 then modifying logger to accept the expression attribute as a short hand
 way of calling it.


 Bleh, why not use JavaScript, it's baked in the JRE. Otherwise, this
 language risks to grow...

 Gary



 Ralph

 On Jan 18, 2014, at 2:12 PM, Nicholas Williams 
 nicho...@nicholaswilliams.net wrote:

 I prefer to avoid markers whenever possible. Unlike levels, markers
 require some amount of configuration to get them to log/not log when
 desired. They don't just work.

 N

 Sent from my iPhone from LAX baggage claim, so please forgive brief
 replies and frequent typos

 On Jan 18, 2014, at 14:01, Matt Sicker boa...@gmail.com wrote:

 Markers all around! No logging levels, just allow markers to have
 ordinals or bit-flags to allow more flexible filtering.

 Sorry, nothing useful to add beyond wild speculations.


 On 18 January 2014 15:15, Ralph Goers ralph.go...@dslextreme.com wrote:

 Actually, here is how I would prefer it.  Let’s see if it makes sense to
 anyone else.

 FATAL - Hopefully, almost never logged because the system is crashing.
 ERROR - Something affecting the usability of the system occurred.
 WARN - Something not nice, but probably recoverable occurred. May lead
 to errors later.
 INFO - Something of general interest, but not necessarily significant.
 DIAG or DIAGNOSTIC - Events that can be used by operations or users to
 diagnose problems in the system.
 DEBUG - Used by developers for internal debugging.
 VERBOSE - Used to log minute details of the system.  As its dictionary
 definition implies this is extremely chatty.
 TRACE - Adds tracing of method entry and exit, possibly object creation
 and initialization.

 I believe these should be enough for anybody.  I still think CONFIG is a
 Marker at the INFO level. The advantage of being a Marker is that it can be
 enabled regardless of its level and enabling it doesn’t imply enabling
 other levels.

 Ralph


 On Jan 18, 2014, at 1:03 PM, Gary Gregory garydgreg...@gmail.com
 wrote:

 On Sat, Jan 18, 2014 at 2:21 PM, Ralph Goers ralph.go...@dslextreme.com
  wrote:

 STEP?  No clue what that means.

 Gary, if you want to implement VERBOSE between INFO and DEBUG I’m OK
 with that, but what will that map to in SLF4J, etc.  DEBUG?


 Sounds OK, I can see it as debug data, but for users, instead of
 developers.

 Gary


 And yes, something on the web site should document our recommended
 usage for levels and markers.

 Ralph



 On Jan 18, 2014, at 10:53 AM, Gary Gregory garydgreg...@gmail.com
 wrote:

 Ah, my view of VERBOSE is that it is _more_ information, hence INFO 
 VERBOSE  DEBUG; while it sounds like Ralphs sees it as more DEBUG data.

  For me DEBUG data is going to be already verbose, even more than
 'verbose'.

 What is interesting (to me) is that DEBUG is often misused based on
 this basic mix: debug messages can be for users *and/or* for developers,
 there is no distinction in the audience.

 For example, as a user, I want to get data to help me debug my
 configuration and my process. As a developer, I want to debug the code.
 These can be two very different set of data.

 But we do not have DEBUG_USER and DEBUG_DEV levels. I would see INFO
 next to VERBOSE as useful to users. Then DEBUG and TRACE useful for
 developers. Each app can have its convention of course, but it would be
 nice to have the distinction available through levels for developers to 
 use.

 I see TRACE as method entry and exit type of logging, *very* *low*
 level stuff.

 We could also have both (ducking for projectiles):

 INFO
 VERBOSE
 DEBUG
 STEP
 TRACE

 Gary


 On Sat, Jan 18, 2014 at 12:47 PM, Ralph Goers 
 ralph.go...@dslextreme.com wrote:

 Oops. I just noticed you proposed that VERBOSE be between INFO and
 DEBUG. Now that I don’t understand. My experience is that VERBOSE is
 usually more detailed than debug messages, not less.

 Ralph

 On Jan 18, 2014, at 9:44 AM, Ralph Goers ralph.go...@dslextreme.com
 wrote:

 I understand the need for CONFIG.  However it isn’t clear to me
 whether it belongs between INFO and WARN or DEBUG and INFO.  That is
 

[jira] [Commented] (LOG4J2-467) Thread name caching in async logger incompatible with use of Thread.setName()

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862435#comment-13862435
 ] 

Scott Deboy commented on LOG4J2-467:


Here are my results from my Mac - two cached/two uncached runs.

CACHED

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,023,291 ops/sec. 
latency(ns): avg=4137.8 99%  16384.0 99.99%  2936012.8 (53351 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,542,271 ops/sec. 
latency(ns): avg=2588.6 99%  4505.6 99.99%  2097152.0 (368968 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,895,205 ops/sec. 
latency(ns): avg=2431.8 99%  4096.0 99.99%  2097152.0 (741385 samples)


Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,370,012 ops/sec. 
latency(ns): avg=4088.8 99%  16384.0 99.99%  3355443.2 (57130 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,602,343 ops/sec. 
latency(ns): avg=2448.9 99%  3686.4 99.99%  2097152.0 (406678 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,934,711 ops/sec. 
latency(ns): avg=2436.2 99%  4096.0 99.99%  2446677.3 (748575 samples)



UNCACHED:

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 6,818,683 ops/sec. 
latency(ns): avg=3747.8 99%  16384.0 99.99%  2936012.8 (64379 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,915,888 ops/sec. 
latency(ns): avg=2616.1 99%  4096.0 99.99%  2306867.2 (368855 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,911,439 ops/sec. 
latency(ns): avg=2464.6 99%  4096.0 99.99%  2097152.0 (737069 samples)

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,449,397 ops/sec. 
latency(ns): avg=3675.4 99%  16384.0 99.99%  2516582.4 (61476 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 4,031,314 ops/sec. 
latency(ns): avg=2578.6 99%  3481.6 99.99%  2516582.4 (388410 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 2,625,581 ops/sec. 
latency(ns): avg=2454.1 99%  4096.0 99.99%  2970965.3 (764774 samples)


 Thread name caching in async logger incompatible with use of Thread.setName()
 -

 Key: LOG4J2-467
 URL: https://issues.apache.org/jira/browse/LOG4J2-467
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta9
 Environment: Debian Squeeze amd64
 OpenJDK 7u25
Reporter: Anthony Baldocchi
Assignee: Remko Popma
 Fix For: 2.0-rc1

 Attachments: PerfTestDriver.java, PerfTestDriver.java


 AsyncLogger caches a thread's name in a thread-local info variable.  I make 
 use of a thread pool where the submitted Runnables call Thread.setName() at 
 the beginning of their task and the thread name is included in the log 
 message.  For an example of this behavior, see 
 org.jboss.netty.util.ThreadRenamingRunnable in Netty 3.x.  With the cached 
 thread name, the log messages will contain whatever name the thread had when 
 it logged for the first time and so long as the thread doesn't terminate 
 (such as in a core pool thread), all log messages involving this thread will 
 be erroneous.  If Thread.getName has a significant performance impact for 
 async logging, I would be satisfied if this behavior were configurable, 
 perhaps on a per-logger basis, so that the penalty only needs to be taken by 
 users who make use of Thread.setName()



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

-
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-467) Thread name caching in async logger incompatible with use of Thread.setName()

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862435#comment-13862435
 ] 

Scott Deboy edited comment on LOG4J2-467 at 1/4/14 10:55 PM:
-

Details about my machine:
java version 1.7.0_45
16 G memory
Mid 2012 Macbook Pro, 2.3 i7
Mavericks

Summary? Is it fair to say this is a 'push'? At least on my box it looks like 
it is (or uncached you could argue is slightly better)

Results:

CACHED

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,023,291 ops/sec. 
latency(ns): avg=4137.8 99%  16384.0 99.99%  2936012.8 (53351 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,542,271 ops/sec. 
latency(ns): avg=2588.6 99%  4505.6 99.99%  2097152.0 (368968 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,895,205 ops/sec. 
latency(ns): avg=2431.8 99%  4096.0 99.99%  2097152.0 (741385 samples)


Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,370,012 ops/sec. 
latency(ns): avg=4088.8 99%  16384.0 99.99%  3355443.2 (57130 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,602,343 ops/sec. 
latency(ns): avg=2448.9 99%  3686.4 99.99%  2097152.0 (406678 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,934,711 ops/sec. 
latency(ns): avg=2436.2 99%  4096.0 99.99%  2446677.3 (748575 samples)



UNCACHED:

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 6,818,683 ops/sec. 
latency(ns): avg=3747.8 99%  16384.0 99.99%  2936012.8 (64379 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,915,888 ops/sec. 
latency(ns): avg=2616.1 99%  4096.0 99.99%  2306867.2 (368855 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,911,439 ops/sec. 
latency(ns): avg=2464.6 99%  4096.0 99.99%  2097152.0 (737069 samples)

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,449,397 ops/sec. 
latency(ns): avg=3675.4 99%  16384.0 99.99%  2516582.4 (61476 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 4,031,314 ops/sec. 
latency(ns): avg=2578.6 99%  3481.6 99.99%  2516582.4 (388410 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 2,625,581 ops/sec. 
latency(ns): avg=2454.1 99%  4096.0 99.99%  2970965.3 (764774 samples)



was (Author: sdeboy):
Here are my results from my Mac - two cached/two uncached runs.

CACHED

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,023,291 ops/sec. 
latency(ns): avg=4137.8 99%  16384.0 99.99%  2936012.8 (53351 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,542,271 ops/sec. 
latency(ns): avg=2588.6 99%  4505.6 99.99%  2097152.0 (368968 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,895,205 ops/sec. 
latency(ns): avg=2431.8 99%  4096.0 99.99%  2097152.0 (741385 samples)


Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,370,012 ops/sec. 
latency(ns): avg=4088.8 99%  16384.0 99.99%  3355443.2 (57130 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,602,343 ops/sec. 
latency(ns): avg=2448.9 99%  3686.4 99.99%  2097152.0 (406678 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,934,711 ops/sec. 
latency(ns): avg=2436.2 99%  4096.0 99.99%  2446677.3 (748575 samples)



UNCACHED:

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 6,818,683 ops/sec. 
latency(ns): avg=3747.8 99%  16384.0 99.99%  2936012.8 (64379 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,915,888 ops/sec. 
latency(ns): avg=2616.1 99%  4096.0 99.99%  2306867.2 (368855 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,911,439 ops/sec. 
latency(ns): avg=2464.6 99%  4096.0 99.99%  2097152.0 (737069 samples)

Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,449,397 ops/sec. 
latency(ns): avg=3675.4 99%  16384.0 99.99%  2516582.4 (61476 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 4,031,314 ops/sec. 
latency(ns): avg=2578.6 99%  3481.6 99.99%  2516582.4 (388410 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 2,625,581 ops/sec. 
latency(ns): avg=2454.1 99%  4096.0 99.99%  2970965.3 (764774 samples)


 Thread name caching in async logger incompatible with use of Thread.setName()
 -

 Key: LOG4J2-467
 URL: https://issues.apache.org/jira/browse/LOG4J2-467
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta9
 Environment: Debian Squeeze amd64
 OpenJDK 7u25
Reporter: Anthony Baldocchi
Assignee: Remko Popma
 Fix For: 2.0-rc1

 Attachments: PerfTestDriver.java, PerfTestDriver.java


 AsyncLogger caches a thread's name in a thread-local info variable.  I make 
 use of a thread pool where the submitted

[jira] [Commented] (LOG4J2-467) Thread name caching in async logger incompatible with use of Thread.setName()

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862187#comment-13862187
 ] 

Scott Deboy commented on LOG4J2-467:


What should be the bottleneck in this test?  I ran this on my MBP and I see 
around 70% idle CPU, disk doesn't look like it's being thrashed.

 Thread name caching in async logger incompatible with use of Thread.setName()
 -

 Key: LOG4J2-467
 URL: https://issues.apache.org/jira/browse/LOG4J2-467
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta9
 Environment: Debian Squeeze amd64
 OpenJDK 7u25
Reporter: Anthony Baldocchi
Assignee: Remko Popma
 Fix For: 2.0-rc1

 Attachments: PerfTestDriver.java


 AsyncLogger caches a thread's name in a thread-local info variable.  I make 
 use of a thread pool where the submitted Runnables call Thread.setName() at 
 the beginning of their task and the thread name is included in the log 
 message.  For an example of this behavior, see 
 org.jboss.netty.util.ThreadRenamingRunnable in Netty 3.x.  With the cached 
 thread name, the log messages will contain whatever name the thread had when 
 it logged for the first time and so long as the thread doesn't terminate 
 (such as in a core pool thread), all log messages involving this thread will 
 be erroneous.  If Thread.getName has a significant performance impact for 
 async logging, I would be satisfied if this behavior were configurable, 
 perhaps on a per-logger basis, so that the penalty only needs to be taken by 
 users who make use of Thread.setName()



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LOG4J2-467) Thread name caching in async logger incompatible with use of Thread.setName()

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862199#comment-13862199
 ] 

Scott Deboy commented on LOG4J2-467:


The test fails part way through for me since it isn't resolving the slf4j 
classes: Exception in thread main java.lang.NoClassDefFoundError: 
org/slf4j/LoggerFactory

I am only getting through the single threaded tests before it fails.

Assume I need the slf4j API and an implementation?  What's the right command to 
get those included?

MBP means macbook pro..it's a mid 2012, 2.3 i7, SSD Samsung 840 pro w/16G, on 
Mavericks.  Once I have a good command to run I'll update the bug with results.

 Thread name caching in async logger incompatible with use of Thread.setName()
 -

 Key: LOG4J2-467
 URL: https://issues.apache.org/jira/browse/LOG4J2-467
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta9
 Environment: Debian Squeeze amd64
 OpenJDK 7u25
Reporter: Anthony Baldocchi
Assignee: Remko Popma
 Fix For: 2.0-rc1

 Attachments: PerfTestDriver.java


 AsyncLogger caches a thread's name in a thread-local info variable.  I make 
 use of a thread pool where the submitted Runnables call Thread.setName() at 
 the beginning of their task and the thread name is included in the log 
 message.  For an example of this behavior, see 
 org.jboss.netty.util.ThreadRenamingRunnable in Netty 3.x.  With the cached 
 thread name, the log messages will contain whatever name the thread had when 
 it logged for the first time and so long as the thread doesn't terminate 
 (such as in a core pool thread), all log messages involving this thread will 
 be erroneous.  If Thread.getName has a significant performance impact for 
 async logging, I would be satisfied if this behavior were configurable, 
 perhaps on a per-logger basis, so that the penalty only needs to be taken by 
 users who make use of Thread.setName()



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LOG4J2-467) Thread name caching in async logger incompatible with use of Thread.setName()

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862217#comment-13862217
 ] 

Scott Deboy commented on LOG4J2-467:


I'm not sure why, but I do get an slf4j error as you see above:

Logback: Sync (single thread) (1/5)...Exception in thread main 
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory



 Thread name caching in async logger incompatible with use of Thread.setName()
 -

 Key: LOG4J2-467
 URL: https://issues.apache.org/jira/browse/LOG4J2-467
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta9
 Environment: Debian Squeeze amd64
 OpenJDK 7u25
Reporter: Anthony Baldocchi
Assignee: Remko Popma
 Fix For: 2.0-rc1

 Attachments: PerfTestDriver.java


 AsyncLogger caches a thread's name in a thread-local info variable.  I make 
 use of a thread pool where the submitted Runnables call Thread.setName() at 
 the beginning of their task and the thread name is included in the log 
 message.  For an example of this behavior, see 
 org.jboss.netty.util.ThreadRenamingRunnable in Netty 3.x.  With the cached 
 thread name, the log messages will contain whatever name the thread had when 
 it logged for the first time and so long as the thread doesn't terminate 
 (such as in a core pool thread), all log messages involving this thread will 
 be erroneous.  If Thread.getName has a significant performance impact for 
 async logging, I would be satisfied if this behavior were configurable, 
 perhaps on a per-logger basis, so that the penalty only needs to be taken by 
 users who make use of Thread.setName()



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: Next release of 2.0

[Scott Deboy]

I think it makes sense to go through the existing bugs and find ones we
feel are critical and squash them before a final 2.0.

Gary's right in the sense that adoption as a non beta means we will feel
resistance to significant changes.

Maybe we should make it clear that Api changes may appear in 2.1 but not
2.0.x?
On Jan 2, 2014 7:23 PM, Gary Gregory garydgreg...@gmail.com wrote:

 On Thu, Jan 2, 2014 at 10:15 PM, Remko Popma remko.po...@gmail.comwrote:

 Frankly, Gary, I don't understand the hesitation.
 We started talking about a 2.0 GA release six months ago. Surely that
 should have been enough time to familiarize yourself with the APIs and
 raise any concerns.

 I understand that the 2.0 release is a big step but I also agree with
 Christian that if unforeseen issues come up we can address them in upcoming
 releases. (And if we find we've made a terrible mistake and need an API
 change, then so be it...)

 How about everyone marks outstanding Jira tickets that they really want
 to address before the 2.0 release (with the issue target version), and
 release the 2.0 GA when these are all fixed?


 Hey, it's a volunteer community process, and we all have our opinions ;) I
 just stated mine is all.

 Feel free to call a vote when you see fit. It's all good.

 Gary



 On Fri, Jan 3, 2014 at 3:47 AM, Remko Popma remko.po...@gmail.comwrote:

 What tweaks do you have in mind? API changes?


 On Fri, Jan 3, 2014 at 12:45 AM, Gary Gregory garydgreg...@gmail.comwrote:

 On Thu, Jan 2, 2014 at 10:27 AM, Christian Grobmeier 
 grobme...@gmail.com wrote:

 Why the caution?

 We can have a 3.0, a 2.1 and son on.

 Nobody expects we should stick forever with a version.
 On the other hand, we were releasing in beta for ages now.

 What are the reasons you don't want a 2.0 stable?


 You've got it backwards ;)

 I do want a stable 2.0. I, personally, am not 100% familiar with 100%
 of the API and I am not sure that the API is stable. There are a LOT of
 _public_ APIs in Log4J. Once 2.0 is out, these are set in stone.

 There are also a couple of tweaks I'd like to do. People are using
 log4j now in beta form. Another beta/rc will not hurt. But once 2.0 is out,
 we are set.

 Gary




 On 2 Jan 2014, at 14:04, Gary Gregory wrote:

  Make it RC or another beta IMO. Once 2.0 is out you cannot unhinged
 that bell.

 Gary

  Original message 
 From: Ralph Goers ralph.go...@dslextreme.com
 Date:01/02/2014  02:46  (GMT-05:00)
 To: Log4J Developers List log4j-dev@logging.apache.org
 Subject: Next release of 2.0

 I am trying to find a bit more time to work on Log4j again.  I see
 quite a few issues that I would like to address and think I will need 
 about
 2 weeks to complete them so I am tentatively targeting the middle of the
 month for the next release.   The question in my mind is whether the next
 release should be 2.0-RC1 or just 2.0.

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



 ---
 http://www.grobmeier.de
 The Zen Programmer: http://bit.ly/12lC6DL
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Apache Log4j Extras 1.2.17.1 based on RC1

[Scott Deboy]

I'm on Mac Mavericks, using:

java -version
java version 1.7.0_45
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
admin@spiff:~$


On 11/23/13, Gary Gregory garydgreg...@gmail.com wrote:
 On Sat, Nov 23, 2013 at 9:45 AM, Gary Gregory
 garydgreg...@gmail.comwrote:

 On Sat, Nov 23, 2013 at 9:34 AM, Benedikt Ritter
 brit...@apache.orgwrote:




 2013/11/23 Gary Gregory garydgreg...@gmail.com

 On Fri, Nov 22, 2013 at 8:09 AM, Benedikt Ritter
 brit...@apache.orgwrote:




 2013/11/21 Gary Gregory garydgreg...@gmail.com

 On Thu, Nov 21, 2013 at 3:18 PM, Benedikt Ritter
 brit...@apache.orgwrote:

 Hi guys,

 I currently don't have the time to do a full review of the RC (maybe
 tomorrow) but I built with:

 Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a;
 2013-09-17 17:22:22+0200)

 Maven home: /Applications/dev/maven/apache-maven-3.1.1

 Java version: 1.7.0_40, vendor: Oracle Corporation

 Java home:
 /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/jre

 Default locale: de_DE, platform encoding: UTF-8

 OS name: mac os x, version: 10.9, arch: x86_64, family: mac


 So it doesn't seem to be a Java 7 problem...


 Can you try with 1.7.0_45?


 No problems executing mvn test with:

 Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a;
 2013-09-17 17:22:22+0200)

 Maven home: /Applications/dev/maven/apache-maven-3.1.1

 Java version: 1.7.0_45, vendor: Oracle Corporation

 Java home:
 /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre

 Default locale: de_DE, platform encoding: UTF-8

 OS name: mac os x, version: 10.9, arch: x86_64, family: mac


 Maybe it's related to Windows? Anybody else who builds on Windows?


 It can't possibly be just me...


 Looks like only Scott has voted aside from you. Don't know which OS he
 uses. I currently really don't have the time to set up a virtual machine
 with Windows to make sure it is not related to Windows.


 For me, on Windows, it always shows some kind of failure in the XSLT test
 class on Oracle Java 7 but never on Oracle Java 6.

 It could be that the version of Xalan embedded in Java has changed
 between
 6 and 7. Or something else, like the execution order of the test method
 is
 different b/w Java 6 and 7.


 It might be interesting to test Java 8 EA.

 Gary


 Gary


 Benedikt




 Gary



 Benedikt




 Gary



 HTH

 Benedikt


 2013/11/21 Gary Gregory garydgreg...@gmail.com

 This is a Java 6 vs. Java 7 issue. When I try the same as above
 with
 Java 6, it works, but not on 7:

 Files [target/locationfiltered] and [witness/xml/xsltLayout.2]
 differ on line 4
 One reads:  [log4j:properties].
 Other reads:[/log4j:event].
 
 Contents of target/locationfiltered:
 1   : log4j:event xmlns:log4j=http://jakarta.apache.org/log4j/;
 logger=org.apache.log4j.xml.XSLTLayoutTestCase$X
 time=-MM-ddTHH:mm:ss.SSSZ timestamp=XXX level=INFO
 thread=main
 2   : log4j:messagein X() constructor/log4j:message
 3   : log4j:locationInfo
 class=org.apache.log4j.xml.XSLTLayoutTestCase$X
 method=lt;initgt;
 file=XSLTLayoutTestCase.java line=X/
 4   : log4j:properties
 5   : log4j:data name=key1 value=val1/
 6   : log4j:data name=key2 value=val2/
 7   : /log4j:properties
 8   : /log4j:event
 9   : log4j:event xmlns:log4j=http://jakarta.apache.org/log4j/;
 logger=org.apache.log4j.xml.XSLTLayoutTestCase
 time=-MM-ddTHH:mm:ss.SSSZ timestamp=XXX level=DEBUG
 thread=main
 10  : log4j:messageMessage 0/log4j:message
 11  : log4j:locationInfo
 class=org.apache.log4j.xml.XSLTLayoutTestCase method=common
 file=XSLTLayoutTestCase.java line=X/
 12  : log4j:properties
 13  : log4j:data name=key1 value=val1/
 14  : log4j:data name=key2 value=val2/
 15  : /log4j:properties
 16  : /log4j:event
 17  : log4j:event xmlns:log4j=http://jakarta.apache.org/log4j/;
 logger=root time=-MM-ddTHH:mm:ss.SSSZ timestamp=XXX
 level=DEBUG
 thread=main
 18  : log4j:messageMessage 0/log4j:message
 19  : log4j:locationInfo
 class=org.apache.log4j.xml.XSLTLayoutTestCase method=common
 file=XSLTLayoutTestCase.java line=X/
 20  : log4j:properties
 21  : log4j:data name=key1 value=val1/
 22  : log4j:data name=key2 value=val2/
 23  : /log4j:properties
 24  : /log4j:event
 25  : log4j:event xmlns:log4j=http://jakarta.apache.org/log4j/;
 logger=org.apache.log4j.xml.XSLTLayoutTestCase
 time=-MM-ddTHH:mm:ss.SSSZ timestamp=XXX level=INFO
 thread=main
 26  : log4j:messageMessage 1/log4j:message
 27  : log4j:locationInfo
 class=org.apache.log4j.xml.XSLTLayoutTestCase method=common
 file=XSLTLayoutTestCase.java line=X/
 28  : log4j:properties
 29  : log4j:data name=key1 value=val1/
 30  : log4j:data name=key2 value=val2/
 31  : /log4j:properties
 32  : /log4j:event
 33  : log4j:event xmlns:log4j=http://jakarta.apache.org/log4j/;
 logger=root time=-MM-ddTHH:mm:ss.SSSZ timestamp=XXX
 level=INFO
 thread=main
 34  : log4j:messageMessage 1/log4j:message
 35  : 

[jira] [Commented] (LOG4J2-447) XMLLayout does not include marker name

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830265#comment-13830265
 ] 

Scott Deboy commented on LOG4J2-447:


I don't think we already have a hamcrest dependency in our tests.

Would also need to document that the XMLlayout includes just the leaf marker 
name but not the hierarchy..

 XMLLayout does not include marker name
 --

 Key: LOG4J2-447
 URL: https://issues.apache.org/jira/browse/LOG4J2-447
 Project: Log4j 2
  Issue Type: Bug
  Components: Layouts
Affects Versions: 2.0-beta9
Reporter: Jeff Hudren
 Attachments: LOG4J2-447.patch


 Log4j2 supports the notion of markers, but this is not represented by the 
 XMLLayout.
 For example, using SerializedLayout with SocketAppender will send marker 
 information, but using XMLLayout with SocketAppender will not.
 It would be very helpful to have just the name of the leaf marker sent with 
 the log event, not the corresponding marker hierarchy.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: [VOTE] Release Apache Log4j Extras 1.2.17.1 based on RC1

[Scott Deboy]

+1 Everything looks good to me.

On 10/26/13, Jess Holle je...@ptc.com wrote:
 Is anyone going to vote on 1.2.17.1?

 I'll use this release in any case, but it would be nice if this was the
 latest public release in general.

 On 10/21/2013 9:26 AM, Christian Grobmeier wrote:
 On 21 Oct 2013, at 15:28, Jess Holle wrote:

 Packaging now looks good at a glance as I now see no duplication.

 I don't own the code in our application that actually uses this, nor
 even know where the test cases are, however -- plus my vote doesn't
 actually count anyway -- so I'll leave that to others.

 Maybe your vote is not binding but its still important!
 Thanks for looking into it!


 On 10/21/2013 3:20 AM, Christian Grobmeier wrote:
 Hello

 please vote to release Apache Log4j Extras 1.2.17.1.

 Site:
 http://people.apache.org/~grobmeier/extras-12171
 (download path will be corrected at release time)

 Artifacts:
 https://repository.apache.org/content/repositories/orgapachelogging-007/log4j/apache-log4j-extras/1.2.17.1/



 (please note: I worked more closely to the Log4j2 release guide. All
 artifacts are on the repository server,
 including the previously damaged -bin artifact. Only -src and -bin
 artifacts will be linked from the website later)

 You can easily download all artifacts using this command:

 wget -e robots=off --cut-dirs=3 -r -p -np --no-check-certificate
 https://repository.apache.org/content/repositories/orgapachelogging-007/log4j/apache-log4j-extras/1.2.17.1/

 Source tag:
 http://svn.apache.org/repos/asf/logging/log4j/companions/extras/tags/apache-log4j-extras-1.2.17.1/



 Changes to 1.2.17:

 The -bin artifact still contained duplicated classes, while the -src
 artifact did not. This version removes
 the duplicated classes from the artifact.

 Please cast your vote:

 [ ] +1, release
 [ ] -1, do not release, because

 Thanks,
 Christian


 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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


 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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: [ANNOUNCEMENT] Apache Log4j Extras 1.2.17 released

[Scott Deboy]

It's here:

https://logging.apache.org/log4j/extras/download.html

FYI, the main page links 'extras' to the above.

Looks like we need to nuke the other site..

On 10/20/13, Gary Gregory garydgreg...@gmail.com wrote:
 Hi All:

 I see the 1.1 site here:
 https://logging.apache.org/log4j/companions/extras/download.html

 Where is the 1.2.17 site?

 Gary


 On Sun, Oct 20, 2013 at 3:06 PM, Jess Holle je...@ptc.com wrote:

 So I just downloaded apache-log4j-extras-1.2.17-**bin.zip, pulled out
 apache-log4j-extras-1.2.17.**jar, and took a peek.

 Straight away, I notice org/apache/log4j/Appender.**class -- and other
 duplicate classes.

 I will admit I should have examined the release candidate, but I didn't
 think the double-check this -- as the issue seems clear enough.  Yet the
 classes seem to be duplicated once again.


 On 10/20/2013 3:24 AM, Christian Grobmeier wrote:

 The Apache Log4j 1 team is pleased to announce the release of Apache
 Log4j Extras 1.2.17.

 Apache Extras™ for Apache log4j™ is a jar file full of additional
 functionality for log4j 1.2.x.

 This release is a maintenance release.

 Changes:

 - Version naming changed to match the required log4j version.
 - RollingFileAppender with TimeBasedRolling policy doesn't create
 parent-path if FileNamePattern contains date pattern as directory
 (thanks
 to Daniel Stankiewicz) Fixes 53536.
 - DBAppender has a compile error (thanks to Antonio Petrelli) Fixes
 53645.
 - Prefixed FormattingInfo and PatternParser with Extras to avoid
 classloading conflict
 - Fixed product naming
 - Removed duplicated classes (thanks to Jess Holle for spotting it)
 - Removed ant build
 - Made tests writing to target folder
 - Merged all companions into the extras companion
 - Switched Parent to Apache parent Fixes 47595.
 - Upgraded to Apache Maven 3

 Apache Log4j Extras 1.2.17 required Java  1.4.2 and Log4j 1.2.17.

 For more information please visit the product website:

 http://logging.apache.org/**log4j/extrashttp://logging.apache.org/log4j/extras

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




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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: [ANNOUNCEMENT] Apache Log4j Extras 1.2.17 released

[Scott Deboy]

Yes, it looks like something went a bit sideways with the -bin jar.
The source jar is correct (no Appender class), but the -bin jar does
have the additional classes in it.

Scott

On 10/20/13, Jess Holle je...@ptc.com wrote:
 So I just downloaded apache-log4j-extras-1.2.17-bin.zip, pulled out
 apache-log4j-extras-1.2.17.jar, and took a peek.

 Straight away, I notice org/apache/log4j/Appender.class -- and other
 duplicate classes.

 I will admit I should have examined the release candidate, but I didn't
 think the double-check this -- as the issue seems clear enough.  Yet the
 classes seem to be duplicated once again.

 On 10/20/2013 3:24 AM, Christian Grobmeier wrote:
 The Apache Log4j 1 team is pleased to announce the release of Apache
 Log4j Extras 1.2.17.

 Apache Extras™ for Apache log4j™ is a jar file full of additional
 functionality for log4j 1.2.x.

 This release is a maintenance release.

 Changes:

 - Version naming changed to match the required log4j version.
 - RollingFileAppender with TimeBasedRolling policy doesn't create
 parent-path if FileNamePattern contains date pattern as directory
 (thanks to Daniel Stankiewicz) Fixes 53536.
 - DBAppender has a compile error (thanks to Antonio Petrelli) Fixes
 53645.
 - Prefixed FormattingInfo and PatternParser with Extras to avoid
 classloading conflict
 - Fixed product naming
 - Removed duplicated classes (thanks to Jess Holle for spotting it)
 - Removed ant build
 - Made tests writing to target folder
 - Merged all companions into the extras companion
 - Switched Parent to Apache parent Fixes 47595.
 - Upgraded to Apache Maven 3

 Apache Log4j Extras 1.2.17 required Java  1.4.2 and Log4j 1.2.17.

 For more information please visit the product website:

 http://logging.apache.org/log4j/extras

 -
 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: [ANNOUNCEMENT] Apache Log4j Extras 1.2.17 released

[Scott Deboy]

I think this may be related to these two lines in assembly/bin.xml:

directorytarget/directory
outputDirectory./outputDirectory

Scott

On 10/20/13, Christian Grobmeier grobme...@gmail.com wrote:
 (dropping other lists than log4j-dev)

 Wow, this is weird. So far I have no idea how the Appender.class made it
 its way into the -bin artifact.
 I will investigate this… any ideas on the error are welcome.



 On 20 Oct 2013, at 21:31, Scott Deboy wrote:

 Yes, it looks like something went a bit sideways with the -bin jar.
 The source jar is correct (no Appender class), but the -bin jar does
 have the additional classes in it.

 Scott

 On 10/20/13, Jess Holle je...@ptc.com wrote:
 So I just downloaded apache-log4j-extras-1.2.17-bin.zip, pulled out
 apache-log4j-extras-1.2.17.jar, and took a peek.

 Straight away, I notice org/apache/log4j/Appender.class -- and other
 duplicate classes.

 I will admit I should have examined the release candidate, but I
 didn't
 think the double-check this -- as the issue seems clear enough.  Yet
 the
 classes seem to be duplicated once again.

 On 10/20/2013 3:24 AM, Christian Grobmeier wrote:
 The Apache Log4j 1 team is pleased to announce the release of Apache
 Log4j Extras 1.2.17.

 Apache Extras™ for Apache log4j™ is a jar file full of
 additional
 functionality for log4j 1.2.x.

 This release is a maintenance release.

 Changes:

 - Version naming changed to match the required log4j version.
 - RollingFileAppender with TimeBasedRolling policy doesn't create
 parent-path if FileNamePattern contains date pattern as directory
 (thanks to Daniel Stankiewicz) Fixes 53536.
 - DBAppender has a compile error (thanks to Antonio Petrelli) Fixes
 53645.
 - Prefixed FormattingInfo and PatternParser with Extras to avoid
 classloading conflict
 - Fixed product naming
 - Removed duplicated classes (thanks to Jess Holle for spotting it)
 - Removed ant build
 - Made tests writing to target folder
 - Merged all companions into the extras companion
 - Switched Parent to Apache parent Fixes 47595.
 - Upgraded to Apache Maven 3

 Apache Log4j Extras 1.2.17 required Java  1.4.2 and Log4j 1.2.17.

 For more information please visit the product website:

 http://logging.apache.org/log4j/extras

 -
 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


 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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: [ANNOUNCEMENT] Apache Log4j Extras 1.2.17 released

[Scott Deboy]

I can try to work on it later today..will send something if I get the chance.

Scott

On 10/20/13, Christian Grobmeier grobme...@gmail.com wrote:
 Gladly taking a patch.

 Otherwise I will try to fix it myself and cut a new version 1.2.17.1
 soon (this week)


 On 20 Oct 2013, at 21:45, Jess Holle wrote:

 Do note that the Maven build includes all the duplicates -- I just
 checked.

 Thus the issue is with the build configuration.

 On 10/20/2013 2:33 PM, Gary Gregory wrote:
 On Sun, Oct 20, 2013 at 3:31 PM, Scott Deboy scott.de...@gmail.com
 mailto:scott.de...@gmail.com wrote:

 Yes, it looks like something went a bit sideways with the -bin jar.
 The source jar is correct (no Appender class), but the -bin jar does
 have the additional classes in it.


 Well, let's not kick ourselves too long. Who wants to cut a 1.2.17.1?

 Gary


 Scott

 On 10/20/13, Jess Holle je...@ptc.com mailto:je...@ptc.com wrote:
  So I just downloaded apache-log4j-extras-1.2.17-bin.zip, pulled out
  apache-log4j-extras-1.2.17.jar, and took a peek.
 
  Straight away, I notice org/apache/log4j/Appender.class -- and
 other
  duplicate classes.
 
  I will admit I should have examined the release candidate, but I
 didn't
  think the double-check this -- as the issue seems clear enough.
  Yet the
  classes seem to be duplicated once again.
 
  On 10/20/2013 3:24 AM, Christian Grobmeier wrote:
  The Apache Log4j 1 team is pleased to announce the release of
 Apache
  Log4j Extras 1.2.17.
 
  Apache Extras™ for Apache log4j™ is a jar file full of
 additional
  functionality for log4j 1.2.x.
 
  This release is a maintenance release.
 
  Changes:
 
  - Version naming changed to match the required log4j version.
  - RollingFileAppender with TimeBasedRolling policy doesn't create
  parent-path if FileNamePattern contains date pattern as directory
  (thanks to Daniel Stankiewicz) Fixes 53536.
  - DBAppender has a compile error (thanks to Antonio Petrelli)
 Fixes
  53645.
  - Prefixed FormattingInfo and PatternParser with Extras to avoid
  classloading conflict
  - Fixed product naming
  - Removed duplicated classes (thanks to Jess Holle for spotting
 it)
  - Removed ant build
  - Made tests writing to target folder
  - Merged all companions into the extras companion
  - Switched Parent to Apache parent Fixes 47595.
  - Upgraded to Apache Maven 3
 
  Apache Log4j Extras 1.2.17 required Java  1.4.2 and Log4j 1.2.17.
 
  For more information please visit the product website:
 
  http://logging.apache.org/log4j/extras
 
 
 -
  To unsubscribe, e-mail:
 log4j-dev-unsubscr...@logging.apache.org
 mailto:log4j-dev-unsubscr...@logging.apache.org
  For additional commands, e-mail:
 log4j-dev-h...@logging.apache.org
 mailto:log4j-dev-h...@logging.apache.org
 
 
 
 
 
 -
  To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
 mailto:log4j-dev-unsubscr...@logging.apache.org
  For additional commands, e-mail:
 log4j-dev-h...@logging.apache.org
 mailto:log4j-dev-h...@logging.apache.org
 
 

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




 --
 E-Mail: garydgreg...@gmail.com mailto:garydgreg...@gmail.com |
 ggreg...@apache.org mailto:ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 http://garygregory.wordpress.com/
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory


 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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: [ANNOUNCEMENT] Apache Log4j Extras 1.2.17 released

[Scott Deboy]

I think I fixed it in commit 1534007.

Extras is no longer a 'bundle'.

Scott

On 10/20/13, Christian Grobmeier grobme...@gmail.com wrote:
 On 20 Oct 2013, at 21:29, Gary Gregory wrote:

 On Sun, Oct 20, 2013 at 3:26 PM, Scott Deboy scott.de...@gmail.com
 wrote:

 It's here:

 https://logging.apache.org/log4j/extras/download.html

 FYI, the main page links 'extras' to the above.

 Looks like we need to nuke the other site..


 Yes, please, it's confusing.

 I did that.

 This: https://logging.apache.org/log4j/companions/
 now links to the extras page directly

 Thanks!



 Gary



 On 10/20/13, Gary Gregory garydgreg...@gmail.com wrote:
 Hi All:

 I see the 1.1 site here:
 https://logging.apache.org/log4j/companions/extras/download.html

 Where is the 1.2.17 site?

 Gary


 On Sun, Oct 20, 2013 at 3:06 PM, Jess Holle je...@ptc.com wrote:

 So I just downloaded apache-log4j-extras-1.2.17-**bin.zip, pulled
 out
 apache-log4j-extras-1.2.17.**jar, and took a peek.

 Straight away, I notice org/apache/log4j/Appender.**class -- and
 other
 duplicate classes.

 I will admit I should have examined the release candidate, but I
 didn't
 think the double-check this -- as the issue seems clear enough.
 Yet the
 classes seem to be duplicated once again.


 On 10/20/2013 3:24 AM, Christian Grobmeier wrote:

 The Apache Log4j 1 team is pleased to announce the release of
 Apache
 Log4j Extras 1.2.17.

 Apache Extras™ for Apache log4j™ is a jar file full of
 additional
 functionality for log4j 1.2.x.

 This release is a maintenance release.

 Changes:

 - Version naming changed to match the required log4j version.
 - RollingFileAppender with TimeBasedRolling policy doesn't create
 parent-path if FileNamePattern contains date pattern as directory
 (thanks
 to Daniel Stankiewicz) Fixes 53536.
 - DBAppender has a compile error (thanks to Antonio Petrelli)
 Fixes
 53645.
 - Prefixed FormattingInfo and PatternParser with Extras to avoid
 classloading conflict
 - Fixed product naming
 - Removed duplicated classes (thanks to Jess Holle for spotting
 it)
 - Removed ant build
 - Made tests writing to target folder
 - Merged all companions into the extras companion
 - Switched Parent to Apache parent Fixes 47595.
 - Upgraded to Apache Maven 3

 Apache Log4j Extras 1.2.17 required Java  1.4.2 and Log4j 1.2.17.

 For more information please visit the product website:

 http://logging.apache.org/**log4j/extras
 http://logging.apache.org/log4j/extras


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





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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory


 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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: [ANNOUNCEMENT] Apache Log4j Extras 1.2.17 released

[Scott Deboy]

Gah I committed that on the tag..

sigh..

Sorry

On 10/20/13, Scott Deboy scott.de...@gmail.com wrote:
 I think I fixed it in commit 1534007.

 Extras is no longer a 'bundle'.

 Scott

 On 10/20/13, Christian Grobmeier grobme...@gmail.com wrote:
 On 20 Oct 2013, at 21:29, Gary Gregory wrote:

 On Sun, Oct 20, 2013 at 3:26 PM, Scott Deboy scott.de...@gmail.com
 wrote:

 It's here:

 https://logging.apache.org/log4j/extras/download.html

 FYI, the main page links 'extras' to the above.

 Looks like we need to nuke the other site..


 Yes, please, it's confusing.

 I did that.

 This: https://logging.apache.org/log4j/companions/
 now links to the extras page directly

 Thanks!



 Gary



 On 10/20/13, Gary Gregory garydgreg...@gmail.com wrote:
 Hi All:

 I see the 1.1 site here:
 https://logging.apache.org/log4j/companions/extras/download.html

 Where is the 1.2.17 site?

 Gary


 On Sun, Oct 20, 2013 at 3:06 PM, Jess Holle je...@ptc.com wrote:

 So I just downloaded apache-log4j-extras-1.2.17-**bin.zip, pulled
 out
 apache-log4j-extras-1.2.17.**jar, and took a peek.

 Straight away, I notice org/apache/log4j/Appender.**class -- and
 other
 duplicate classes.

 I will admit I should have examined the release candidate, but I
 didn't
 think the double-check this -- as the issue seems clear enough.
 Yet the
 classes seem to be duplicated once again.


 On 10/20/2013 3:24 AM, Christian Grobmeier wrote:

 The Apache Log4j 1 team is pleased to announce the release of
 Apache
 Log4j Extras 1.2.17.

 Apache Extras™ for Apache log4j™ is a jar file full of
 additional
 functionality for log4j 1.2.x.

 This release is a maintenance release.

 Changes:

 - Version naming changed to match the required log4j version.
 - RollingFileAppender with TimeBasedRolling policy doesn't create
 parent-path if FileNamePattern contains date pattern as directory
 (thanks
 to Daniel Stankiewicz) Fixes 53536.
 - DBAppender has a compile error (thanks to Antonio Petrelli)
 Fixes
 53645.
 - Prefixed FormattingInfo and PatternParser with Extras to avoid
 classloading conflict
 - Fixed product naming
 - Removed duplicated classes (thanks to Jess Holle for spotting
 it)
 - Removed ant build
 - Made tests writing to target folder
 - Merged all companions into the extras companion
 - Switched Parent to Apache parent Fixes 47595.
 - Upgraded to Apache Maven 3

 Apache Log4j Extras 1.2.17 required Java  1.4.2 and Log4j 1.2.17.

 For more information please visit the product website:

 http://logging.apache.org/**log4j/extras
 http://logging.apache.org/log4j/extras


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





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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory


 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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: [ANNOUNCEMENT] Apache Log4j Extras 1.2.17 released

[Scott Deboy]

Reverted...but I see we have -18-snapshot in the pom now..I'll just
remove the bundle packaging entry on trunk..Christian, would you mind
rolling a 1.2.17.1 RC?

Scott

On 10/20/13, Scott Deboy scott.de...@gmail.com wrote:
 Gah I committed that on the tag..

 sigh..

 Sorry

 On 10/20/13, Scott Deboy scott.de...@gmail.com wrote:
 I think I fixed it in commit 1534007.

 Extras is no longer a 'bundle'.

 Scott

 On 10/20/13, Christian Grobmeier grobme...@gmail.com wrote:
 On 20 Oct 2013, at 21:29, Gary Gregory wrote:

 On Sun, Oct 20, 2013 at 3:26 PM, Scott Deboy scott.de...@gmail.com
 wrote:

 It's here:

 https://logging.apache.org/log4j/extras/download.html

 FYI, the main page links 'extras' to the above.

 Looks like we need to nuke the other site..


 Yes, please, it's confusing.

 I did that.

 This: https://logging.apache.org/log4j/companions/
 now links to the extras page directly

 Thanks!



 Gary



 On 10/20/13, Gary Gregory garydgreg...@gmail.com wrote:
 Hi All:

 I see the 1.1 site here:
 https://logging.apache.org/log4j/companions/extras/download.html

 Where is the 1.2.17 site?

 Gary


 On Sun, Oct 20, 2013 at 3:06 PM, Jess Holle je...@ptc.com wrote:

 So I just downloaded apache-log4j-extras-1.2.17-**bin.zip, pulled
 out
 apache-log4j-extras-1.2.17.**jar, and took a peek.

 Straight away, I notice org/apache/log4j/Appender.**class -- and
 other
 duplicate classes.

 I will admit I should have examined the release candidate, but I
 didn't
 think the double-check this -- as the issue seems clear enough.
 Yet the
 classes seem to be duplicated once again.


 On 10/20/2013 3:24 AM, Christian Grobmeier wrote:

 The Apache Log4j 1 team is pleased to announce the release of
 Apache
 Log4j Extras 1.2.17.

 Apache Extras™ for Apache log4j™ is a jar file full of
 additional
 functionality for log4j 1.2.x.

 This release is a maintenance release.

 Changes:

 - Version naming changed to match the required log4j version.
 - RollingFileAppender with TimeBasedRolling policy doesn't create
 parent-path if FileNamePattern contains date pattern as directory
 (thanks
 to Daniel Stankiewicz) Fixes 53536.
 - DBAppender has a compile error (thanks to Antonio Petrelli)
 Fixes
 53645.
 - Prefixed FormattingInfo and PatternParser with Extras to avoid
 classloading conflict
 - Fixed product naming
 - Removed duplicated classes (thanks to Jess Holle for spotting
 it)
 - Removed ant build
 - Made tests writing to target folder
 - Merged all companions into the extras companion
 - Switched Parent to Apache parent Fixes 47595.
 - Upgraded to Apache Maven 3

 Apache Log4j Extras 1.2.17 required Java  1.4.2 and Log4j 1.2.17.

 For more information please visit the product website:

 http://logging.apache.org/**log4j/extras
 http://logging.apache.org/log4j/extras


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





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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory


 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

 -
 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: [VOTE] Release apache-log4j-extras-1.2.17 RC3

[Scott Deboy]

+1

Checked the website, JavaDoc, LICENSE and NOTICE, hashes, built it
with mvn package and tested the dist artifact with Chainsaw, all look
good.

Thanks for your help Christian!

Scott

On 10/14/13, Christian Grobmeier grobme...@gmail.com wrote:
 Dear all,

 this is a vote for a new Apache Extras package.

 Changes to RC2:
   * created a source package
   * download packages are not in maven anymore
   * fixed version number in changes

 Changes to RC1:
   * removed duplicate classes
   * switched to release number 1.2.17 (same release as log4j)
   * JavaDoc has been regenerated with Java 7 Update 25 (bypassing
 security problem)
   * renamed product to extras at all places

 Changes:
   * all companions have been merged into the extras companion
   * pom does inherit from parent pom
   * testoutput now goes to /target
   * ant build has been removed
   * makes now use of Maven 3

 The website can be found here:

   * http://people.apache.org/~grobmeier/extras-site/

 Note: I might need to update the path for the download.

 Artifacts for Maven:

   *
 https://repository.apache.org/content/repositories/orgapachelogging-168/

 They can be downloaded with:

   * wget -e robots=off --cut-dirs=3 -r -p -np --no-check-certificate
 https://repository.apache.org/content/repositories/orgapachelogging-168/

 Artifacts for the website and for the ASF dist svn:

   * http://people.apache.org/~grobmeier/extras-artifacts/

 SVN tag:

   *
 http://svn.apache.org/repos/asf/logging/log4j/companions/extras/tags/apache-log4j-extras-1.2.17/

 Please cast your vote:

 [ ] +1
 [ ] -1, because...

 Vote will be open for the usual 72 hours at least.

 Thanks,
 Christian

 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB

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

Re: Verbose logging level

[Scott Deboy]

If your examples included loggers I think it would show these added verbose
entries would be another logger at INFO but not a separate severity.

I think of levels in terms of relative numeric severity. DEBUG  INFO WARN
ERROR etc.  Chainsaw supports this kind of logic in filtering colorizing
and searching for events.

Where would verbose go? I would put it below DEBUG myself.

Btw this advice to use another logger in most cases doesn't mean there
aren't cases where additional levels aren't useful.

Just something to think about.

Scott
On Oct 7, 2013 7:30 PM, Gary Gregory garydgreg...@gmail.com wrote:

 Hi All:

 I've just come across the need for distinguishing log entries somewhat
 between what INFO and DEBUG provide.

 I think of the DEBUG level as a watermark where data is provided for
 developers and support to do deep debugging. INFO is for users. But I see
 the need now for providing an easy way to give user more information (hence
 VERBOSE or another word) which is not at the DEBUG level of detail.

 Ideally, I'd like this in INFO mode:

 INFO Reading configuration
 INFO Running server

 Then in a new VERBOSE mode:

 INFO Reading configuration
 VERBOSE Reading accounts
 VERBOSE Reading this config data
 VERBOSE Reading that config data
 VERBOSE Reading other config data
 INFO Running server

 The in DEBUG mode, you'd get all the things that are real debug
 information like

 DEBUG Configuration location was not provided on the command line.
 DEBUG Searching classpath for configuration: cp entries
 DEBUG Searching user home for configuration: c:\users\...
 DEBUG Found configuration at location xzy, last modified date: ...
 INFO Reading configuration

 Thoughts?

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (LOG4J2-393) Low initialization performance when using Log4J with jar packages

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13763772#comment-13763772
 ] 

Scott Deboy commented on LOG4J2-393:


Sounds good - I recall we had a conversation on the fact that there should be a 
single advertiser for the entire configuration.  As long as this fits that 
model, it works for me.  I assume the advertiser test will be updated as well 
when you're done?

 Low initialization performance when using Log4J with jar packages
 -

 Key: LOG4J2-393
 URL: https://issues.apache.org/jira/browse/LOG4J2-393
 Project: Log4j 2
  Issue Type: Bug
  Components: Configurators, Core
Affects Versions: 2.0-beta8
Reporter: Philipp Hedwig
  Labels: performance

 We discovered a huge performance difference when initializing Log4J with 
 deployed jar packages compared to using it directly with normal class files.
 As it seems,
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInJar_
 is way slower than its counterpart
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInDirectory_
 and since this method gets called a few hundred times at initialization in 
 this project, initialization of Log4J took more than 2 minutes with jar 
 packages, compared to a few seconds with class files.
 The performance issue was already mentioned in 
 [LOG4J2-184|https://issues.apache.org/jira/browse/LOG4J2-184], only without 
 the jar problem.
 The solution to [LOG4J2-175|https://issues.apache.org/jira/browse/LOG4J2-175] 
 might cause this, but we are unsure why the methods exactly get called this 
 often.
 I just can tell that
 _org.apache.logging.log4j.core.config.plugins.PluginManager#collectPlugins()_ 
 gets called VERY often via
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_, 
 which gets called by
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
 And _collectPlugins()_ is remapped to _collectPlugins(boolean preLoad, final 
 String pkgs)_ with _collectPlugins(true, null);_. I'm unsure what this 
 preLoad is for, since it gets overridden with false and apparently no kind of 
 caching is used. In this method, _resolver.findInPackage(test, pkg);_ takes a 
 whole lot of time searching within the jars, as described in the beginning.
 The only way to work around this was for us to extract the custom appender in 
 a sperate ant build target, and with this in a seperate jar, to minimize the 
 size of the jar, reducing the search time.
 Can you cache things and maybe reduce the calls to _collectPlugins()_? I 
 don't see the probability of changing plugins during initialization as 
 described in LOG4J2-175 or the comment in 
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_.
 Introducing a variable for the plugin manager within the for loop in 
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_ 
 might be a good idea!

--
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-393) Low initialization performance when using Log4J with jar packages

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759260#comment-13759260
 ] 

Scott Deboy commented on LOG4J2-393:


I believe this behavior changed when I needed to add the ability to add a test 
for the advertiser mechanism, which added a new package, and the new advertiser 
wasn't discovered until this logic was changed.

 Low initialization performance when using Log4J with jar packages
 -

 Key: LOG4J2-393
 URL: https://issues.apache.org/jira/browse/LOG4J2-393
 Project: Log4j 2
  Issue Type: Bug
  Components: Configurators, Core
Affects Versions: 2.0-beta8
Reporter: Philipp Hedwig
  Labels: performance

 We discovered a huge performance difference when initializing Log4J with 
 deployed jar packages compared to using it directly with normal class files.
 As it seems,
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInJar_
 is way slower than its counterpart
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInDirectory_
 and since this method gets called a few hundred times at initialization in 
 this project, initialization of Log4J took more than 2 minutes with jar 
 packages, compared to a few seconds with class files.
 The performance issue was already mentioned in 
 [LOG4J2-184|https://issues.apache.org/jira/browse/LOG4J2-184], only without 
 the jar problem.
 The solution to [LOG4J2-175|https://issues.apache.org/jira/browse/LOG4J2-175] 
 might cause this, but we are unsure why the methods exactly get called this 
 often.
 I just can tell that
 _org.apache.logging.log4j.core.config.plugins.PluginManager#collectPlugins()_ 
 gets called VERY often via
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_, 
 which gets called by
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
 And _collectPlugins()_ is remapped to _collectPlugins(boolean preLoad, final 
 String pkgs)_ with _collectPlugins(true, null);_. I'm unsure what this 
 preLoad is for, since it gets overridden with false and apparently no kind of 
 caching is used. In this method, _resolver.findInPackage(test, pkg);_ takes a 
 whole lot of time searching within the jars, as described in the beginning.
 The only way to work around this was for us to extract the custom appender in 
 a sperate ant build target, and with this in a seperate jar, to minimize the 
 size of the jar, reducing the search time.
 Can you cache things and maybe reduce the calls to _collectPlugins()_? I 
 don't see the probability of changing plugins during initialization as 
 described in LOG4J2-175 or the comment in 
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_.
 Introducing a variable for the plugin manager within the for loop in 
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_ 
 might be a good idea!

--
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-393) Low initialization performance when using Log4J with jar packages

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759281#comment-13759281
 ] 

Scott Deboy commented on LOG4J2-393:


This isn't advertiser-specific.  I don't believe we had tests exercising 
lookups from additional config-defined packages, otherwise they would have 
failed as well.

 Low initialization performance when using Log4J with jar packages
 -

 Key: LOG4J2-393
 URL: https://issues.apache.org/jira/browse/LOG4J2-393
 Project: Log4j 2
  Issue Type: Bug
  Components: Configurators, Core
Affects Versions: 2.0-beta8
Reporter: Philipp Hedwig
  Labels: performance

 We discovered a huge performance difference when initializing Log4J with 
 deployed jar packages compared to using it directly with normal class files.
 As it seems,
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInJar_
 is way slower than its counterpart
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInDirectory_
 and since this method gets called a few hundred times at initialization in 
 this project, initialization of Log4J took more than 2 minutes with jar 
 packages, compared to a few seconds with class files.
 The performance issue was already mentioned in 
 [LOG4J2-184|https://issues.apache.org/jira/browse/LOG4J2-184], only without 
 the jar problem.
 The solution to [LOG4J2-175|https://issues.apache.org/jira/browse/LOG4J2-175] 
 might cause this, but we are unsure why the methods exactly get called this 
 often.
 I just can tell that
 _org.apache.logging.log4j.core.config.plugins.PluginManager#collectPlugins()_ 
 gets called VERY often via
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_, 
 which gets called by
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
 And _collectPlugins()_ is remapped to _collectPlugins(boolean preLoad, final 
 String pkgs)_ with _collectPlugins(true, null);_. I'm unsure what this 
 preLoad is for, since it gets overridden with false and apparently no kind of 
 caching is used. In this method, _resolver.findInPackage(test, pkg);_ takes a 
 whole lot of time searching within the jars, as described in the beginning.
 The only way to work around this was for us to extract the custom appender in 
 a sperate ant build target, and with this in a seperate jar, to minimize the 
 size of the jar, reducing the search time.
 Can you cache things and maybe reduce the calls to _collectPlugins()_? I 
 don't see the probability of changing plugins during initialization as 
 described in LOG4J2-175 or the comment in 
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_.
 Introducing a variable for the plugin manager within the for loop in 
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_ 
 might be a good idea!

--
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-393) Low initialization performance when using Log4J with jar packages

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759278#comment-13759278
 ] 

Scott Deboy commented on LOG4J2-393:


Test:
https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/test/java/org/apache/logging/log4j/core/config/AdvertiserTest.java

Associated xml config file:
https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/test/resources/log4j-advertiser.xml

 Low initialization performance when using Log4J with jar packages
 -

 Key: LOG4J2-393
 URL: https://issues.apache.org/jira/browse/LOG4J2-393
 Project: Log4j 2
  Issue Type: Bug
  Components: Configurators, Core
Affects Versions: 2.0-beta8
Reporter: Philipp Hedwig
  Labels: performance

 We discovered a huge performance difference when initializing Log4J with 
 deployed jar packages compared to using it directly with normal class files.
 As it seems,
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInJar_
 is way slower than its counterpart
 _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInDirectory_
 and since this method gets called a few hundred times at initialization in 
 this project, initialization of Log4J took more than 2 minutes with jar 
 packages, compared to a few seconds with class files.
 The performance issue was already mentioned in 
 [LOG4J2-184|https://issues.apache.org/jira/browse/LOG4J2-184], only without 
 the jar problem.
 The solution to [LOG4J2-175|https://issues.apache.org/jira/browse/LOG4J2-175] 
 might cause this, but we are unsure why the methods exactly get called this 
 often.
 I just can tell that
 _org.apache.logging.log4j.core.config.plugins.PluginManager#collectPlugins()_ 
 gets called VERY often via
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_, 
 which gets called by
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
 And _collectPlugins()_ is remapped to _collectPlugins(boolean preLoad, final 
 String pkgs)_ with _collectPlugins(true, null);_. I'm unsure what this 
 preLoad is for, since it gets overridden with false and apparently no kind of 
 caching is used. In this method, _resolver.findInPackage(test, pkg);_ takes a 
 whole lot of time searching within the jars, as described in the beginning.
 The only way to work around this was for us to extract the custom appender in 
 a sperate ant build target, and with this in a seperate jar, to minimize the 
 size of the jar, reducing the search time.
 Can you cache things and maybe reduce the calls to _collectPlugins()_? I 
 don't see the probability of changing plugins during initialization as 
 described in LOG4J2-175 or the comment in 
 _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_.
 Introducing a variable for the plugin manager within the for loop in 
 _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_ 
 might be a good idea!

--
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: svn commit: r1516445 - /logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SocketServer.java

[Scott Deboy]

Can you include that reply here?  Too many mails flying by.

Scott
On Aug 22, 2013 9:16 AM, Gary Gregory garydgreg...@gmail.com wrote:

 On Thu, Aug 22, 2013 at 12:09 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:

 Why?


 See my previous reply.

 Gary


 On Aug 22, 2013, at 6:25 AM, ggreg...@apache.org wrote:

  Author: ggregory
  Date: Thu Aug 22 13:25:16 2013
  New Revision: 1516445
 
  URL: http://svn.apache.org/r1516445
  Log:
  Explicit boxing and use Long cache.
 
  Modified:
 
  
 logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SocketServer.java
 
  Modified:
 logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SocketServer.java
  URL:
 http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SocketServer.java?rev=1516445r1=1516444r2=1516445view=diff
 
 ==
  ---
 logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SocketServer.java
 (original)
  +++
 logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SocketServer.java
 Thu Aug 22 13:25:16 2013
  @@ -131,7 +131,7 @@ public class SocketServer extends Abstra
  // socket has been accepted.
 
  final SocketHandler handler = new
 SocketHandler(clientSocket);
  -handlers.put(handler.getId(), handler);
  +handlers.put(Long.valueOf(handler.getId()), handler);
  handler.start();
  } catch (final IOException ioe) {
  System.out.println(Exception encountered on accept.
 Ignoring. Stack Trace :);
  @@ -195,7 +195,7 @@ public class SocketServer extends Abstra
  }
  }
  } finally {
  -handlers.remove(getId());
  +handlers.remove(Long.valueOf(getId()));
  }
  }
  }
 
 


 -
 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 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Dialects

[Scott Deboy]

See the Column casting in JDBCAppender Column casting in JDBCAppender
thread on the user list for context.

I think it's time to discuss this issue on the dev list.  There's no
need for us to say 'no' 20 different ways on the user list when the
reality is that the PGSQL enum issue can be easily handled if we
choose to do it.

Remember, any of us can hack the appender to add this feature..I
personally don't find your list of reasons to not add dialect support
compelling.

Scott

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

Re: svn commit: r1514021 [2/2] - in /logging/log4j/log4j2/trunk: core/src/main/java/org/apache/logging/log4j/core/appender/ core/src/main/java/org/apache/logging/log4j/core/appender/rewrite/ core/src/

[Scott Deboy]

I'm not sure if this ship has fully sailed, but I'd prefer to see us
stick with he dash format due to folks being familiar with it from
log4j 1.

Scott

On 8/16/13, Gary Gregory garydgreg...@gmail.com wrote:
 On Fri, Aug 16, 2013 at 1:13 PM, Ralph Goers
 ralph.go...@dslextreme.comwrote:

 I'm adding an aliases attribute to the Plugin annotation.


 Hold on to your horses ;)

 Another way to look at this is that our config parsing that is already
 case-insensitive could be augmented to strip out -s, no aliases needed.

 As someone pointed out here, some folks like-to-talk-like-this (see JPA).

 Gary



 On Aug 16, 2013, at 6:38 AM, Remko Popma wrote:

 Maybe we just need another plugin for the 2nd name then. Subclass or
 delegate?

 On Friday, August 16, 2013, Ralph Goers wrote:

 I had the same thought. People switching from log4j 1 or logback will
 probably make that mistake a lot. Plus this breaks virtually everyone
 currently using Log4j 2.  The problem is that I don't think there is
 currently a way for a plugin to have 2 names.

 Sent from my iPad

 On Aug 16, 2013, at 6:03 AM, Remko Popma remko.po...@gmail.com wrote:

 Would it be an idea to support both appender-ref and appenderRef
 attributes?



 On Thu, Aug 15, 2013 at 10:22 AM, Gary Gregory
 garydgreg...@gmail.comwrote:

 I never thought that Log4J 2 configuration files should be backward
 compatible with version 1, and even less so with a different product.

 Gary


 On Wed, Aug 14, 2013 at 8:51 PM, Ralph Goers
 ralph.go...@dslextreme.comwrote:

 Now that I see this it kind of scares me.  Log4j 1.x and Logback both
 use
 appender-ref. Anyone using Log4j 2 will now be broken.

 On Aug 14, 2013, at 1:05 PM, ggreg...@apache.org wrote:

  Modified:
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-config.xml
  URL:
 http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-config.xml?rev=1514021r1=1514020r2=1514021view=diff
 
 ==
  ---
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-config.xml
 (original)
  +++
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-config.xml Wed
 Aug 14 20:05:54 2013
  @@ -30,10 +30,10 @@
/appenders
loggers
  logger name=org.apache.test level=trace additivity=false
  -  appender-ref ref=List/
  +  AppenderRef ref=List/
  /logger
  root level=error
  -  appender-ref ref=STDOUT/
  +  AppenderRef ref=STDOUT/
  /root
/loggers
  /configuration
  \ No newline at end of file
 
  Modified:
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-console-highlight-default.xml
  URL:
 http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-console-highlight-default.xml?rev=1514021r1=1514020r2=1514021view=diff
 
 ==
  ---
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-console-highlight-default.xml
 (original)
  +++
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-console-highlight-default.xml
 Wed Aug 14 20:05:54 2013
  @@ -25,7 +25,7 @@
loggers
  logger name=org.foo level=DEBUG /
  root level=TRACE
  -  appender-ref ref=Console /
  +  AppenderRef ref=Console /
  /root
/loggers
  /configuration
  \ No newline at end of file
 
  Modified:
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-console-highlight-logback.xml
  URL:
 http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-console-highlight-logback.xml?rev=1514021r1=1514020r2=1514021view=diff
 
 ==
  ---
 logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-console-highlight-logback.xml
 (original)





 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: Two Question for NoSql MongoDB appender

[Scott Deboy]

Is there any way it could be getting loaded in another class loader?

Verbose classes flag help to determine that?
On Aug 16, 2013 10:37 PM, Nick Williams nicho...@nicholaswilliams.net
wrote:

 The problem is we don't know what's missing and we can't tell what's
 missing. I'm not even convinced that the problem IS a missing dependency.
 Whenever I've seen a missing dependency, the NoClassDefFoundError was for
 the actual missing dependency, not for the class that depended on it. This
 NoClassDefFoundError in this case is for org.mongodb.MongoException, which
 is 100% for certain without any question whatsoever correctly placed on the
 classpath.

 Nick

 On Aug 17, 2013, at 12:32 AM, Gary Gregory wrote:

 Why not try to create the proper dependencies and see if we can get it
 working? How else can we unit test otherwise?

 Gary


 On Sat, Aug 17, 2013 at 12:49 AM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 That approach concerns me. Catching RuntimeException essentially opens it
 up to thousands of possible exceptions that could be the cause, as opposed
 to looking for that exact cause. I suppose I don't have a choice, though.
 This apparently just isn't going to work.

 Definitely agreed that there is too much going on for a simple Exception
 class.

 :-/

 Nick


 On Aug 16, 2013, at 11:45 PM, Ralph Goers wrote:

 After following the chain of stuff that gets brought in via BSONObject I
 still recommend the approach in my other email of just catching
 RuntimeException.  A bunch of other classes are being referenced, one of
 which is creating a static Logger from java.util.logging. I have no idea
 why that might fail but there is just way too much going on for a simple
 Exception class.

 Ralph

 On Aug 16, 2013, at 9:26 PM, Nick Williams wrote:


 https://github.com/mongodb/mongo-java-driver/blob/master/src/main/com/mongodb/DB.java

 That also shows an import for org.bson.BSONObject, but the tests still
 run with just DB and no MongoException. org.bson is in the
 org.mongodb:mongo-java-driver JAR file. So, no, that's not the problem.
 There's something else...

 Nick

 On Aug 16, 2013, at 11:20 PM, Ralph Goers wrote:


 https://github.com/mongodb/mongo-java-driver/blob/master/src/main/com/mongodb/MongoException.java
  shows
 an import for org.bson.BSONObject.  The pom.xml for mongo-java-driver
 doesn't contain a transitive dependency for that and mvn dependency:tree on
 core doesn't show it.

 Ralph


 On Aug 16, 2013, at 3:48 PM, Nick Williams wrote:

 Guys, I'm having a hard time with this simple fix that should have taken
 five minutes. I'm getting test failures due to NoClassDefFoundErrors that
 shouldn't happen.

 Here are the tests in error:
   CategoryTest.setupClass:52 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testTraceWithException:415 ? NoClassDefFound
 com/mongodb/MongoExcep...
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testLog:459 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testRB1:295 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testRB2:314 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testRB3:334 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testTrace:388 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testAdditivity1:119 ? NoClassDefFound
 com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testAdditivity2:144 ? NoClassDefFound
 com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testAdditivity3:183 ? NoClassDefFound
 com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testIsTraceEnabled:443 ? NoClassDefFound
 com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.testExists:355 ? NoClassDefFound com/mongodb/MongoException
   LoggerTest.tearDown:75 ? NoClassDefFound com/mongodb/MongoException
   LoggingTest.setupClass:44 ? NoClassDefFound com/mongodb/MongoException
   LoggingTest.cleanupClass:49 NullPointer

 Here's the code I added:

 try {
 if (!database.authenticate(username,
 password.toCharArray())) {
 LOGGER.error(Failed to authenticate against
 MongoDB server. Unknown error.);
 }
 } catch (MongoException e) {
 LOGGER.error(Failed to authenticate against MongoDB:
  + e.getMessage(), e);
 } catch (IllegalStateException e) {
 

Mixing fixes with format changes

[Scott Deboy]

Hey folks,

Now that we have a few guys who are spending a lot of time working to
keep things 'consistent', a friendly reminder to please separate
formatting and 'consistency-related' changes in a separate commit from
bug fixes.

Thanks much,
Scott

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

Re: Final (again) (was Re: r1501104)

[Scott Deboy]

I appreciate the commitment to consistently but agree where it isn't
needed, it's reasonable for us as a group to decline to use final where not
strictly required.
On Jul 9, 2013 5:53 PM, Ralph Goers ralph.go...@dslextreme.com wrote:

 This topic was covered in an email thread that started with this email -
 http://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201301.mbox/%3CCACZkXPwsDyD-X%2B5wHuq4X26wzCZnsHJ%3Ds5rLJNKe71XYyg6LfA%40mail.gmail.com%3Ehttp://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201301.mbox/%3CCACZkXPwsDyD-X+5wHuq4X26wzCZnsHJ=s5rljnke71xyyg6...@mail.gmail.com%3E.
  Unfortunately I don't know how to link the whole thread from the apache
 archives but you can find it at
 http://marc.info/?t=13497881857r=1w=2.

 I happen to agree with you, as you will see from the thread.  I find it
 more annoying that many, many files were changed at once with no warning.
  I also suspect Gary does this through something automated in Eclipse,
 which means he doesn't see the comments that say don't do that.

 Ralph

 On Jul 9, 2013, at 4:41 PM, Nick Williams wrote:

 Gary,

 Earlier today you committed r1501104 with the following comment:

 Add final modifier to private fields.

 Add final modifier to method parameters.

 Add final modifier to local variables.


 I've seen you do similar things before, too. Can you explain a little bit
 why you do this? There's certainly no compiler value--the compiler for a
 long time has been capable of determining whether a variable is ever
 changed and optimizing appropriately. All it seems to do to me is clutter
 the code...significantly. It makes the code harder to read, IMO.

 Can you justify the intentional mass change of this nature?

 Thanks,

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

Re: Log4j 2 and JBoss Logging

[Scott Deboy]

+1 seems reasonable to me...

On 6/7/13, Nick Williams nicho...@nicholaswilliams.net wrote:
 The JBoss Logging devs have accepted my pull request to fix JBLOGGING-94
 [1], so JBoss Logging works with Log4j 2 now as of JBoss Logging 3.1.4 and
 3.2.0.

 However, JBoss Logging still only works with Log4j 2 _IF_ the log4j-1.2-api
 artifact is on the class path, and so it doesn't perform as well as it
 could. Thus, I've started working on a pull request that will add
 first-class support for Log4j 2, significantly improving performance.

 However, take a look at lines 850-851 of Category.java from Log4j 1.2 [2]
 and line 1460 of AbstractLogger.java from Log4j 2 [3]. In Log4j 1.2 this
 method was public, but its equivalent in Log4j 2 is protected. This means
 that JBoss Logging will have to subclass AbstractLoggerWrapper and wrap the
 original logger in order to call this method, with will not perform quite as
 well as calling the method on the original logger directly. Note that I had
 to do this exact thing for the log4j-taglib artifact: subclass
 AbstractLoggerWrapper just so that I could call this method.

 It seems, to me, that maybe this method should be public, like it was in
 1.2, instead of protected. That would simplify both the tag library and what
 I'm trying to do in JBoss Logging. It might simplify other bridge/adapter
 code, too. What do the rest of the devs think of this?

 Nick

 [1] https://issues.jboss.org/browse/JBLOGGING-94
 [2]
 http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/Category.java?view=markup#l850
 [3]
 http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/api/src/main/java/org/apache/logging/log4j/spi/AbstractLogger.java?view=markup#l1460


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



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

[jira] [Commented] (LOG4J2-238) OSGi dependency failures in core

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667035#comment-13667035
 ] 

Scott Deboy commented on LOG4J2-238:


Would you mind removing the commented out code?

 OSGi dependency failures in core
 

 Key: LOG4J2-238
 URL: https://issues.apache.org/jira/browse/LOG4J2-238
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta5
 Environment: OSGi (Eclipse 4.2.2, but I think the issue is generic 
 OSGi)
Reporter: Bob Kerns
  Labels: OSGi
 Attachments: 
 0001-LOG4J2-238-and-Log472-159.-OSGi-coordination-of-API-.patch


 To get the core module to load, in addition to re-fixing what was almost 
 fixed in LOG4J2-159 I had to make several packages optional.
 * com.lmax.disruptor
 * com.lmax.disruptor.dsl
 * com.lmax.disruptor.util
 These provided a dependency on sun.misc, which I could hack around to make 
 available but isn't normally available in OSGi and thus not a dependency I 
 can easily put into a product. I believe the dependency is on sun.misc.Unsafe 
  I'd like to use it...
 There is also a direct dependency somewhere on
 * sun.misc (also Unsafe)
 * com.sun.tools.jconsole -- I think this unlikely to be used in an OSGi 
 environment, so optional is appropriate.
 * org.codehaus.jackson
 * org.codehaus.jackson.map
 These would be easy enough to satisfy, but since most people won't need JSON 
 logging, the dependency should be optional.
 I think the correct minimal fix is just to make them all optional in the 
 manifest. Eliminating the need for sun.misc would be a good further step

--
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-252) SMTPAppender: send multiple events in one mail

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13663082#comment-13663082
 ] 

Scott Deboy commented on LOG4J2-252:


One implementation idea: Add a Timer with a daemon thread to SMTPManager and a 
quietPeriod property on the appender that's passed to the SMTPManager.  If 
there are events to be sent and the quietPeriod is exceeded, send them.

Have the SMTPManager implement LifeCycle (or just provide a stop method by 
itself) and cancel the Timer in SMTPManager's stop method, calling 
SMTPManager's stop from SMTPAppender.stop.

 SMTPAppender: send multiple events in one mail
 --

 Key: LOG4J2-252
 URL: https://issues.apache.org/jira/browse/LOG4J2-252
 Project: Log4j 2
  Issue Type: Wish
Reporter: Matej Vitásek

 I am using Log4j 2 for a Tomcat web application to send me an e-mail whenever 
 an ERROR occurs. Usually, more than one error is produced at one time, and I 
 get a lot of e-mails over a period of a few seconds.
 It would be great if the SMTPAppender could cluster more events into one 
 mail. Of course, one has to be sure that Log4j 2 is not waiting too long to 
 send me the errors, which could be solved by a timeout setting.
 So I propose the following: add a new timeout setting to the SMTPAppender. 
 Whenever an event that would trigger sending a mail occurs, wait for timeout 
 seconds and bundle whatever else events occur into this mail. Only then send 
 the mail.

--
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-241) Support the ability to trim logger name from the right.

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661381#comment-13661381
 ] 

Scott Deboy commented on LOG4J2-241:


This already exists in log4j extras.  we should cull extras for other things 
that can be pulled over:

http://svn.apache.org/viewvc?view=revisionrevision=r1481783


 Support the ability to trim logger name from the right.
 ---

 Key: LOG4J2-241
 URL: https://issues.apache.org/jira/browse/LOG4J2-241
 Project: Log4j 2
  Issue Type: Improvement
Affects Versions: 2.0-beta6
Reporter: Kurt Lehrke
Priority: Minor

 In log4j2, there doesn't seem to be a way to trim the logger name from the 
 right.  I have a situation where our logger names can be extremely large, 
 even when only using the class name.  We'd like to trim it down to a certain 
 number of characters (e.g. 10).  When reading trace files, the 10 beginning 
 characters would be more unique than the last 10 characters.  This would be 
 extremely useful for us to be able to do in the configuration file in the 
 pattern layout. 

--
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: Module clean ups

[Scott Deboy]

http://www.jetbrains.com/idea/buy/buy.jsp#openSource

On 5/16/13, Gary Gregory garydgreg...@gmail.com wrote:
 On Thu, May 16, 2013 at 6:04 PM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 I don't use Eclipse (can't stand the thing), so I hesitate to hazard a
 guess. My gut feeling is it sounds like a bug in the Maven Eclipse
 Plugin.
 The error message and URL definitely indicates that the error originated
 in
 the plugin. I would try running with -e to see the full error stack
 trace.
 If that doesn't help, try -X to get full debug mode. It rather sucks that
 it says Cant canonicalize system path: {0} but doesn't tell you what
 that
 path is. That path information sure would help determine what the problem
 was. Maybe debug or stack trace mode will help indicate what the path is
 that it can't canonicalize.

 You could also always try a real IDE. http://www.jetbrains.com/idea/ ;-)
 (By the way, Ultimate Edition is free for us FOSS folks.)


 How do you enable that version for us?

 Gary



 Nick


 On May 16, 2013, at 4:49 PM, Gary Gregory wrote:

 Nice work Nick.

 The last wrinkle for Eclipse users is that running, which is not new, is
 running mvn eclipse:eclipse works until the last sample:

 [INFO] Apache Log4j 2  SUCCESS
 [1.101s]
 [INFO] Apache Log4j API .. SUCCESS
 [0.256s]
 [INFO] Apache Log4j Core . SUCCESS
 [1.604s]
 [INFO] Apache Log4j 1.x Compatibility API  SUCCESS
 [0.216s]
 [INFO] Apache Log4j SLF4J Binding  SUCCESS
 [0.222s]
 [INFO] Apache Log4j to SLF4J Adapter . SUCCESS
 [0.163s]
 [INFO] Apache Log4j Commons Logging Bridge ... SUCCESS
 [0.136s]
 [INFO] Apache Log4j Flume NG Bridge .. SUCCESS
 [1.174s]
 [INFO] Apache Log4j Web Adapters . SUCCESS
 [0.135s]
 [INFO] Apache Log4j Tag Library .. SUCCESS
 [0.156s]
 [INFO] Apache Log4j JMX GUI .. SUCCESS
 [0.107s]
 [INFO] Apache Log4j Samples .. SUCCESS
 [0.082s]
 [INFO] Apache Log4j Samples: Flume - Common .. SUCCESS
 [0.508s]
 [INFO] Apache Log4j Samples: Flume - Remote .. FAILURE
 [0.769s]
 [INFO] Apache Log4j Samples: Flume - Embedded  SKIPPED
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 8.584s
 [INFO] Finished at: Thu May 16 17:47:35 EDT 2013
 [INFO] Final Memory: 38M/598M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse (default-cli)
 on
 project log4j-samples-flume-remote: Cant canonicalize system path: {0}:
 The
 filename, directory name, or volume label syntax
  is incorrect - [Help 1]
 [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/MojoExecutionException
 [ERROR]
 [ERROR] After correcting the problems, you can resume the build with the
 command
 [ERROR]   mvn goals -rf :log4j-samples-flume-remote

 Thoughts on that?

 Gary


 On Thu, May 16, 2013 at 5:23 PM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 - There were 400 use cases of Log4j in documentation, but around 100
 use cases of Log4J. All uses of Log4J have been changed to Log4j.

 - There were dozens of classes with Log4j in their names, but a
 handful
 had Log4J in their name. All uses of Log4J have been changed to
 Log4j.

 - There were 100 use cases of Log4j 2 in documentation, but a dozen
 or
 so Log4j2. All uses of Log4j2 have been changed to Log4j 2.

 - The sample artifacts all start with log4j-samples now.

 - The sample artifacts have real names now instead of falling back to
 their artifact IDs.

 - In the process of doing this, I incidentally correct many spelling
 errors in documentation. At some point I need to run spell check on the
 entire project...

 This is all committed. Everything compiles, all tests pass, site looks
 great.

 Nick

 On May 16, 2013, at 1:00 PM, Gary Gregory wrote:

 On Thu, May 16, 2013 at 1:43 PM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 If I understand correctly, you want the last four (all samples) to be:

 log4j-samples
 log4j-samples-common
 log4j-samples-remote
 log4j-samples-embedded

 And you also want them to have names as apposed to just IDs. I'll make
 some further observations:

 - Core and JMX GUI should start with Apache Log4j (lowercase J) like
 the other artifacts, not Apache Log4J 

Re: Product name companions vs extras

[Scott Deboy]

Extras sounds ok.

Scott
On May 15, 2013 4:01 AM, Christian Grobmeier grobme...@gmail.com wrote:

 Hi,

 we have had Apache Companions Extras. Now we don't have subcomponents.
 What is the new name now? Is it log4j extras or is it log4j
 companions?

 I am asking because we need a location for the website and I would
 like to fix the docs from the website.

 Basically I have a slight tendency to log4j extras 1.2.17 (note new
 version naming too)

 Cheers
 Christian

 --
 http://www.grobmeier.de
 https://www.timeandbill.de

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

Re: Useless parentheses?

[Scott Deboy]

I'd prefer if we leave the extra parens. IMO clarity trumps teachable
moments. Just disable the warning?
On May 13, 2013 8:26 AM, Nick Williams nicho...@nicholaswilliams.net
wrote:

 It's not 100% harmless, but it is harmless as far as operation of the code.

 To understand how it could cause harm, consider the situation where
 another developer who understands precedence incorrectly happens across the
 code and sees these parentheses. Seeing these parentheses will solidify his
 incorrect understanding of precedence. If, however, he sees it without
 parentheses, it will not make sense to him, and he will have to look up
 Java operator precedence to understand why it works.

 An unlikely scenario, to be sure, but that's enough to make me remove the
 parentheses.

 Nick

 On May 13, 2013, at 10:21 AM, Jess Holle wrote:

  I'm guilty of that weird (and useless) style -- for me it's an old habit
 from C days where I frequently defined a return(X) macro when doing certain
 types of troubleshooting.

 While this case is useless, it's also harmless.

 On 5/13/2013 10:14 AM, Gary Gregory wrote:

  The parentheses are useless to the compiler because  takes precedence
 over ||. The parentheses are useful to humans who have not memorized Java
 operator precedence ;)

  This warning is useful to catch weird style choices like return (foo +
 bar); I've seen other odd choices in parentheses styling.

 Gary


 On Mon, May 13, 2013 at 11:09 AM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:

 The PMD inspector says the following if statement contains Useless
 parentheses.

 if ((isEventTimestamp  isLiteralValue) || (isEventTimestamp 
 isPattern) || (isLiteralValue  isPattern)) {
 LOGGER.error(The pattern, literal, and isEventTimestamp
 attributes are mutually exclusive.);
 return null;
 }

 I'm all for removing useless parentheses; unfortunately, I don't see how
 these are useless. The way I see it, if isLiteralValue is false, with
 parentheses it will (correctly) continue to evaluate after the first
 grouped condition but without parentheses it would (incorrectly) short
 circuit after the first use of isLiteralValue.

 Am I missing something here? Or is this a PMD bug?

 Nick
 -
 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 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: Useless parentheses?

[Scott Deboy]

I believe there is consensus that the parens should be added back in.

On 5/13/13, Nick Williams nicho...@nicholaswilliams.net wrote:
 I'm confused. Does this mean the consensus is that I should add the
 parentheses back in? Ralph says:

 Anybody who thinks they understand something but doesn't is just going to
 be plain dangerous.


 I say that's exactly why the parentheses should be left out. Putting them
 back in perpetuates that danger by making that dangerous person think he's
 right.

 Nick

 On May 13, 2013, at 1:22 PM, Ralph Goers wrote:

 I'll be honest and admit that I overuse parens a lot because I don't ever
 want to have to remember precedence rules.   So I will always do (a * b) /
 c or (a / b) * c regardless of the whether they are needed or not.  The
 same is true of logical operators - unless they are all the same.  I don't
 really follow the logic of the guy who misunderstands precedence rules and
 removes the parens as there is something wrong with that picture.  Anybody
 who thinks they understand something but doesn't is just going to be plain
 dangerous.

 Ralph


 On May 13, 2013, at 9:50 AM, Remko Popma wrote:

 +1 on extra parens
 Teachable moments always seem to happen on Friday night when you really
 want to go home but it. just. doesn't. work...
 Not a fan. :-)

 From: Scott Deboy scott.de...@gmail.com
 To: Log4J Developers List log4j-dev@logging.apache.org
 Sent: Tuesday, May 14, 2013 1:27 AM
 Subject: Re: Useless parentheses?

 I'd prefer if we leave the extra parens. IMO clarity trumps teachable
 moments. Just disable the warning?
 On May 13, 2013 8:26 AM, Nick Williams nicho...@nicholaswilliams.net
 wrote:
 It's not 100% harmless, but it is harmless as far as operation of the
 code.

 To understand how it could cause harm, consider the situation where
 another developer who understands precedence incorrectly happens across
 the code and sees these parentheses. Seeing these parentheses will
 solidify his incorrect understanding of precedence. If, however, he sees
 it without parentheses, it will not make sense to him, and he will have
 to look up Java operator precedence to understand why it works.

 An unlikely scenario, to be sure, but that's enough to make me remove the
 parentheses.

 Nick

 On May 13, 2013, at 10:21 AM, Jess Holle wrote:

 I'm guilty of that weird (and useless) style -- for me it's an old habit
 from C days where I frequently defined a return(X) macro when doing
 certain types of troubleshooting.

 While this case is useless, it's also harmless.

 On 5/13/2013 10:14 AM, Gary Gregory wrote:
 The parentheses are useless to the compiler because  takes precedence
 over ||. The parentheses are useful to humans who have not memorized
 Java operator precedence ;)

 This warning is useful to catch weird style choices like return (foo +
 bar); I've seen other odd choices in parentheses styling.

 Gary


 On Mon, May 13, 2013 at 11:09 AM, Nick Williams
 nicho...@nicholaswilliams.net wrote:
 The PMD inspector says the following if statement contains Useless
 parentheses.

 if ((isEventTimestamp  isLiteralValue) || (isEventTimestamp
  isPattern) || (isLiteralValue  isPattern)) {
 LOGGER.error(The pattern, literal, and isEventTimestamp
 attributes are mutually exclusive.);
 return null;
 }

 I'm all for removing useless parentheses; unfortunately, I don't see
 how these are useless. The way I see it, if isLiteralValue is false,
 with parentheses it will (correctly) continue to evaluate after the
 first grouped condition but without parentheses it would (incorrectly)
 short circuit after the first use of isLiteralValue.

 Am I missing something here? Or is this a PMD bug?

 Nick
 -
 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: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

Thanks for posting to the dev list!

I've commented on your stackoverflow post.  There were a few issues.

 - Stale docs (sorry)
 - No support in Chainsaw V2 for Log4j2 socketappenders yet
 - Chainsaw wasn't setting up a 'tailing' log file receiver
configuration for the advertised fileappender

Those are all fixed, and I commented on the stackoverflow post.

Thanks much!



On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Hi all, I'm trying to get a basic hello world log message to stream from
 log4j2 (beta 5, the binary release as of yesterday) to chainsaw v2 (also
 the binary release as of yesterday). None of my guesses as to what to put
 into log4j2.xml have proven fruitful. I'm also asking this question on
 stack overflow (
 http://stackoverflow.com/questions/16474939/log4j2-to-chainsaw-hello-world-not-working-what-am-i-doing-wrong)
 if you'd like to get some goodness points in exchange for the answer
 (otherwise I'll copy whatever I get working to there and keep the goodness
 points for myself).

 My config file is posted in the SO question, but I'd be just as happy
 scrapping the whole thing and pasting in something that ought to work,
 whichever is easier. Thanks for your help!

 --M@


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

Re: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

Please note, the latest 'release' of Chainsaw doesn't support Log4j2,
only the developer snapshot available here:
http://people.apache.org/~sdeboy

On 5/10/13, Scott Deboy scott.de...@gmail.com wrote:
 Thanks for posting to the dev list!

 I've commented on your stackoverflow post.  There were a few issues.

  - Stale docs (sorry)
  - No support in Chainsaw V2 for Log4j2 socketappenders yet
  - Chainsaw wasn't setting up a 'tailing' log file receiver
 configuration for the advertised fileappender

 Those are all fixed, and I commented on the stackoverflow post.

 Thanks much!



 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Hi all, I'm trying to get a basic hello world log message to stream from
 log4j2 (beta 5, the binary release as of yesterday) to chainsaw v2 (also
 the binary release as of yesterday). None of my guesses as to what to put
 into log4j2.xml have proven fruitful. I'm also asking this question on
 stack overflow (
 http://stackoverflow.com/questions/16474939/log4j2-to-chainsaw-hello-world-not-working-what-am-i-doing-wrong)
 if you'd like to get some goodness points in exchange for the answer
 (otherwise I'll copy whatever I get working to there and keep the
 goodness
 points for myself).

 My config file is posted in the SO question, but I'd be just as happy
 scrapping the whole thing and pasting in something that ought to work,
 whichever is easier. Thanks for your help!

 --M@



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

Re: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

So a couple of things - the config I posted was a Log4j2 config to use
on the appender side.  Make sure your app is using that appender
configuration.

This allows Chainsaw to begin parsing and tailing your log file
without you having to tell Chainsaw about the fileappender
configuration.

Once you have started your app that is using the appender
configuration I provided, just open the 'zeroconf' tab in Chainsaw.
You should see a row with your appender's name (assuming you added
jmdns to the classpath for the app using the fileappender
configuration).

You can click 'autoconnect' if you'd like to always start Chainsaw
with this configuration if it is available.  Next, just double-click
on the row and Chainsaw will start  parsing and tailing your log file
- assuming the advertised URL your used in your file appender
configuration is accessible by Chainsaw (looks like you are working
locally with Chainsaw and your fileappender, so file:// paths will
work fine).

On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Thanks for the quick response!  I pulled down your custom build and it's
 definitely fixed some things (notably the please load a config file intro
 screen), but I'm still not getting it.

 I pointed chainsaw at the config file you posted on SO but it didn't seem
 to cause chainsaw to do anything (no recievers defined, zeroconf still did
 nothing).  After that I tried opening the log file but it wouldn't open.
  When I switched the logging format back to XMLLayout chainsaw could
 manually open it, but it still didn't tail.  Could the not tailing be
 related to the XML format?  Is there a more tail-friendly format that will
 open?

 On an unrelated note, in the new version the horizontal resizing (of the
 recievers pane and the pane on the other side) seems to be broken, it's not
 really a problem, just a heads up.

 --M@

 On Fri, May 10, 2013 at 11:48 AM, Scott Deboy scott.de...@gmail.com
 wrote:

 Thanks for posting to the dev list!

 I've commented on your stackoverflow post.  There were a few issues.

  - Stale docs (sorry)
  - No support in Chainsaw V2 for Log4j2 socketappenders yet
  - Chainsaw wasn't setting up a 'tailing' log file receiver
 configuration for the advertised fileappender

 Those are all fixed, and I commented on the stackoverflow post.

 Thanks much!



 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  Hi all, I'm trying to get a basic hello world log message to stream
  from
  log4j2 (beta 5, the binary release as of yesterday) to chainsaw v2
  (also
  the binary release as of yesterday). None of my guesses as to what to
  put
  into log4j2.xml have proven fruitful. I'm also asking this question on
  stack overflow (
 
 http://stackoverflow.com/questions/16474939/log4j2-to-chainsaw-hello-world-not-working-what-am-i-doing-wrong
 )
  if you'd like to get some goodness points in exchange for the answer
  (otherwise I'll copy whatever I get working to there and keep the
 goodness
  points for myself).
 
  My config file is posted in the SO question, but I'd be just as happy
  scrapping the whole thing and pasting in something that ought to work,
  whichever is easier. Thanks for your help!
 
  --M@
 

 -
 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: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

When Chainsaw starts you don't need to give it a config, as the config
will be generated once the advertisement is discovered.

If you have a row in ZeroConf with your appender name, that's great.

Maybe the advertiseURI in your log4j appender configuration is wrong?
Copy and paste that into a browser to see if it opens your log file.
If not, you need to put in the right URI for your log file and restart
the app..and maybe Chainsaw..not sure if updates to advertisements
work - haven't tried it.

Also, are you using a patternlayout? You need to
(VFSLogFilePatternReceiver doesn't support XMLLayout).

You should see a receiver defined in the receiver window...if it's not
showing anything it's because the advertiseURI you provided wasn't
quite right.

On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Right, I followed you, I'm using it in my app, what I meant was when
 Chainsaw starts it asks me if I want to open a log4j config file so I
 select the one the app is using and click Ok.  I hadn't notice this before
 because my window was too small, but at the status bar at the bottom it
 tells me the result of that was {}.

 Good call, I did have the jmdns line commented out in the classpath from
 last night's debugging, so that's back in, and now zeroconf is much closer
 to working.  The only remaining problem is that although the zeroconf tab
 says Connected no tab has popped up.  Double clicking the row toggles it
 between Connected ant Not Connected, but I can't see any of the messages
 that should be streaming in.  Giving the receiver a level doesn't seem to
 fix it either.  Any idea what the problem is?

 Also it seems that one of the restarts has fixed the horizontal resizing
 issue I'd been seeing.

 --M@

 On Fri, May 10, 2013 at 1:13 PM, Scott Deboy scott.de...@gmail.com wrote:

 So a couple of things - the config I posted was a Log4j2 config to use
 on the appender side.  Make sure your app is using that appender
 configuration.

 This allows Chainsaw to begin parsing and tailing your log file
 without you having to tell Chainsaw about the fileappender
 configuration.

 Once you have started your app that is using the appender
 configuration I provided, just open the 'zeroconf' tab in Chainsaw.
 You should see a row with your appender's name (assuming you added
 jmdns to the classpath for the app using the fileappender
 configuration).

 You can click 'autoconnect' if you'd like to always start Chainsaw
 with this configuration if it is available.  Next, just double-click
 on the row and Chainsaw will start  parsing and tailing your log file
 - assuming the advertised URL your used in your file appender
 configuration is accessible by Chainsaw (looks like you are working
 locally with Chainsaw and your fileappender, so file:// paths will
 work fine).

 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  Thanks for the quick response!  I pulled down your custom build and
  it's
  definitely fixed some things (notably the please load a config file
 intro
  screen), but I'm still not getting it.
 
  I pointed chainsaw at the config file you posted on SO but it didn't
  seem
  to cause chainsaw to do anything (no recievers defined, zeroconf still
 did
  nothing).  After that I tried opening the log file but it wouldn't
  open.
   When I switched the logging format back to XMLLayout chainsaw could
  manually open it, but it still didn't tail.  Could the not tailing be
  related to the XML format?  Is there a more tail-friendly format that
 will
  open?
 
  On an unrelated note, in the new version the horizontal resizing (of
  the
  recievers pane and the pane on the other side) seems to be broken, it's
 not
  really a problem, just a heads up.
 
  --M@
 
  On Fri, May 10, 2013 at 11:48 AM, Scott Deboy scott.de...@gmail.com
  wrote:
 
  Thanks for posting to the dev list!
 
  I've commented on your stackoverflow post.  There were a few issues.
 
   - Stale docs (sorry)
   - No support in Chainsaw V2 for Log4j2 socketappenders yet
   - Chainsaw wasn't setting up a 'tailing' log file receiver
  configuration for the advertised fileappender
 
  Those are all fixed, and I commented on the stackoverflow post.
 
  Thanks much!
 
 
 
  On 5/10/13, M@ matthew.dun...@gmail.com wrote:
   Hi all, I'm trying to get a basic hello world log message to stream
   from
   log4j2 (beta 5, the binary release as of yesterday) to chainsaw v2
   (also
   the binary release as of yesterday). None of my guesses as to what
   to
   put
   into log4j2.xml have proven fruitful. I'm also asking this question
   on
   stack overflow (
  
 
 http://stackoverflow.com/questions/16474939/log4j2-to-chainsaw-hello-world-not-working-what-am-i-doing-wrong
  )
   if you'd like to get some goodness points in exchange for the answer
   (otherwise I'll copy whatever I get working to there and keep the
  goodness
   points for myself).
  
   My config file is posted in the SO question, but I'd be just as
   happy
   scrapping the whole thing and pasting

Re: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

Look in the chainsaw-log tab - there should be messages explaining why
it isn't working.

On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Err, sorry, I meant the URI opens perfectly.

 --M@

 On Fri, May 10, 2013 at 2:14 PM, M@ matthew.dun...@gmail.com wrote:

 Yeah, the filename opens perfectly in a browser.  I've tried it both with
 a patternlayout and with the xmllayout, the xmllayout never says
 Connected
 in zero conf.  Right now I'm using a complete copy and paste of the
 config
 file you put in SO.

 I do see a receiver listed, and I can right click to tell it I'd like to
 see trace, but that's all I can get it to do.  Restarting the receiver
 doesn't seem to do anything.  Double clicking does nothing.

 --M@

 On Fri, May 10, 2013 at 2:07 PM, Scott Deboy
 scott.de...@gmail.comwrote:

 When Chainsaw starts you don't need to give it a config, as the config
 will be generated once the advertisement is discovered.

 If you have a row in ZeroConf with your appender name, that's great.

 Maybe the advertiseURI in your log4j appender configuration is wrong?
 Copy and paste that into a browser to see if it opens your log file.
 If not, you need to put in the right URI for your log file and restart
 the app..and maybe Chainsaw..not sure if updates to advertisements
 work - haven't tried it.

 Also, are you using a patternlayout? You need to
 (VFSLogFilePatternReceiver doesn't support XMLLayout).

 You should see a receiver defined in the receiver window...if it's not
 showing anything it's because the advertiseURI you provided wasn't
 quite right.

 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  Right, I followed you, I'm using it in my app, what I meant was when
  Chainsaw starts it asks me if I want to open a log4j config file so I
  select the one the app is using and click Ok.  I hadn't notice this
 before
  because my window was too small, but at the status bar at the bottom
  it
  tells me the result of that was {}.
 
  Good call, I did have the jmdns line commented out in the classpath
  from
  last night's debugging, so that's back in, and now zeroconf is much
 closer
  to working.  The only remaining problem is that although the zeroconf
 tab
  says Connected no tab has popped up.  Double clicking the row toggles
  it
  between Connected ant Not Connected, but I can't see any of the
  messages
  that should be streaming in.  Giving the receiver a level doesn't seem
 to
  fix it either.  Any idea what the problem is?
 
  Also it seems that one of the restarts has fixed the horizontal
  resizing
  issue I'd been seeing.
 
  --M@
 
  On Fri, May 10, 2013 at 1:13 PM, Scott Deboy scott.de...@gmail.com
 wrote:
 
  So a couple of things - the config I posted was a Log4j2 config to
  use
  on the appender side.  Make sure your app is using that appender
  configuration.
 
  This allows Chainsaw to begin parsing and tailing your log file
  without you having to tell Chainsaw about the fileappender
  configuration.
 
  Once you have started your app that is using the appender
  configuration I provided, just open the 'zeroconf' tab in Chainsaw.
  You should see a row with your appender's name (assuming you added
  jmdns to the classpath for the app using the fileappender
  configuration).
 
  You can click 'autoconnect' if you'd like to always start Chainsaw
  with this configuration if it is available.  Next, just double-click
  on the row and Chainsaw will start  parsing and tailing your log file
  - assuming the advertised URL your used in your file appender
  configuration is accessible by Chainsaw (looks like you are working
  locally with Chainsaw and your fileappender, so file:// paths will
  work fine).
 
  On 5/10/13, M@ matthew.dun...@gmail.com wrote:
   Thanks for the quick response!  I pulled down your custom build and
   it's
   definitely fixed some things (notably the please load a config
   file
  intro
   screen), but I'm still not getting it.
  
   I pointed chainsaw at the config file you posted on SO but it
   didn't
   seem
   to cause chainsaw to do anything (no recievers defined, zeroconf
 still
  did
   nothing).  After that I tried opening the log file but it wouldn't
   open.
When I switched the logging format back to XMLLayout chainsaw
   could
   manually open it, but it still didn't tail.  Could the not tailing
   be
   related to the XML format?  Is there a more tail-friendly format
   that
  will
   open?
  
   On an unrelated note, in the new version the horizontal resizing
   (of
   the
   recievers pane and the pane on the other side) seems to be broken,
 it's
  not
   really a problem, just a heads up.
  
   --M@
  
   On Fri, May 10, 2013 at 11:48 AM, Scott Deboy
   scott.de...@gmail.com
 
   wrote:
  
   Thanks for posting to the dev list!
  
   I've commented on your stackoverflow post.  There were a few
   issues.
  
- Stale docs (sorry)
- No support in Chainsaw V2 for Log4j2 socketappenders yet
- Chainsaw wasn't setting up a 'tailing' log file

Re: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

Try this form of URI (note the three slashes at the front):

file:///path/to/logfile



On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 It says the file is not available (retry in 10s), so I copied and pasted
 the URI from the log message and it opens ok in a browser.

 --M@

 On Fri, May 10, 2013 at 2:18 PM, Scott Deboy scott.de...@gmail.com wrote:

 Look in the chainsaw-log tab - there should be messages explaining why
 it isn't working.

 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  Err, sorry, I meant the URI opens perfectly.
 
  --M@
 
  On Fri, May 10, 2013 at 2:14 PM, M@ matthew.dun...@gmail.com wrote:
 
  Yeah, the filename opens perfectly in a browser.  I've tried it both
 with
  a patternlayout and with the xmllayout, the xmllayout never says
  Connected
  in zero conf.  Right now I'm using a complete copy and paste of the
  config
  file you put in SO.
 
  I do see a receiver listed, and I can right click to tell it I'd like
  to
  see trace, but that's all I can get it to do.  Restarting the receiver
  doesn't seem to do anything.  Double clicking does nothing.
 
  --M@
 
  On Fri, May 10, 2013 at 2:07 PM, Scott Deboy
  scott.de...@gmail.comwrote:
 
  When Chainsaw starts you don't need to give it a config, as the
  config
  will be generated once the advertisement is discovered.
 
  If you have a row in ZeroConf with your appender name, that's great.
 
  Maybe the advertiseURI in your log4j appender configuration is wrong?
  Copy and paste that into a browser to see if it opens your log file.
  If not, you need to put in the right URI for your log file and
  restart
  the app..and maybe Chainsaw..not sure if updates to advertisements
  work - haven't tried it.
 
  Also, are you using a patternlayout? You need to
  (VFSLogFilePatternReceiver doesn't support XMLLayout).
 
  You should see a receiver defined in the receiver window...if it's
  not
  showing anything it's because the advertiseURI you provided wasn't
  quite right.
 
  On 5/10/13, M@ matthew.dun...@gmail.com wrote:
   Right, I followed you, I'm using it in my app, what I meant was
   when
   Chainsaw starts it asks me if I want to open a log4j config file so
   I
   select the one the app is using and click Ok.  I hadn't notice this
  before
   because my window was too small, but at the status bar at the
   bottom
   it
   tells me the result of that was {}.
  
   Good call, I did have the jmdns line commented out in the classpath
   from
   last night's debugging, so that's back in, and now zeroconf is much
  closer
   to working.  The only remaining problem is that although the
   zeroconf
  tab
   says Connected no tab has popped up.  Double clicking the row
   toggles
   it
   between Connected ant Not Connected, but I can't see any of the
   messages
   that should be streaming in.  Giving the receiver a level doesn't
 seem
  to
   fix it either.  Any idea what the problem is?
  
   Also it seems that one of the restarts has fixed the horizontal
   resizing
   issue I'd been seeing.
  
   --M@
  
   On Fri, May 10, 2013 at 1:13 PM, Scott Deboy
   scott.de...@gmail.com
  wrote:
  
   So a couple of things - the config I posted was a Log4j2 config to
   use
   on the appender side.  Make sure your app is using that appender
   configuration.
  
   This allows Chainsaw to begin parsing and tailing your log file
   without you having to tell Chainsaw about the fileappender
   configuration.
  
   Once you have started your app that is using the appender
   configuration I provided, just open the 'zeroconf' tab in
   Chainsaw.
   You should see a row with your appender's name (assuming you added
   jmdns to the classpath for the app using the fileappender
   configuration).
  
   You can click 'autoconnect' if you'd like to always start Chainsaw
   with this configuration if it is available.  Next, just
   double-click
   on the row and Chainsaw will start  parsing and tailing your log
 file
   - assuming the advertised URL your used in your file appender
   configuration is accessible by Chainsaw (looks like you are
   working
   locally with Chainsaw and your fileappender, so file:// paths will
   work fine).
  
   On 5/10/13, M@ matthew.dun...@gmail.com wrote:
Thanks for the quick response!  I pulled down your custom build
 and
it's
definitely fixed some things (notably the please load a config
file
   intro
screen), but I'm still not getting it.
   
I pointed chainsaw at the config file you posted on SO but it
didn't
seem
to cause chainsaw to do anything (no recievers defined, zeroconf
  still
   did
nothing).  After that I tried opening the log file but it
wouldn't
open.
 When I switched the logging format back to XMLLayout chainsaw
could
manually open it, but it still didn't tail.  Could the not
tailing
be
related to the XML format?  Is there a more tail-friendly format
that
   will
open?
   
On an unrelated note, in the new version

Re: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

The advertiser should be doing all that for you..it may be getting
hung up if you don't have good delimiters.

The fix: change your patternlayout on the appender side to include
delimiters around each field and Chainsaw will parse them correctly.

On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Brilliant!  That got it.  Thank you so much!

 For my next trick I'll play with the format string to get the Logger
 column to populate correctly, but that's minor and probably not hard.

 --M@

 On Fri, May 10, 2013 at 2:24 PM, Scott Deboy scott.de...@gmail.com wrote:

 Try this form of URI (note the three slashes at the front):

 file:///path/to/logfile



 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  It says the file is not available (retry in 10s), so I copied and
  pasted
  the URI from the log message and it opens ok in a browser.
 
  --M@
 
  On Fri, May 10, 2013 at 2:18 PM, Scott Deboy scott.de...@gmail.com
 wrote:
 
  Look in the chainsaw-log tab - there should be messages explaining why
  it isn't working.
 
  On 5/10/13, M@ matthew.dun...@gmail.com wrote:
   Err, sorry, I meant the URI opens perfectly.
  
   --M@
  
   On Fri, May 10, 2013 at 2:14 PM, M@ matthew.dun...@gmail.com
   wrote:
  
   Yeah, the filename opens perfectly in a browser.  I've tried it
   both
  with
   a patternlayout and with the xmllayout, the xmllayout never says
   Connected
   in zero conf.  Right now I'm using a complete copy and paste of the
   config
   file you put in SO.
  
   I do see a receiver listed, and I can right click to tell it I'd
   like
   to
   see trace, but that's all I can get it to do.  Restarting the
 receiver
   doesn't seem to do anything.  Double clicking does nothing.
  
   --M@
  
   On Fri, May 10, 2013 at 2:07 PM, Scott Deboy
   scott.de...@gmail.comwrote:
  
   When Chainsaw starts you don't need to give it a config, as the
   config
   will be generated once the advertisement is discovered.
  
   If you have a row in ZeroConf with your appender name, that's
   great.
  
   Maybe the advertiseURI in your log4j appender configuration is
 wrong?
   Copy and paste that into a browser to see if it opens your log
   file.
   If not, you need to put in the right URI for your log file and
   restart
   the app..and maybe Chainsaw..not sure if updates to advertisements
   work - haven't tried it.
  
   Also, are you using a patternlayout? You need to
   (VFSLogFilePatternReceiver doesn't support XMLLayout).
  
   You should see a receiver defined in the receiver window...if it's
   not
   showing anything it's because the advertiseURI you provided wasn't
   quite right.
  
   On 5/10/13, M@ matthew.dun...@gmail.com wrote:
Right, I followed you, I'm using it in my app, what I meant was
when
Chainsaw starts it asks me if I want to open a log4j config file
 so
I
select the one the app is using and click Ok.  I hadn't notice
 this
   before
because my window was too small, but at the status bar at the
bottom
it
tells me the result of that was {}.
   
Good call, I did have the jmdns line commented out in the
 classpath
from
last night's debugging, so that's back in, and now zeroconf is
 much
   closer
to working.  The only remaining problem is that although the
zeroconf
   tab
says Connected no tab has popped up.  Double clicking the row
toggles
it
between Connected ant Not Connected, but I can't see any of the
messages
that should be streaming in.  Giving the receiver a level
doesn't
  seem
   to
fix it either.  Any idea what the problem is?
   
Also it seems that one of the restarts has fixed the horizontal
resizing
issue I'd been seeing.
   
--M@
   
On Fri, May 10, 2013 at 1:13 PM, Scott Deboy
scott.de...@gmail.com
   wrote:
   
So a couple of things - the config I posted was a Log4j2 config
 to
use
on the appender side.  Make sure your app is using that
appender
configuration.
   
This allows Chainsaw to begin parsing and tailing your log file
without you having to tell Chainsaw about the fileappender
configuration.
   
Once you have started your app that is using the appender
configuration I provided, just open the 'zeroconf' tab in
Chainsaw.
You should see a row with your appender's name (assuming you
 added
jmdns to the classpath for the app using the fileappender
configuration).
   
You can click 'autoconnect' if you'd like to always start
 Chainsaw
with this configuration if it is available.  Next, just
double-click
on the row and Chainsaw will start  parsing and tailing your
log
  file
- assuming the advertised URL your used in your file appender
configuration is accessible by Chainsaw (looks like you are
working
locally with Chainsaw and your fileappender, so file:// paths
 will
work fine).
   
On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Thanks for the quick response!  I pulled

Re: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

Spaces should work fine around logger names, as long as there are no
spaces in your logger names!

Can you describe what you are seeing that's weird?

On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 I'm just using a pattern I copied from the docs ;-)

 --M@

 On Fri, May 10, 2013 at 2:33 PM, Scott Deboy scott.de...@gmail.com wrote:

 The advertiser should be doing all that for you..it may be getting
 hung up if you don't have good delimiters.

 The fix: change your patternlayout on the appender side to include
 delimiters around each field and Chainsaw will parse them correctly.

 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  Brilliant!  That got it.  Thank you so much!
 
  For my next trick I'll play with the format string to get the Logger
  column to populate correctly, but that's minor and probably not hard.
 
  --M@
 
  On Fri, May 10, 2013 at 2:24 PM, Scott Deboy scott.de...@gmail.com
 wrote:
 
  Try this form of URI (note the three slashes at the front):
 
  file:///path/to/logfile
 
 
 
  On 5/10/13, M@ matthew.dun...@gmail.com wrote:
   It says the file is not available (retry in 10s), so I copied and
   pasted
   the URI from the log message and it opens ok in a browser.
  
   --M@
  
   On Fri, May 10, 2013 at 2:18 PM, Scott Deboy scott.de...@gmail.com
  wrote:
  
   Look in the chainsaw-log tab - there should be messages explaining
 why
   it isn't working.
  
   On 5/10/13, M@ matthew.dun...@gmail.com wrote:
Err, sorry, I meant the URI opens perfectly.
   
--M@
   
On Fri, May 10, 2013 at 2:14 PM, M@ matthew.dun...@gmail.com
wrote:
   
Yeah, the filename opens perfectly in a browser.  I've tried it
both
   with
a patternlayout and with the xmllayout, the xmllayout never says
Connected
in zero conf.  Right now I'm using a complete copy and paste of
 the
config
file you put in SO.
   
I do see a receiver listed, and I can right click to tell it I'd
like
to
see trace, but that's all I can get it to do.  Restarting the
  receiver
doesn't seem to do anything.  Double clicking does nothing.
   
--M@
   
On Fri, May 10, 2013 at 2:07 PM, Scott Deboy
scott.de...@gmail.comwrote:
   
When Chainsaw starts you don't need to give it a config, as the
config
will be generated once the advertisement is discovered.
   
If you have a row in ZeroConf with your appender name, that's
great.
   
Maybe the advertiseURI in your log4j appender configuration is
  wrong?
Copy and paste that into a browser to see if it opens your log
file.
If not, you need to put in the right URI for your log file and
restart
the app..and maybe Chainsaw..not sure if updates to
 advertisements
work - haven't tried it.
   
Also, are you using a patternlayout? You need to
(VFSLogFilePatternReceiver doesn't support XMLLayout).
   
You should see a receiver defined in the receiver window...if
 it's
not
showing anything it's because the advertiseURI you provided
 wasn't
quite right.
   
On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Right, I followed you, I'm using it in my app, what I meant
 was
 when
 Chainsaw starts it asks me if I want to open a log4j config
 file
  so
 I
 select the one the app is using and click Ok.  I hadn't
 notice
  this
before
 because my window was too small, but at the status bar at the
 bottom
 it
 tells me the result of that was {}.

 Good call, I did have the jmdns line commented out in the
  classpath
 from
 last night's debugging, so that's back in, and now zeroconf
 is
  much
closer
 to working.  The only remaining problem is that although the
 zeroconf
tab
 says Connected no tab has popped up.  Double clicking the row
 toggles
 it
 between Connected ant Not Connected, but I can't see any of
 the
 messages
 that should be streaming in.  Giving the receiver a level
 doesn't
   seem
to
 fix it either.  Any idea what the problem is?

 Also it seems that one of the restarts has fixed the
 horizontal
 resizing
 issue I'd been seeing.

 --M@

 On Fri, May 10, 2013 at 1:13 PM, Scott Deboy
 scott.de...@gmail.com
wrote:

 So a couple of things - the config I posted was a Log4j2
 config
  to
 use
 on the appender side.  Make sure your app is using that
 appender
 configuration.

 This allows Chainsaw to begin parsing and tailing your log
 file
 without you having to tell Chainsaw about the fileappender
 configuration.

 Once you have started your app that is using the appender
 configuration I provided, just open the 'zeroconf' tab in
 Chainsaw.
 You should see a row with your appender's name (assuming you
  added
 jmdns to the classpath for the app using the fileappender
 configuration).

 You can click 'autoconnect' if you'd

Re: struggling with getting hello world from log4j2 to chainsaw v2

[Scott Deboy]

Thanks, taken care of.

On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 I edited your SO answer to not contain that mistake, it's awaiting peer
 review, do you have the ability to approve it?

 --M@

 On Fri, May 10, 2013 at 3:40 PM, Scott Deboy scott.de...@gmail.com wrote:

 Great!

 I need to add a wiki topic on this..



 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  The problem was an errant 'sg'
PatternLayout pattern=%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
  %msg%n/
  should have been
  PatternLayout pattern=%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
  %m%n/
 
  It's working like a charm now, thanks again for all your help.
 
  --M@
 
  On Fri, May 10, 2013 at 3:01 PM, Scott Deboy scott.de...@gmail.com
 wrote:
 
  Mind pasting in your Log4j appender configuration? I'd like to fix
  whatever is tripping this up.
 
  On 5/10/13, Scott Deboy scott.de...@gmail.com wrote:
   If appendNonMatches=true in the (VFS)LogFilePatternReceiver and a
   line
   of text from the log file can't be parsed (the regexp fails for that
   line or the timestampformat doesn't match), the entire line is set
   as
   the 'message' field with an 'Unknown' logger.
  
   This way you always see your log events on-screen, even if Chainsaw
   can't parse them correctly.
  
   According to what I see, there are a couple of things:
  
   The logFormat for this receiver should be:
   TIMESTAMP [THREAD] LEVEL LOGGER - MESSAGE
  
   The timestampFormat should be:
   HH:mm:ss.SSS
  
   Is that what the generated receiver shows in the receivers panel?
  
   If not, from the receivers panel, change the values to match what I
   provided, and press the 'half-circle arrow' button (restart the
   receiver).  It should work.
  
   On 5/10/13, M@ matthew.dun...@gmail.com wrote:
   Level
   DEBUG
   Logger
   Unknown
   Time
   2013-05-10 14:46:50,649 (ms delta: 0)
   Thread
   AWT-EventQueue-0
   Message
   14:46:50.434 [MainLoop] TRACE com.mds.simulator.MdsSimComponentImpl
   -
   tick
   Marker
  
   Throwable
  
   The logger is showing in the message but the the logger field
   reports
   Unknown
  
   On Fri, May 10, 2013 at 2:43 PM, Scott Deboy
   scott.de...@gmail.com
   wrote:
  
   Spaces should work fine around logger names, as long as there are
   no
   spaces in your logger names!
  
   Can you describe what you are seeing that's weird?
  
   On 5/10/13, M@ matthew.dun...@gmail.com wrote:
I'm just using a pattern I copied from the docs ;-)
   
--M@
   
On Fri, May 10, 2013 at 2:33 PM, Scott Deboy
scott.de...@gmail.com
   wrote:
   
The advertiser should be doing all that for you..it may be
 getting
hung up if you don't have good delimiters.
   
The fix: change your patternlayout on the appender side to
 include
delimiters around each field and Chainsaw will parse them
correctly.
   
On 5/10/13, M@ matthew.dun...@gmail.com wrote:
 Brilliant!  That got it.  Thank you so much!

 For my next trick I'll play with the format string to get the
 Logger
 column to populate correctly, but that's minor and probably
 not
 hard.

 --M@

 On Fri, May 10, 2013 at 2:24 PM, Scott Deboy
 scott.de...@gmail.com
wrote:

 Try this form of URI (note the three slashes at the front):

 file:///path/to/logfile



 On 5/10/13, M@ matthew.dun...@gmail.com wrote:
  It says the file is not available (retry in 10s), so I
 copied
  and
  pasted
  the URI from the log message and it opens ok in a browser.
 
  --M@
 
  On Fri, May 10, 2013 at 2:18 PM, Scott Deboy 
   scott.de...@gmail.com
 wrote:
 
  Look in the chainsaw-log tab - there should be messages
  explaining
why
  it isn't working.
 
  On 5/10/13, M@ matthew.dun...@gmail.com wrote:
   Err, sorry, I meant the URI opens perfectly.
  
   --M@
  
   On Fri, May 10, 2013 at 2:14 PM, M@
   matthew.dun...@gmail.com
   wrote:
  
   Yeah, the filename opens perfectly in a browser.  I've
  tried
   it
   both
  with
   a patternlayout and with the xmllayout, the xmllayout
   never
   says
   Connected
   in zero conf.  Right now I'm using a complete copy and
  paste
   of
the
   config
   file you put in SO.
  
   I do see a receiver listed, and I can right click to
 tell
  it
   I'd
   like
   to
   see trace, but that's all I can get it to do.
  Restarting
   the
 receiver
   doesn't seem to do anything.  Double clicking does
   nothing.
  
   --M@
  
   On Fri, May 10, 2013 at 2:07 PM, Scott Deboy
   scott.de...@gmail.comwrote:
  
   When Chainsaw starts you don't need to give it a
 config,
  as
   the
   config
   will be generated once the advertisement is
   discovered.
  
   If you have a row in ZeroConf with your appender
   name,
   that's

[jira] [Created] (LOG4J2-251) Support advertisement of configuration text

[Scott Deboy (JIRA)]

Scott Deboy created LOG4J2-251:
--

 Summary: Support advertisement of configuration text
 Key: LOG4J2-251
 URL: https://issues.apache.org/jira/browse/LOG4J2-251
 Project: Log4j 2
  Issue Type: Improvement
Reporter: Scott Deboy
Assignee: Scott Deboy


It may be useful to support advertisement of the configuration itself, either 
json or xml.

The advertiser map should provide:
contentType (application/json or text/xml)
content (the actual configuration text)
name (configuration)

--
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-251) Support advertisement of configuration text

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653540#comment-13653540
 ] 

Scott Deboy commented on LOG4J2-251:


Advertising the configuration at the end of baseconfiguration subclasses of 
setup (called from start)

Overriding stop in the baseconfiguration subclasses which advertise the 
configuration so that the configuration can be 'unadvertised' (and 
reconfiguration/subsequent start will advertise the new configuration).

 Support advertisement of configuration text
 ---

 Key: LOG4J2-251
 URL: https://issues.apache.org/jira/browse/LOG4J2-251
 Project: Log4j 2
  Issue Type: Improvement
Reporter: Scott Deboy
Assignee: Scott Deboy

 It may be useful to support advertisement of the configuration itself, either 
 json or xml.
 The advertiser map should provide:
 contentType (application/json or text/xml)
 content (the actual configuration text)
 name (configuration)

--
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-251) Support advertisement of configuration text

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653574#comment-13653574
 ] 

Scott Deboy commented on LOG4J2-251:


Expose the XML or JSON configuration text via the Advertiser mechanism.

MulticastDNSAdvertiser has a limit of 255 bytes for labels and values.  If an 
entry is greater than 255 bytes, the entry is now removed prior to publishing.

The log4j configuration content was exceeding this limit.  This limit is 
specific to Multicast DNS.

Added a 'location' key, with the location (file path) if it is available


 Support advertisement of configuration text
 ---

 Key: LOG4J2-251
 URL: https://issues.apache.org/jira/browse/LOG4J2-251
 Project: Log4j 2
  Issue Type: Improvement
Reporter: Scott Deboy
Assignee: Scott Deboy

 It may be useful to support advertisement of the configuration itself, either 
 json or xml.
 The advertiser map should provide:
 contentType (application/json or text/xml)
 content (the actual configuration text)
 name (configuration)

--
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-235) Dependency on tools.jar and jconsole

[Scott Deboy (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648203#comment-13648203
 ] 

Scott Deboy commented on LOG4J2-235:


Is it fair to say 'gui related things' are a bridge-too-far when it comes to 
core? Pretty much everything else that's optional is fair game?  I'd be ok with 
that.

 Dependency on tools.jar and jconsole
 

 Key: LOG4J2-235
 URL: https://issues.apache.org/jira/browse/LOG4J2-235
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0-beta5
 Environment: Windows 7, 64 bit, Maven 3.0.5, Java 1.6
Reporter: Sebastian Oerding

 Hello,
 when switching from 2.0-beta4 to 2.0-beta5 I something irritating that in the 
 dependency hierarchy of my project. For log4j2-core there were transitive 
 dependencies on tools.jar and jsconsole which had not been there.
 This looks like a bug and an as a consequence requires a JDK instead of  a 
 JRE (at least due to the tools.jar which does not exist in Java 1.6 JRE). If 
 these dependencies are really required, it should be clearly stated.

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