September 2009 - logback-dev

[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-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-120) ArrayIndexOutOfBoundsException when using Oracle driver ojdbc6 with DBAppender
by Manuel Kueblboeck (JIRA) 09 Feb '11

09 Feb '11

ArrayIndexOutOfBoundsException when using Oracle driver ojdbc6 with DBAppender ------------------------------------------------------------------------------ Key: LBCORE-120 URL: http://jira.qos.ch/browse/LBCORE-120 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.17 Environment: Windows XP, Oracle Database 11g Release 11.1.0.0.0, jdk1.6.0_16 Reporter: Manuel Kueblboeck Assignee: Logback dev list Priority: Minor When using the Oracle driver ojdbc6 (11.1.0.7.0) an ArrayIndexOutOfBoundsException occurs when trying to write a log message to the database (see stacktrace below). I am using ch.qos.logback.core.db.DriverManagerConnectionSource in my logback.xml. When using ojdbc14 (10.2.0.4), this works fine. 07:31:43,997 |-ERROR in ch.qos.logback.classic.db.DBAppender[LogDB] - problem appending event java.lang.ArrayIndexOutOfBoundsException: 10 at java.lang.ArrayIndexOutOfBoundsException: 10 at at oracle.jdbc.driver.OracleSql.computeBasicInfo(OracleSql.java:950) at at oracle.jdbc.driver.OracleSql.getSqlKind(OracleSql.java:623) at at oracle.jdbc.driver.OraclePreparedStatement.<init>(OraclePreparedStatement.java:1212) at at oracle.jdbc.driver.T4CPreparedStatement.<init>(T4CPreparedStatement.java:28) at at oracle.jdbc.driver.T4CDriverExtension.allocatePreparedStatement(T4CDriverExtension.java:68) at at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:3140) at at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:3042) at at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:6022) at at ch.qos.logback.core.db.DBAppenderBase.append(DBAppenderBase.java:90) at at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:87) at at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:271) at at ch.qos.logback.classic.Logger.callAppenders(Logger.java:258) at at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:440) at at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:394) at at ch.qos.logback.classic.Logger.debug(Logger.java:521) at at nz.co.integrationworks.reporting.AbstractReporter.log(AbstractReporter.java:37) at at nz.co.integrationworks.reporting.AbstractReporter.log(AbstractReporter.java:29) at at nz.co.integrationworks.reporting.BusinessLoggerManualTest.main(BusinessLoggerManualTest.java:28) -- 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 4

[JIRA] Created: (LBCLASSIC-113) Nullpointer
by Mathias Bogaert (JIRA) 23 Dec '10

23 Dec '10

Nullpointer ----------- Key: LBCLASSIC-113 URL: http://jira.qos.ch/browse/LBCLASSIC-113 Project: logback-classic Issue Type: Bug Components: Other Reporter: Mathias Bogaert Assignee: Logback dev list Priority: Critical java.lang.NullPointerException at ch.qos.logback.classic.Logger.callTurboFilters(Logger.java:769) [logback-classic-0.9.15.jar:na] at ch.qos.logback.classic.Logger.isTraceEnabled(Logger.java:641) [logback-classic-0.9.15.jar:na] at ch.qos.logback.classic.Logger.isTraceEnabled(Logger.java:637) [logback-classic-0.9.15.jar:na] at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:198) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:126) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:905) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] Hibernate calls if ( log.isTraceEnabled() ). -- 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 3

[JIRA] Created: (LBCLASSIC-130) Multiple resource warning is not appropriate for logback-test.xml
by Jon Vincent (JIRA) 20 Oct '10

20 Oct '10

Multiple resource warning is not appropriate for logback-test.xml ----------------------------------------------------------------- Key: LBCLASSIC-130 URL: http://jira.qos.ch/browse/LBCLASSIC-130 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.14, 0.9.15, 0.9.16 Reporter: Jon Vincent Assignee: Logback dev list Priority: Minor When LBCLASSIC-85 was fixed, it also applied to logback-test.xml. Unfortunately, some IDEs (such as Eclipse) include the test classpath for all modules in a multi-module project -- which means that it's nearly impossible to avoid having multiple logback-test.xml files on the classpath if one project depends on another when running tests in Eclipse. Every test in the project will therefore emit this warning when run from the IDE. Is it possible to have the ContextInitializer only emit this warning for logback.xml, and not logback-test.xml? This would avoid a spurious/unactionable warning for developers using Eclipse. -- 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

5 14

[JIRA] Created: (LBCORE-114) Lifecycle.stop is not called for policy objects
by Anders Wallgren (JIRA) 14 Oct '10

14 Oct '10

Lifecycle.stop is not called for policy objects ----------------------------------------------- Key: LBCORE-114 URL: http://jira.qos.ch/browse/LBCORE-114 Project: logback-core Issue Type: Bug Affects Versions: 0.9.17 Reporter: Anders Wallgren Assignee: Logback dev list TriggeringPolicy implements Lifecycle, and start is called during configuration. However, when the context is shut down, stop is not called. -- 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: (LBCORE-117) Supply an appender that collects N events on all levels and dumps them to the output when an ERROR is logged
by Aaron Digulla (JIRA) 04 Oct '10

04 Oct '10

Supply an appender that collects N events on all levels and dumps them to the output when an ERROR is logged ------------------------------------------------------------------------------------------------------------ Key: LBCORE-117 URL: http://jira.qos.ch/browse/LBCORE-117 Project: logback-core Issue Type: New Feature Components: Appender Reporter: Aaron Digulla Assignee: Logback dev list For many applications, it's not necessary to log at the levels DEBUG and TRACE all the time. In fact, we usually only do this to be able to debug ERROR events. It would be great if there was an appender that would only collect a configurable number of events internally until a message of level ERROR or above is logged. At this time, the appender should dump it's internal state to the log and reset the internal state. -- 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: (LBGENERAL-28) JMX configurator should be able to use MBeanServers with a domain name
by C Z (JIRA) 09 Apr '10

09 Apr '10

JMX configurator should be able to use MBeanServers with a domain name ---------------------------------------------------------------------- Key: LBGENERAL-28 URL: http://jira.qos.ch/browse/LBGENERAL-28 Project: logback-general Issue Type: New Feature Affects Versions: 0.9.16 Reporter: C Z Assignee: Logback dev list Currently, logback exposes an MBean to provide logging related controls via the inclusion of the following configuration: <jmxConfigurator /> However, this *always* uses the platform mbean server: MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); (can be found in class JMXConfiguratorAction, line# 54). I think it should be able to provide an option to use an MBeanServer with a specific domain, which is provided in the JMX spec. The code needs to use the following: List servers = MBeanServerFactory.findMBeanServer(agentId); and then use the first one, possibly giving a warning if there are multiple. This is crucial for our use-case, especially because we have separate MBeanServers in our web-app environment, and we need each application to use its own MBeanServer with a specific domain. So, all in all, can we add an attribute of some sort, so that we can do the following: <jmxConfigurator agentid="someMbeanServerId"/> and if this is set, the code uses: MBeanServer mbs = MBeanServerFactory.findMBeanServer(agentId).get(0); and otherwise, it does whatever it used to do. -- 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-95) BurstFilter
by Ceki Gulcu (JIRA) 25 Mar '10

25 Mar '10

BurstFilter ----------- Key: LBCORE-95 URL: http://jira.qos.ch/browse/LBCORE-95 Project: logback-core Issue Type: New Feature Reporter: Ceki Gulcu Assignee: Ceki Gulcu A filter to regulate log message bursts, useful for things like throttling the number of logs sent to an e-mail appender when the database is unavailable. See http://www.qos.ch/pipermail/logback-dev/2009-March/003921.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-148) Deadlock with DBAppender
by Mel T. (JIRA) 24 Mar '10

24 Mar '10

Deadlock with DBAppender ------------------------ Key: LBCLASSIC-148 URL: http://jira.qos.ch/browse/LBCLASSIC-148 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Environment: MacBook Pro 17" Intel Core 2 Duo 2.33 GHz OS X 10.5.7 (9J61) java version "1.6.0_13" slf4j 1.5.8 c3p0 0.9.1.2 Reporter: Mel T. Assignee: Logback dev list A deadlock occurs when running the attached application. For this lock to occur, we need to: - load a configuration other than the default in java app. - not have any default logback.xml in the classpath. - have these jars in the classpath c3p0-0.9.1.2.jar logback-core-0.9.17.jar logback-classic-0.9.17.jar log4j-over-slf4j-1.5.8.jar slf4j-api-1.5.8.jar mysql.jar - Place attached the logback2.xml file in the same package as the attached MainTest class. - adapt the logback2.xml file to your DB schema. (note that you do not need to have the DB tables created for the lock to occur, but the test is more conclusive if you have a valid DB connection and schema.) - Execute this java -cp ".:../c3p0-0.9.1.2.jar:../logback-core-0.9.17.jar:../logback-classic-0.9.17.jar:../log4j-over-slf4j-1.5.8.jar:../slf4j-api-1.5.8.jar:../mysql.jar" MainTest The application should output the logger status and hang. Workaround: - Do not include log4j-over-slf4j in the classpath, - or add a default logback.xml that will be loaded first (just copy and rename logback2.xml in same default package) - or use the attached logback2-works.xml instead of logback2.xml (modify MainTest to load that file instead.) In this last one, the change is that the DB appender is only used in a logger element instead of the root. I did not spend the time to look at the cause of this locking problem as the workarounds allow me to move on. So I hope this really belong in jira, and not a config/usage error on my part. -- Mel T. -- 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 11