- logback-dev - mailman3.qos.ch

http://logback.qos.ch/manual/configuration.html#loggerElement something wrong
by zuxiong lin 24 Aug '11

24 Aug '11

http://logback.qos.ch/manual/configuration.html#loggerElement Configuring loggers, or the <logger> element<http://logback.qos.ch/manual/configuration.html#loggerElement> each appender thus referenced is added to the named logger. Note that unlike log4j, logback-classic does not close or remove any previously referenced appenders before adding the new appender reference. In log4j version 1.2.16 , any previously referenced appenders are valid. <logger name="classlogger" additivity="false"> <level value="INFO" /> <appender-ref ref="MYINFO_FILE" /> <appender-ref ref="DEBUG" /> </logger> So, the manual is wrong.

1 0

[JIRA] Created: (LBCLASSIC-287) ThrowableProxy keeps common frames of cause-hierarchy
by Joern Huxhorn (JIRA) 23 Aug '11

23 Aug '11

ThrowableProxy keeps common frames of cause-hierarchy ----------------------------------------------------- Key: LBCLASSIC-287 URL: http://jira.qos.ch/browse/LBCLASSIC-287 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.29 Reporter: Joern Huxhorn Assignee: Logback dev list The ThrowableProxy implementation is currently merely calculating the number of common frames but keeps the common frames of the cause stacktraces anyway. Wouldn't it make sense to remove the common stack trace elements of cause (and suppressed) exceptions before they are processed any further? This would reduce the size of the event upon transport and would probably also simplify calculation of packaging data. -- 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 0

[JIRA] Created: (LBCLASSIC-286) Allow Threshold Filter to filter out levels above provided level
by Robert Elliot (JIRA) 22 Aug '11

22 Aug '11

Allow Threshold Filter to filter out levels above provided level ---------------------------------------------------------------- Key: LBCLASSIC-286 URL: http://jira.qos.ch/browse/LBCLASSIC-286 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: 0.9.30 Reporter: Robert Elliot Assignee: Logback dev list Priority: Minor It would be nice if a property could make the existing ThresholdFilter act in the opposite way - so that it response with NEUTRAL to levels equal to or _below_ the configured level, instead of equal to or above it. This would mean you could use two appenders with ThresholdFilters to split logging between error/warn on the one hand and info/debug/trace on the other, for instance. A new property (perhaps "revers"?) could be created with a default value of false and it would be backward compatible. (It's trivial to do yourself, of course, but it would be nice to have out of the box.) -- 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 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.29-17-g0ef4726
by git-noreply＠pixie.qos.ch 17 Aug '11

17 Aug '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 0ef4726a00390c62ef346ebfdd9673a8d4df4944 (commit) from 707298f12c4d6a5ae392a0c2c5bb488cbcc4f8ef (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=0ef4726a00390c62ef346ebf… http://github.com/ceki/logback/commit/0ef4726a00390c62ef346ebfdd9673a8d4df4… commit 0ef4726a00390c62ef346ebfdd9673a8d4df4944 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Aug 17 14:03:31 2011 +0200 typo fixes diff --git a/logback-site/src/site/pages/access.html b/logback-site/src/site/pages/access.html index 057d8c9..eba8f76 100644 --- a/logback-site/src/site/pages/access.html +++ b/logback-site/src/site/pages/access.html @@ -40,12 +40,12 @@ without much recoding was one of our main goals. In accordance with this strategy, logback-access builds on top of logback-core and can thus provide much of the functionality of logback-classic - but in the scope of HTPP-access logging. </p> + but in the scope of HTTP-access logging. </p> <p>It should be noted that while logback-access requires logback-core, it is independent of logback-classic as well as slf4j. Just as importantly, logback-access artifact must be - installed at the container level, not at web-applcation level. It + installed at the container level, not at web-application level. It does not make sense to bundle <em>logback-access.jar</em> at the level of a web-application. </p> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/access.html | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[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: (LBCORE-217) CyclicBufferFileAppender
by Pascal Leclercq (JIRA) 04 Aug '11

04 Aug '11

CyclicBufferFileAppender ------------------------ Key: LBCORE-217 URL: http://jira.qos.ch/browse/LBCORE-217 Project: logback-core Issue Type: New Feature Components: Appender Reporter: Pascal Leclercq Assignee: Logback dev list We mostly use "FileAppender" and/or RollingFileAppender. We have a debug level on certain logger just to be sure we'll be able to analyse what's goign wrong in case of an error. This cause huge amount of logs and slow down our application. It would be nice to combine CyclicBufferTracker (like in SMTPAppender) and FileAppender to be able to get only the n last lines before and error event occurs. I create a POC and end up to the conclusion that 50 % performance improvement (with the last 1000 lines). I would like to send you the POC but I can't upload here. Sample conf : <configuration> <appender name="FILE" class="fr.opensagres.CyclicBufferFileAppender"> <file>testFile.log</file> <append>true</append> <encoder> <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern> </encoder> <cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTrackerImpl"> <bufferSize>1000</bufferSize> </cyclicBufferTracker> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration> regards -- 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] Commented: (LBCORE-41) FixedWindowRollingPolicy MAX_WINDOW_SIZE too small?
by Patrick Crocker (JIRA) 29 Jul '11

29 Jul '11

[ http://jira.qos.ch/browse/LBCORE-41?page=com.atlassian.jira.plugin.system.i… ] Patrick Crocker commented on LBCORE-41: --------------------------------------- I too believe that logback should not be establishing arbitrary policy as to what is 'too big' for the FixedWindowRollingPolicy. I replaced commons-logging/log4j with slf4j/logback-classic on an existing project. The log4j rules were already established with a rolling policy of 100 backups. The only way I was able to complete the logback conversion was to copy the original logback FixedWindowRollingPolicy class into a new com.company.FixedLargeWindowRollingPolicy class with the MAX_WINDOW_SIZE code removed. As logback updates to the FixedWindowRollingPolicy class have come out, I've had the task of manually updating my copy with the latest updates. That has changed now that 0.9.29 changed the FixedWindowRollingPolicy class to reference a package-scoped RollingPolicy.Base.zipEntryFileNamePattern field. Since the field is package-scoped, the only way I can keep my hack current is to change my classes package to match the RollingPolicyBase package (ch.qos.logback.core.rolling). This is getting way too messy now. Can't we just have the limitation removed and leave it up to the business to decide how big a window is too big? > FixedWindowRollingPolicy MAX_WINDOW_SIZE too small? > --------------------------------------------------- > > Key: LBCORE-41 > URL: http://jira.qos.ch/browse/LBCORE-41 > Project: logback-core > Issue Type: Improvement > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: Windows > Platform: All > Reporter: Mike Mansell > Assignee: Logback dev list > Priority: Minor > > I know it's not a blog but let me first say I've switched from log time use of JCL / log4j and think SLF4J / Logback is awesome so kudos to you guys for getting this out here... simple and powerful.. not much to not like ;-) > I'm curious as to why a window size as small as 12 was chosen here. I realize the renaming of all files within the window gets more expensive as the window increases but it seems prohibitive for people with larger logging requirements. Moreover, the fact that it is final means I can't override this either although I realize it is rather trivial to build my own implementation. > I have a project that generates a tremendous amount of logging currently (about 100MB every 6 minutes) and in my current setup have issues with files over 2GB. With the current MAX_WINDOW_SIZE I can only keep a days worth of logs! > If the rename is a big deal a rolling policy that just uses the index as a cyclic sequence should work fine or are there other reasons to cap this at something so low? > I could submit an implementation back if you like but just curious to get your feedback and any reasoning I might be missing on keeping the window size so low. > Thanks again for a great product! -- 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 0

[JIRA] Created: (LBCLASSIC-285) Tomcat integration - internal, access and webapps logging
by Sébastien (JIRA) 28 Jul '11

28 Jul '11

Tomcat integration - internal, access and webapps logging --------------------------------------------------------- Key: LBCLASSIC-285 URL: http://jira.qos.ch/browse/LBCLASSIC-285 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.29 Reporter: Sébastien Assignee: Logback dev list I have spend several hours on the last few days to integrate SLF4J with logback in tomcat 6.0.32 ; My use case is that I want to use slf4j and logback to process all log from tomcat, associated libraries, logback-access and several webapps, each of those webapps having their own configuration file. I came to logback hoping to have a better experience than with log4j regarding (advertised) context separation and co, but it have been quite more painful than expected. I have used the solution posted here https://github.com/grgrzybek/tomcat-slf4j-logback which is very useful (thanks!) but still suffer from multiple inconveniences. - It's a bit of a hack ; a very nicely packaged one, but still, having to relocate the package to another namespace and having two copies of the framework is not a smooth integration. - if you want both tomcat internal -> slf4j -> logback and logback-access, you end up with copies of logback-core and logback-classic in lib/ and suffer from context leakage between webapps which target the common jar - if you tries to circumvent the former problem with the use of the context JNDI selector, it is picked also by the package relocated tomcat-logback used for internal tomcat logging and go to a bootstrap issue with naming services since it is called early in tomcat start sequence. One could try to patch more the relocated package to rename the property name used to set context selector, but it is adding more complexity and renaming to the relocation hack - I ended up adding logback-access to the package relocation build and use the renamed version ; it works but hardly elegant and still does not solve other problems. - If your have an endorsed/ dir in tomcat with some libraries, coming say from apache foundation, that use commons logging, the jcl-slf4j bridge works well but you end up with slf4j and logback in endorsed/ and you also say good by to free context isolation by webapp classloader and copies of logback in each webapp. - to be sure to choose the good logback configuration for a webapp, I used the ServletContextListener from LBCLASSIC-202 ; a good solution but requires more packaging since it's not present in standard distribution. I think it could work better with the availability of a bit more Context selector logic, but before digging further, i'm interested to know if there is some work going on in those areas, which I would prefer not to duplicate. -- 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 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.29-16-g707298f
by git-noreply＠pixie.qos.ch 21 Jul '11

21 Jul '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 707298f12c4d6a5ae392a0c2c5bb488cbcc4f8ef (commit) from 6058b4beb2019cc7f6be39312ee9ad2fbd88db6c (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=707298f12c4d6a5ae392a0c2… http://github.com/ceki/logback/commit/707298f12c4d6a5ae392a0c2c5bb488cbcc4f… commit 707298f12c4d6a5ae392a0c2c5bb488cbcc4f8ef Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Jul 21 11:30:35 2011 +0200 added a link to the logback-akka project diff --git a/logback-site/src/site/pages/download.html b/logback-site/src/site/pages/download.html index 634a00d..d7314e3 100644 --- a/logback-site/src/site/pages/download.html +++ b/logback-site/src/site/pages/download.html @@ -52,8 +52,8 @@ </p> <ul> - <li><a href="dist/logback-${pom.version}.zip">logback-${pom.version}.zip</a></li> - <li><a href="dist/logback-${project.version}.tar.gz">logback-${pom.version}.tar.gz</a></li> + <li><a href="dist/logback-${project.version}.zip">logback-${project.version}.zip</a></li> + <li><a href="dist/logback-${project.version}.tar.gz">logback-${project.version}.tar.gz</a></li> </ul> @@ -63,12 +63,13 @@ <p>A console plugin for Eclipse is also available. It allows you - to receive logging events in a convenient Eclipse view, and - offers integration with logback's filtering - framework, among other features. A more precise description can be found in the plugin's + to receive logging events in a convenient Eclipse view, and offers + integration with logback's filtering framework, among other + features. A more precise description can be found in the plugin's <a href="consolePlugin.html">user guide</a>. <b>Unfortunately, the - console plugin is somewhat outdated. It expects logback version - 0.9.9. It will be upgraded in the coming weeks.</b></p> + console plugin is very much outdated. It expects logback version + 0.9.9. It will be upgraded during the second semester of + 2011.</b></p> <ul> @@ -81,7 +82,12 @@ <hr/> - <h2>Third-party tools</h2> + <h2>Third-party tools, extensions or forks</h2> + + <p>If you are the author of a logback-related project and would + like us to add your project to the list below please drop a line + on the logback-dev mailing list.</p> + <dl> <dt> @@ -95,28 +101,33 @@ classic.</p> </dd> - +  <dt> <a href="http://lilith.huxhorn.de">Lilith</a> by Joern Huxhorn </dt> <dd> - <p>Lilith is a Logging- and AccessEvent viewer for logback. - </p> + <p>Lilith is a Logging- and AccessEvent viewer for logback.</p> </dd> - </dl> +  + <dt> + <a + href="https://github.com/mojolly/logback-akka">Logback-akka</a> + by Ivan Porto Carrero. + </dt> - - <hr/> + <dd> + <p>Consists of several akka-based logback utilities, including + ActorAppender, HoptoadActorAppender and Logstash redis + appender. + </p> + </dd> - <h2>Forks</h2> + + </dl> - <p>At present time there are 18 forks of logback on github. If you - are the author of one of these forks and would like feedback from - potential users, please drop us a line at the logback-dev mailing list - with a brief description of your fork. We will gladly add a link to - your fork to the list below (currently empty).</p> + <p/> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/download.html | 51 +++++++++++++++++----------- 1 files changed, 31 insertions(+), 20 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0