October 2008 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-66) Document the valueOf convention
by Ceki Gulcu (JIRA) 04 Feb '09

04 Feb '09

Document the valueOf convention ------------------------------- Key: LBCORE-66 URL: http://jira.qos.ch/browse/LBCORE-66 Project: logback-core Issue Type: Sub-task Components: Joran Reporter: Ceki Gulcu Assignee: Logback dev list Joran now assumes that any class which has a static valueOf method taking a String as an argument can be built from a string. Level, Duration and FileSize classes follow this convention. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2

[JIRA] Created: (LBCORE-68) Add a pattern resolver to <file> property of FileAppnder
by Nicolas Giraud (JIRA) 03 Feb '09

03 Feb '09

Add a pattern resolver to <file> property of FileAppnder -------------------------------------------------------- Key: LBCORE-68 URL: http://jira.qos.ch/browse/LBCORE-68 Project: logback-core Issue Type: New Feature Components: Appender, Joran Affects Versions: 0.9.11 Environment: Ubuntu 8.04, J2SE 6 Reporter: Nicolas Giraud Assignee: Logback dev list Following discussion on the mailing list, it would be very convenient to be able to use patterns in the filename of a FileAppender. My initial expectation was to be able to do something like: <appender name="myFileAppender" class="ch.qos.logback.core.FileAppender"> <file>${logFolder}/SomePrefix.%d.someExt</file> [...] </appender> where %d would be substituted by the current date. However Ralph Goers, when replying to my question on the mailing list, suggested a more flexibl approach: <appender name="myFileAppender" class="ch.qos.logback.core.FileAppender"> <File resolver="com.mycorp.logback.MyPatternResolver">someName.%{host}.%{datetime}.log</File> [...] </appender> with MyPatternResolver implementing an interface like: package ch.qos.logback.core.pattern; public interface Resolver { String resolve(String pattern); } Providing a default implementation allowing to generate timestamp, use system properties, would be nice too. Currently this can be done programmatically, but it would be most convenient to have the possibility to do this using the Joran configurator. Best regards, Nicolas -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 1

[JIRA] Created: (LBSITE-20) Logback autoconfiguration documentation is misleading
by Szel Zoltan (JIRA) 30 Dec '08

30 Dec '08

Logback autoconfiguration documentation is misleading ----------------------------------------------------- Key: LBSITE-20 URL: http://jira.qos.ch/browse/LBSITE-20 Project: logback-site Issue Type: Bug Components: Documentation Affects Versions: 0.9.9, 0.9.10 Reporter: Szel Zoltan Assignee: Logback dev list Priority: Minor Hello all, we have hit this problem a couple of times so i think it worth rising it. The Logback documentation about autoconfiguration says: Logback tries to find a file called logback-test.xml in the classpath. If no such file is found, it checks for the file logback.xml. In case neither file is found, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed on the console. This is very misleading, one might think he/she can put the logback.xml file anywhere in the classpath but Logback will find it only if it is in the top of the classpath(e.g.: right under the packages folder). Could you please fix the docs? Best regards, Zoltan Szel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBCORE-51) LoggerFactory doesnt respect custom ContextSelector
by Paul Gregoire (JIRA) 28 Dec '08

28 Dec '08

LoggerFactory doesnt respect custom ContextSelector --------------------------------------------------- Key: LBCORE-51 URL: http://jira.qos.ch/browse/LBCORE-51 Project: logback-core Issue Type: Bug Environment: Windows XP64, Java 6, Red5 v0.7.1-dev, Logback 0.9.9, Slf4j 1.5.0 Reporter: Paul Gregoire Assignee: Logback dev list I have found that calling LoggerFactory.getLogger(xxxx) does not make calls to my custom context selector. I expect to see a call to getLoggerContext() but I dont. Do I need to create my own LoggerFactory impl to get my web context apps and red5 apps to use their own Loggers? Main Red5 trunk (dev) http://svn1.cvsdude.com/osflash/red5/java/server/trunk/ My logger implementations http://svn1.cvsdude.com/osflash/red5/java/server/trunk/src/org/red5/logging/ Example JSP I used to test the log context selection <%@page import="org.slf4j.Logger,org.slf4j.LoggerFactory,org.slf4j.impl.StaticLoggerBinder,ch.qos.logback.classic.LoggerContext,org.red5.logging.LoggingContextSelector"%> <html> <body> <% // Logger log = LoggerFactory.getLogger("TestJsp"); log.info("This is a test log entry from a web context"); // LoggingContextSelector selector = (LoggingContextSelector) StaticLoggerBinder.SINGLETON.getContextSelector(); LoggerContext ctx = selector.getLoggerContext(mywebappcontextname); Logger log2 = ctx.getLogger("TestJsp"); log2.info("This is a test log entry from a web context attempt 2"); %> </body> </html> The first log goes to the "default" logger context and the second goes to the correct one. I also implemented the Servlet filter and context listener for this tested context. Anything I can do to help, please let me know.. I am getting extremely frustrated with this logging stuff and I'm sure our users are as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 13

[JIRA] Created: (LBSITE-19) name-attribute is *not* mentioned in your CounterBasedEvaluator example
by Ceki Gulcu (JIRA) 27 Dec '08

27 Dec '08

name-attribute is *not* mentioned in your CounterBasedEvaluator example ----------------------------------------------------------------------- Key: LBSITE-19 URL: http://jira.qos.ch/browse/LBSITE-19 Project: logback-site Issue Type: Bug Affects Versions: 0.9.9 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Fix For: 0.9.10 See http://www.qos.ch/pipermail/logback-user/2008-October/000661.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 4

[JIRA] Created: (LBCLASSIC-73) LevelFilter should not match exact filter, but greaterOrEqual
by Bruno Navert (JIRA) 03 Dec '08

03 Dec '08

LevelFilter should not match exact filter, but greaterOrEqual ------------------------------------------------------------- Key: LBCLASSIC-73 URL: http://jira.qos.ch/browse/LBCLASSIC-73 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.9 Reporter: Bruno Navert Assignee: Logback dev list Priority: Minor LevelFilter currently matches EXACT level, it would be useful to match on greaterOrEqual instead. This would allow setting filter to DEBUG for instance, and it would allow INFO,ERROR etc through -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3

[JIRA] Created: (LBCORE-67) Unsecure usage of locks in AppenderAttachableImpl
by Joern Huxhorn (JIRA) 03 Dec '08

03 Dec '08

Unsecure usage of locks in AppenderAttachableImpl ------------------------------------------------- Key: LBCORE-67 URL: http://jira.qos.ch/browse/LBCORE-67 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.10 Reporter: Joern Huxhorn Assignee: Logback dev list Attachments: LockPatch.patch The unlock of a lock should, I would even say "must", always be done in a finally block. Otherwise really bad things (deadlock) can happen if an exception is thrown. See http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 11

[JIRA] Created: (LBGENERAL-22) problem converting log4j.properties file
by Ceki Gulcu (JIRA) 02 Dec '08

02 Dec '08

problem converting log4j.properties file ---------------------------------------- Key: LBGENERAL-22 URL: http://jira.qos.ch/browse/LBGENERAL-22 Project: logback-general Issue Type: Bug Reporter: Ceki Gulcu Assignee: Logback dev list Rob Ross wrote: I have a few comments for you. First, the log4j properties translator ( http://logback.qos.ch/translator/Welcome.do ) does not quite work. Maybe it's based on an old version and is now out of date, but you should think about updating it. The file it produced did not translate my properties that I used in log4j.properties to specify the log file path into the equivalent substitutionProperty elements, and it did not translate the Levels I had set on the log4j appenders. It did wrap them in Threshold elements, but the current XML schema wants these specified in a "filter" element on the appender. Also, it did not translate the settings for the rolling file appender into the FileNamePattern element. However, the Joran configurator gave me detailed enough Exception messages that it was easy to determine what the problems were and fix them. ref: http://www.qos.ch/pipermail/logback-user/2008-July/000492.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2

Least-effort logging with bytecode modification
by Ramon Nogueira 18 Nov '08

18 Nov '08

Hi At the company I work for we use the same logging pattern almost everywhere, for example: public class SomeClass { private static final Logger log = LoggerFactory.getLogger(SomeClass.class); public void someMethod() { log.debug("A log message"); } } I would like to simplify this to: import static logging.LogApi.*; public class SomeClass { private void someMethod(String someArg) { debug("A log message"); // from static import } } And then have code equivalent to the former generated (preferably at class load time) dynamically. This could save us hundreds of lines of boilerplate code and provide other interesting options like declarative rules regarding the "injected" logger name, perhaps through class/method annotations and pre-calculating the source location information. I thought of implementing this with AspectJ but its probably easier to just use ASM directly for such a simple case. Any ideas/suggestions/precedents? Thanks Ramon

9 22

[JIRA] Created: (LBCLASSIC-78) NullPointerException in JMX Configurator getLoggerLevel
by Jean-Luc Geering (JIRA) 17 Nov '08

17 Nov '08

NullPointerException in JMX Configurator getLoggerLevel ------------------------------------------------------- Key: LBCLASSIC-78 URL: http://jira.qos.ch/browse/LBCLASSIC-78 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.11 Reporter: Jean-Luc Geering Assignee: Logback dev list NullPointerException in JMX Configurator getLoggerLevel: on line 111, logger.getLevel() can be null. in ch.qos.logback.classic.jmx.Configurator, lines 110 - 114, replace if (logger != null) { return logger.getLevel().toString(); } else { return EMPTY; } with if (logger != null && logger.getLevel() != null) { return logger.getLevel().toString(); } else { return EMPTY; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2