November 2008 - logback-dev

[JIRA] Created: (LBCORE-62) Dinimish contention among concurrent threads when using logback
by Ceki Gulcu (JIRA) 26 Jun '09

26 Jun '09

Dinimish contention among concurrent threads when using logback --------------------------------------------------------------- Key: LBCORE-62 URL: http://jira.qos.ch/browse/LBCORE-62 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.9 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Fix For: 0.9.10 We should strive to diminish interference among concurrent threads when using logback. -- 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 1

[JIRA] Created: (LBCORE-65) Better documentation on Joran
by Ceki Gulcu (JIRA) 04 Feb '09

04 Feb '09

Better documentation on Joran ----------------------------- Key: LBCORE-65 URL: http://jira.qos.ch/browse/LBCORE-65 Project: logback-core Issue Type: Task Components: Joran Affects Versions: 0.9.10 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Joran should be better documented -- 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 3

[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: (LBSITE-22) Invalid log levels for Logger interface from SLF4J in logback doc
by Grzegorz Borkowski (JIRA) 30 Dec '08

30 Dec '08

Invalid log levels for Logger interface from SLF4J in logback doc ----------------------------------------------------------------- Key: LBSITE-22 URL: http://jira.qos.ch/browse/LBSITE-22 Project: logback-site Issue Type: Bug Components: Documentation Reporter: Grzegorz Borkowski Assignee: Logback dev list Priority: Minor On the page http://logback.qos.ch/manual/architecture.html there the section describing SLF4J Logger API: package org.slf4j; public interface Logger { // Printing methods: public void debug(String message); public void info(String message); public void warn(String message); public void error(String message); public void fatal(String message); } As you see, the method names are invalid: there is no "fatal" level in SLF4J. Also "trace" is missing. -- 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: (LBCLASSIC-85) Multiply logback.xml files on the classpath, the first one will be used without notification
by Szel Zoltan (JIRA) 29 Dec '08

29 Dec '08

Multiply logback.xml files on the classpath, the first one will be used without notification -------------------------------------------------------------------------------------------- Key: LBCLASSIC-85 URL: http://jira.qos.ch/browse/LBCLASSIC-85 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.11 Reporter: Szel Zoltan Assignee: Logback dev list Hi all, i have hit this issue a couple of times now, so i go ahead and rise it. We are creating libraries to our developers, which are usually have an example part, where they can try our piece of software out. These examples are part of our Eclipse project. All these examples have a logback.xml file to show how a complete application should look like. During development, this causes some issues because the first one in the classpath will be loaded, so i ended up to use the manual config loading via Joran, but it took me some time to figure out the root cause of the issue. I imagine, this will cause issues when developers will start to bundle there logback.xml file into there jars. Could the ContextInitializer be changed to detect such a scenario and report it? The change is fairly easy, instead of using the getResource(String name) function from the ClassLoader class, you could go with the getResources(String name) function, check if it returned more than one element, than report to the Status manager the fact, that there are more than 1 logback.xml file on the classpath and the first one will be used. Thanks in advance, Kind 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-69) SMTPAppenderBase: Allow to select charset encoding for email's subject and body
by Andrey Rybin (JIRA) 29 Dec '08

29 Dec '08

SMTPAppenderBase: Allow to select charset encoding for email's subject and body ------------------------------------------------------------------------------- Key: LBCORE-69 URL: http://jira.qos.ch/browse/LBCORE-69 Project: logback-core Issue Type: Improvement Components: Appender Reporter: Andrey Rybin Assignee: Logback dev list Please add String charsetEncoding property to SMTPAppenderBase and use it for email's subject and content encoding. Now javaMail default charset encoding is used so only ASCII latin characters can be used in log messages. For example my fix for log4j SMTPAppender: + private String charsetEncoding = "UTF-8"; public void activateOptions () { .. addressMessage(msg); if (getSubject() != null) { ((MimeMessage)msg).setSubject(getSubject(), charsetEncoding); //fix1. Cast looks ugly, but as we always create MimeMessage above, it's ok } /*** Send the contents of the cyclic buffer as an e-mail message. */ @Override protected void sendBuffer () { /* Note: this code already owns the monitor for this appender. This frees us from needing to synchronize on 'cb'. */ try { final MimeBodyPart part = new MimeBodyPart(); final StringBuilder sb = new StringBuilder(); String t = layout.getHeader(); if (t != null) { sb.append(t); } //add header final int len = cb.length(); for (int i = 0; i < len; i++) { final LoggingEvent event = cb.get(); sb.append(layout.format(event)); if (layout.ignoresThrowable()) { final String[] s = event.getThrowableStrRep(); if (s != null) { for (int j = 0; j < s.length; j++) { sb.append(s[j]).append(Layout.LINE_SEP); }//for }//if }//if }//for t = layout.getFooter(); if (t != null) { sb.append(t); } //fix2: t = layout.getContentType(); if (t.startsWith("text/")) { part.setText(sb.toString(), charsetEncoding, t.substring(5)); //remove 'text/' from contentType cause javaMail needs here only subtype (html, plain, etc) } else { part.setContent(sb.toString(), t); //for non text chartset isn't needed }//if final Multipart mp = new MimeMultipart(); mp.addBodyPart(part); msg.setContent(mp); msg.setSentDate(new Date()); Transport.send(msg); } catch (Exception e) { LogLog.error("sendBuffer: Error occured while sending e-mail notification from "+getFrom()+" to "+getTo(), e); }//try }//sendBuffer -- 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: (LBCORE-74) Converters do not work in all appenders
by Natan Cox (JIRA) 28 Dec '08

28 Dec '08

Converters do not work in all appenders --------------------------------------- Key: LBCORE-74 URL: http://jira.qos.ch/browse/LBCORE-74 Project: logback-core Issue Type: Improvement Components: Pattern Affects Versions: 0.9.11 Reporter: Natan Cox Assignee: Logback dev list I'm trying to use a converter in HtmlLayout but it was not logged correctly. I'm basically getting a "PARSER_ERRER". I checked the code and found HTMLLayoutBase.start() does this.head = p.compile(t, getDefaultConverterMap()); where protected Map<String, String> getDefaultConverterMap() { return PatternLayout.defaultConverterMap; } But PatternLayoutBase.start() does this.head = p.compile(t, getEffectiveConverterMap()); and getEffectiveConverterMap loads the extra converters. This is probably in issue in other Appenders too. Maybe the solution can be generified to make it work for every appender? -- 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