February 2011 - logback-dev

[JIRA] Created: (LBCLASSIC-116) SyslogAppender should support RFC 5424
by Ralph Goers (JIRA) 16 Aug '11

16 Aug '11

SyslogAppender should support RFC 5424 -------------------------------------- Key: LBCLASSIC-116 URL: http://jira.qos.ch/browse/LBCLASSIC-116 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.16 Environment: All Reporter: Ralph Goers Assignee: Logback dev list The SyslogAppender supports RFC 3164. RFC 5424 has been released with obsoletes RFC 3164. See http://www.ietf.org/rfc/rfc5424.txt. At the very least the format of the timestamp has been changed. Either the SyslogAppender should be enhanced to comply with RFC 5424 or a new SyslogAppender should be created which does. -- 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 19

[JIRA] Created: (LBCLASSIC-146) SysLog Appender and Line Breaks = :(
by Ingo Siebert (JIRA) 16 Aug '11

16 Aug '11

SysLog Appender and Line Breaks = :( -------------------------------------- Key: LBCLASSIC-146 URL: http://jira.qos.ch/browse/LBCLASSIC-146 Project: logback-classic Issue Type: Bug Components: appender Environment: Debian 4 Etch, 64 Bit (most likely all enviroments) Reporter: Ingo Siebert Assignee: Logback dev list I'm using the SysLog appender and it works well. But I've problems with line breaks, especially for exceptions. Every strack trace line is written as new SysLog-Entry. Example: Aug 11 20:25:21 192.168.33.11 app2-cas org.osgi.framework.BundleException: The bundle class path entry "patch.jar"..." Aug 11 20:25:21 192.168.33.11 app2-cas ^Iat org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassPathEntry(ClasspathManager.java:168) Aug 11 20:25:21 192.168.33.11 app2-cas ^Iat org.eclipse.osgi.baseadaptor.loader.ClasspathManager.buildClasspath(ClasspathManager.java:145) Aug 11 20:25:21 192.168.33.11 app2-cas ^Iat org.eclipse.osgi.baseadaptor.loader.ClasspathManager.initialize(ClasspathManager.java:79) ... That's quire annoying if you want to filter or highlight entries. I think it's major, because there isn't a good workaround to filter/highlight syslog files. I'm using Logback 0.9.13, but I thinks it still exists in the trunk. -- 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

4 4

[JIRA] Created: (LBCLASSIC-247) ConfigurationWatchList produces a warinig a correct configuration
by Michael Franz (JIRA) 16 Jun '11

16 Jun '11

ConfigurationWatchList produces a warinig a correct configuration ----------------------------------------------------------------- Key: LBCLASSIC-247 URL: http://jira.qos.ch/browse/LBCLASSIC-247 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: 0.9.28 Reporter: Michael Franz Assignee: Logback dev list I get the following warning for included files: 12:09:40,657 |-WARN in ch.qos.logback.core.joran.util.ConfigurationWatchListUtil@7c959fa1 - Null ConfigurationWatchList. Cannot add file:/D:/dev/.../logback-lilith.xml Scanning is off. I configure logback in the following way: JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(loggerContext); loggerContext.reset(); configurator.doConfigure(new ByteArrayInputStream(config.getBytes("UTF-8"))); The generated main configuration (variable config) contains mainly includes to files within the file system. -- 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 8

[JIRA] Created: (LBCLASSIC-82) Allow an Appender to be added to a Logger with a Level for more fine grained control of logging output
by Robert Elliot (JIRA) 20 May '11

20 May '11

Allow an Appender to be added to a Logger with a Level for more fine grained control of logging output ------------------------------------------------------------------------------------------------------ Key: LBCLASSIC-82 URL: http://jira.qos.ch/browse/LBCLASSIC-82 Project: logback-classic Issue Type: New Feature Components: appender, joran Environment: N/A Reporter: Robert Elliot Assignee: Logback dev list Priority: Minor Here's my use case: I have an appender, standard.log, whose job is to log major system events such as startup and shutdown, and all problems. I have configured my logger levels very carefully to ensure I get exactly the output I want - in some cases suppressing WARN messages that I know are not a problem by setting the level to ERROR, in some cases allowing INFO messages that let me see important lifecycle events. A simplified example might look like this: root=WARN,standard.log x.y=INFO a=ERROR I have a problem in a couple of parts of the system which means I want to turn on debug logging for that part of the system. I want the output of this to go to a separate appender - debug.log. So now my config looks like this: root=WARN,standard.log x.y=INFO x.y.z=DEBUG,debug.log a=ERROR a.b=DEBUG,debug.log But now I have an issue; all my debug statements are going to standard.log. It is being polluted with a load of information I don't want in it. I have several options: 1) Set additivity to false on x.y.z and a.b. But then any ERROR messages in a.b or INFO or above messages in x.y.z no longer get to standard.log, so this won't do 2) Add a filter of INFO or greater to the standard.log appender But then any INFO and WARN messages in a.b will get to standard.log - and I only want ERROR messages from a and its descendants in there 3) Add a filter of WARN or greater to the standard.log appender Now I still get the WARN messages from a.b that I don't want - and I've lost the INFO messages from x.y that I do want 4) Create two new appenders, standard.log2 for a and standard.log3 for x.y.z. Add a filter to standard.log2 so that it only accepts ERROR. Add a filter to standard.log3 so it only accepts INFO or above. Set additivity to false on a and x.y.z. That works. But it's a huge amount of added configuration, and that would rapidly multiply in a real world setting. 5) Create a custom filter for standard.log which would effectively mirror the logger config by querying the event for its logger and and level. That blows DRY out of the water, of course, and again is a large amount of work for a simple use case. My suggestion to make this easy is to allow Appenders to be added to a Logger with a Level. This solution would operate in parallel with the existing solution, and would not alter the existing behaviour one iota. This would allow me to add debug,log as an appender on a and x.y.z with a level of debug. All debug statements in a and x.y.z & their descendants would be appended to that appender. All statements would also be passed to the "normal" appender and logger hierarchy, so standard.log would still get the same output as before. I have written unit tests for this behaviour and attach a patch fulfilling them; I hope the unit tests flesh out any queries you may have around how this behaves in edge cases. The only change to the public API is a new method addAppender(Appender<LoggingEvent> newAppender, Level level) on Logger. The only change to the config format is allowing an optional level attribute on appender-ref. -- 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 6

[JIRA] Created: (LBCORE-168) Locking issues when prudent logging to a (windows) clustered storage device on owner-switch
by alex (JIRA) 08 Apr '11

08 Apr '11

Locking issues when prudent logging to a (windows) clustered storage device on owner-switch ------------------------------------------------------------------------------------------- Key: LBCORE-168 URL: http://jira.qos.ch/browse/LBCORE-168 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.24 Environment: Windows Server 2003 Enterprise edition Reporter: alex Assignee: Logback dev list Priority: Blocker We have a clustered windows environment (2 nodes) and each node is logging to the same file which is stored on a clustered storage device (prudent is set to true) Logging works great until we switch the owner of the storage device where the logs are being written to at which point one of two things happens: - one or both servers go into a sort of deadlock state, meaning the code that logs just hangs indefinatly. it seems the safeWrite() in FileAppender may be to blame because of the "lock()" statement (note that a jvm reboot will fix this problem). I have been able to reproduce this locked state and verify that it is the lock() by trying to get a lock on the log file in the same jvm but without using logback code. This code will hang as well. - if there is no deadlock, any log written after the switch will just vanish into thin air (I have no idea where the outputstream points to when you start switching the owner) I have no idea how this can be fixed without resorting to a reload/reboot of our servers (which is not an option in production). We used to log synchronously, but then each thread that called logback would hang resulting in a massive amount of idling threads, so now we log asynchronously (this was already an option in the system we built around it) which gives us one advantage: we never write concurrently to the same file, although different nodes may write serially. As a temporary work around I am thinking to implement a simple appender that opens/closes the outputstream for each write (performance is less of an issue) and that does not implement locking. -- 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 4

[JIRA] Created: (LBACCESS-12) Please add IAccessEvent (and AccessEventVO) similar to the LoggingEvent counterparts
by Joern Huxhorn (JIRA) 28 Mar '11

28 Mar '11

Please add IAccessEvent (and AccessEventVO) similar to the LoggingEvent counterparts ------------------------------------------------------------------------------------ Key: LBACCESS-12 URL: http://jira.qos.ch/browse/LBACCESS-12 Project: logback-access Issue Type: Improvement Affects Versions: 0.9.20 Reporter: Joern Huxhorn Assignee: Logback dev list I'm currently implementing "cat" functionality for Lilith data files, i.e. events stored in Lilith data files can be printed using ch.qos.logback.classic.PatternLayout and ch.qos.logback.access.PatternLayout. This works for LoggingEvent since I could implement a iLoggingEvent wrapper for my own LoggingEvent. It does not work for AccessEvent, though, because there is no IAccessEvent interface and I can't instantiate AccessEvent and set the properties manually. ch.qos.logback.access.PatternLayout is currently working on an AccessEvent and I'd like to use it's functionality. -- 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 6

[JIRA] Created: (LBCLASSIC-156) SocketAppender is reporting an WARN if connection could not be established.
by Joern Huxhorn (JIRA) 28 Mar '11

28 Mar '11

SocketAppender is reporting an WARN if connection could not be established. --------------------------------------------------------------------------- Key: LBCLASSIC-156 URL: http://jira.qos.ch/browse/LBCLASSIC-156 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.917 Environment: java version "1.6.0_15" Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) Reporter: Joern Huxhorn Assignee: Logback dev list This is a followup to LBCLASSIC-143 which changed the message from ERROR to WARN. The WARN message still results in a dump of the logging status messages. This means that a whole bunch of text is printed to the console whenever Lilith is started - and it looks quite broken due to the stacktrace. So there are two possible solutions for this problem: a) the status is only printed in case of an ERROR b) SocketAppender considers this as an INFO instead of a WARN. I think b) would be reasonable. Other WARNs are much more important, like duplicate logback.xml. Lilith is only an example, btw. We routinely add SocketAppender[localhost] to our console applications. In case of trouble one can simply start Lilith and check the logs that way instead of reading them on the console. The default use-case is executing the app without Lilith, though, so we get the logback status messages on every start - which is quite noisy and annoying. -- 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 5

[JIRA] Created: (LBCORE-166) RenameUtil not truncating file if delete fails during rollover
by Jose David Barrio (JIRA) 18 Mar '11

18 Mar '11

RenameUtil not truncating file if delete fails during rollover -------------------------------------------------------------- Key: LBCORE-166 URL: http://jira.qos.ch/browse/LBCORE-166 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Environment: Microsoft Windows XP SP2 OAS 10.1.3.4 Java 1.5.0_14 Reporter: Jose David Barrio Assignee: Logback dev list Priority: Minor Attachments: RenameUtil.patch When using logback under Windows over Oracle Application Server, if you redeploy the web application, the log file is keep open by some reason so when a new rollover happens it fails to rename the log file. Currently RenameUtil does: - Try to rename log file. - If rename fails then rename by copy (copy plus delete). If for some reason deletion fails the log file keeps all its content so I just added a truncate if deletion fails: - Try to rename log file. - If rename fails then rename by copy (copy plus delete). - If delete fails then truncate file. I do have a patch file if it's useful. -- 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 7

[JIRA] Created: (LBCLASSIC-246) Strange new error message during application startup with 0.9.28
by Joern Huxhorn (JIRA) 05 Mar '11

05 Mar '11

Strange new error message during application startup with 0.9.28 ---------------------------------------------------------------- Key: LBCLASSIC-246 URL: http://jira.qos.ch/browse/LBCLASSIC-246 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100) Java version: 1.6.0_22, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", version: "10.6.6", arch: "x86_64", family: "mac" Reporter: Joern Huxhorn Assignee: Logback dev list Priority: Critical An error message like this is emitted upon startup of an application that contains the logback.xml in one of its jars: 15:36:20,346 |-ERROR in ch.qos.logback.core.joran.spi.ConfigurationWatchList@47ad6b4b - URL [jar:file:/path/to.jar!/logback.xml] is not of type file This started with Logback 0.9.28 and I guess (!!) it's a side-effect of the LBCLASSIC-245 fix... The logback.xml file in question does not have scan activated, btw. -- 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

4 7

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.28-15-g99c1d18
by git-noreply＠pixie.qos.ch 26 Feb '11

26 Feb '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 99c1d187135cc986de48b040e1e20a8d9d546e6a (commit) from 2e4e829c8e024fa5c51009ba0b507633f5e1adff (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=99c1d187135cc986de48b040… http://github.com/ceki/logback/commit/99c1d187135cc986de48b040e1e20a8d9d546… commit 99c1d187135cc986de48b040e1e20a8d9d546e6a Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sat Feb 26 17:33:30 2011 +0100 editorial changes diff --git a/logback-site/src/site/pages/css/screen.css b/logback-site/src/site/pages/css/screen.css index d2cc84b..b300b22 100644 --- a/logback-site/src/site/pages/css/screen.css +++ b/logback-site/src/site/pages/css/screen.css @@ -23,6 +23,14 @@ body { } +#job img { + border:1px solid #DDDDDD; +} + +#job:hover img { + border:1px solid #8888EE; +} + p.menu { padding-top: 0px; padding-bottom: 0px; diff --git a/logback-site/src/site/pages/job.html b/logback-site/src/site/pages/job.html index cf8164d..b11ca11 100644 --- a/logback-site/src/site/pages/job.html +++ b/logback-site/src/site/pages/job.html @@ -33,38 +33,39 @@ <div id="content"> + <h2>Développeur Java</h2> <p>QoS.ch, ou Quality Open Software, est une société de conception - et de développement informatique basée à Lausanne (en Suisse).</p> + et de développement informatique basée à Lausanne - Suisse.</p> <p>Nous avons une grande expérience dans la réalisation de logiciels d'entreprise en langage Java. Nous sommes également fondateurs ou contributeurs actifs dans plusieurs projets open - source, notamment log4j, SLF4J et Logback. + source, notamment cal10n, logback, log4j, mistletoe et SLF4J. </p> <p>Afin de compléter notre équipe de développeurs pour la réalisation de divers projets, autant open source que pour répondre aux demandes de nos clients, nous recherchons un très bon - développeur. Dans un premier temps, vous serez emmené à travailler + développeur. Dans un premier temps vous serez emmené à travailler sur les projets slf4j et logback. </p> - <h3>Connaissances indispensables:</h3> + <h3>Connaissances souhaitables:</h3> <ul> - <li>Formation universitaire ou jugée équivalente</li> - <li>Bonne expérience en programmation orienté objet, de préférence Java</li> - <li>Bonnes connaissances de développement Web, e.g. Struts, - Wicket, JSF, ou Trapestry</li> + <li>Bonne expérience de programmation orienté objet, de préférence Java</li> + <li>Connaissances de développement Web avec des outils tels que + Struts, Wicket ou Tapestry</li> <li>Affinité pour les méthodologies agiles, en particulier le TDD</li> </ul> <h3>Votre profil:</h3> <ul> + <li>Formation universitaire ou jugée équivalente</li> <li>Grande capacité d'analyse et d'apprentissage</li> <li>Autonome et enthousiaste dans le développement</li> <li>Intérêt marqué pour le développement collaboratif</li> @@ -76,9 +77,9 @@ profit vos aptitudes, nous vous proposons un environnement dynamique et évolutif avec des conditions avantageuses.</p> - <p>Merci de nous adresser votre dossier de candidature et si - possible d'une liste des projets sur lesquels vous avez - participés, par email à l'adresse email suivante: hr(a)qos.ch. + <p>Merci de nous adresser votre dossier de candidature par email à + l'adresse hr(a)qos.ch. Si possible joignez une liste des projets + auxquels vous avez participé. </p> <script src="templates/footer.js" type="text/javascript"></script> diff --git a/logback-site/src/site/pages/templates/header.js b/logback-site/src/site/pages/templates/header.js index bf5af63..23c86d8 100644 --- a/logback-site/src/site/pages/templates/header.js +++ b/logback-site/src/site/pages/templates/header.js @@ -3,7 +3,7 @@ document.write('<td><a href="http://logback.qos.ch/">'); document.write('<img src="' + prefix + 'images/logos/lblogo.jpg" alt="" border="0"/>'); document.write('</a></td>') -document.write('<td align="right"><a href="http://logback.qos.ch/job.html">'); +document.write('<td align="right"><a id="job" href="http://logback.qos.ch/job.html">'); document.write('<img src="' + prefix + 'images/myjob.png" alt="" border="0"/>'); document.write('</a></td>') document.write('</tr></table>') ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/css/screen.css | 8 ++++++++ logback-site/src/site/pages/job.html | 23 ++++++++++++----------- logback-site/src/site/pages/templates/header.js | 2 +- 3 files changed, 21 insertions(+), 12 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0