December 2009 - logback-dev

[JIRA] Created: (LBGENERAL-37) Need to scan included files
by lala (JIRA) 10 Feb '11

10 Feb '11

Need to scan included files --------------------------- Key: LBGENERAL-37 URL: http://jira.qos.ch/browse/LBGENERAL-37 Project: logback-general Issue Type: New Feature Reporter: lala Assignee: Logback dev list Priority: Minor I'm using the following configuration and I'm looking for a method to scan included files. <configuration scan="true" scanPeriod="10 seconds"> <insertFromJNDI env-entry-name="java:comp/env/logback-file" as="logback-file" /> <contextName>lala</contextName> <include file="${logback-file}" /> </configuration> Once scan directive is used, logback is going to rescan this file every 10 seconds whether its modification date has changed. The issue is that I have to overwrite the previous file in order to rescan the target ${logback-file}. I suggest adding an attribute in the configuration marker in order to force logback to scan included files . It could be something like that: <configuration scan="true" scanPeriod="10 seconds" scanIncluded="true"> ..... </configuration> In order to process this task, at each scan logback should memorize the reference to the included files, and their latest modification date. Consequently, every 10 seconds, logback check the whole list of files and rescan the main file if something has changed. -- 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 5

[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: (LBACCESS-10) Servlet input stream gets corrupted
by Augusto (JIRA) 16 Nov '10

16 Nov '10

Servlet input stream gets corrupted ----------------------------------- Key: LBACCESS-10 URL: http://jira.qos.ch/browse/LBACCESS-10 Project: logback-access Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows 7 - java 1.6.0_16-b01 - Hightide 6.1H10 Windows 7 - java 1.6.0_16-b01 - Tomcat 6.0.16 Solaris 5.10 - java 1.6.0_16 - Hightide 6.1H10 Reporter: Augusto Assignee: Logback dev list The request.inputStream() is wrapped in a TeeServletInputStreamm but this class fails to pass all the data in the original input stream to the servlets. In my tests is passes properly between 4 and 8kb of data and later it just return zeros instead of the characters. I'm attaching a very simple webapp that writes the input stream of a POST request into a file to demonstrate the bug. -- 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: (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: (LBCORE-131) SizeAndTimeBasedFNATP will overwrite previous logging files when File property is set at RollingFileAppender
by tomliliu (JIRA) 30 Jun '10

30 Jun '10

SizeAndTimeBasedFNATP will overwrite previous logging files when File property is set at RollingFileAppender ------------------------------------------------------------------------------------------------------------ Key: LBCORE-131 URL: http://jira.qos.ch/browse/LBCORE-131 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Reporter: tomliliu Assignee: Logback dev list Here's the failure case: Configuration: <appender name="appender" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>c:/var/tmp/base.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern> c:/var/tmp/%d{yyyy-MM-dd_HH}.%i.log </FileNamePattern> <TimeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <MaxFileSize>1KB</MaxFileSize> </TimeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern> %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n </Pattern> </layout> </appender> Steps to reproduce: 1. Start the application 2. base.log was created. 3. yyyy-MM-dd_HH.0.log was created on rollover 4. rebounce the application 5. log to base.log 6. yyyy-MM-dd_HH.0.log was created on rollover, overwrite the previous yyyy-MM-dd_HH.0.log. Logging messages are lost. It looks like the root cause is that SizeAndtimeBasedFNATP does not update the currentPeriodsCounter when parentsRawFileProperty is set. if (tbrp.getParentsRawFileProperty() == null) { String regex = tbrp.fileNamePattern.toRegex(dateInCurrentPeriod); String stemRegex = FileFilterUtil.afterLastSlash(regex); computeCurrentPeriodsHighestCounterValue(stemRegex); } SizeAndTimeBasedFNATP should update currentPeriodsCounter regardless whether parentsRawFileProperty is set or not. Here's a fix works for me. SizeAndTimeBasedFNATP.java @Override public void start() { // we depend on certain fields having been initialized // in super.start() super.start(); archiveRemover = new SizeAndTimeBasedArchiveRemover(tbrp.fileNamePattern, rc); archiveRemover.setContext(context); // we need to get the correct value of currentPeriodsCounter. // usually the value is 0, unless the appender or the application // is stopped and restarted within the same period //if (tbrp.getParentsRawFileProperty() == null) { String regex = tbrp.fileNamePattern.toRegex(dateInCurrentPeriod); String stemRegex = FileFilterUtil.afterLastSlash(regex); computeCurrentPeriodsHighestCounterValue(stemRegex); //} started = true; } void computeCurrentPeriodsHighestCounterValue(final String stemRegex) { File file = new File(getCurrentPeriodsFileNameWithoutCompressionSuffix()); File parentDir = file.getParentFile(); File[] matchingFileArray = FileFilterUtil .filesInFolderMatchingStemRegex(parentDir, stemRegex); if (matchingFileArray == null || matchingFileArray.length == 0) { return; } FileFilterUtil.reverseSortFileArrayByName(matchingFileArray); currentPeriodsCounter = FileFilterUtil.extractCounter(matchingFileArray[0], stemRegex); //If parentsRawFileProperty is set, we should increment currentPeriodsCounter by one in order to avoid overwrite the last archive file. if(tbrp.getParentsRawFileProperty() != null) { currentPeriodsCounter ++; } } Thanks, Tom -- 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: (LBCLASSIC-167) RollingFileAppender does not auto create subdirectories in some circumstances
by Rick Janda (JIRA) 08 May '10

08 May '10

RollingFileAppender does not auto create subdirectories in some circumstances ----------------------------------------------------------------------------- Key: LBCLASSIC-167 URL: http://jira.qos.ch/browse/LBCLASSIC-167 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.917 Reporter: Rick Janda Assignee: Logback dev list If the FileNamePattern of the rollingPolicy contains another directory than the File element of the appender, than the directory in the FileNamePattern is not created automatically. The OnConsoleErrorListener writes out the following error in this case: -ERROR in c.q.l.core.rolling.helper.Compress - Error occurred while compressing [/opt/baa-logserver/logs/logback.log33794048136194907.tmp] into [/opt/baa-logserver/logs/archive/logback_2009-10-26.log.zip]. java.io.FileNotFoundException: /opt/baa-logserver/logs/archive/logback_2009-10-26.log.zip (No such file or directory) at java.io.FileNotFoundException: /opt/baa-logserver/logs/archive/logback_2009-10-26.log.zip (No such file or directory) The appender is configured as followed (files are rolled into a archive directory on daily basis): <appender name="LOGBACK" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${LOG_DIR}/logback.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>${LOG_DIR}/archive/logback_%d{yyyy-MM-dd}.log.zip</FileNamePattern> <MaxHistory>${MAX_HISTORY_DAYS}</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%date{dd-MM-yyyy HH:mm:ss.SSS} [%contextName] $%mdc{refId}$ %-5level %logger{0} - %msg%n%xEx{full}</Pattern> </layout> </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

3 3

[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