February 2010 - logback-dev

[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: (LBCLASSIC-189) Normalization of fields
by Ceki Gulcu (JIRA) 02 May '10

02 May '10

Normalization of fields ----------------------- Key: LBCLASSIC-189 URL: http://jira.qos.ch/browse/LBCLASSIC-189 Project: logback-classic Issue Type: Sub-task Reporter: Ceki Gulcu Assignee: Logback dev list Normalization of recurrent fields such as logger. Normalization of session data. The idea was originally proposed by Ruediger Dohna in http://jira.qos.ch/browse/LBCLASSIC-169?focusedCommentId=11570#action_11570. -- 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: (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: (LBCLASSIC-182) Evaluable properties
by Aleksey Didik (JIRA) 02 Apr '10

02 Apr '10

Evaluable properties -------------------- Key: LBCLASSIC-182 URL: http://jira.qos.ch/browse/LBCLASSIC-182 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: 0.9.18 Reporter: Aleksey Didik Assignee: Logback dev list Priority: Minor Necessary to have properties which could be evaluated dynamically in time of configuration file read. Currently we have statical defined property values (by property tag or files) or we could get properties from System properties. In version 0.9.17 was made possibility to save formatted timestamp in property. May be possible to create property evaluator tag, to define some properties value dynamically? Something like this: <property name="hostName" evaluator="a.b.c.HostPropertyEvaluator"> <parameter name="host_type">ip</parameter> </property> Evaluator will be called on property initialization with listed parameters. -- 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 16

[JIRA] Created: (LBCLASSIC-188) Make table and column names overridable
by Ceki Gulcu (JIRA) 31 Mar '10

31 Mar '10

Make table and column names overridable --------------------------------------- Key: LBCLASSIC-188 URL: http://jira.qos.ch/browse/LBCLASSIC-188 Project: logback-classic Issue Type: Sub-task Components: appender Affects Versions: 0.9.18 Reporter: Ceki Gulcu Assignee: Logback dev list To comply with local project rules, it can be helpful if the table and column names used by DBAppender could be overridden. The easiest way to solve this problem is for DBAppender to delegate the resolution of table names and columns to a different class, say DBNameResolver. Here is a possible interface: interface DBNameResolver { String getTableName(String standardTableName); String getColumnName(String standardColumnName); } The default implementation of DBNameResolver could be: class DefaulDBNameResolver implements DBNameResolver { public String getTableName(String standardTableName) { if("logging_event".equals(standardTableName) { return standardTableName; } if("logging_event_property".equals(standardTableName) { return standardTableName; } if("logging_event_exception".equals(standardTableName) { return standardTableName; } throw new IllegalArgumentException(standardTableName + " is an unknown table name"); } String getColumnName(String standardColumnName) { ... } } If a user wanted to use different names she would simply implement DBNameResolver according to her requirements. Any volunteers to implement this? -- 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 19

[JIRA] Created: (LBCLASSIC-166) Static logger references in shared classes doesn't work with JNDIContextSelector
by Gabriele Contini (JIRA) 26 Mar '10

26 Mar '10

Static logger references in shared classes doesn't work with JNDIContextSelector -------------------------------------------------------------------------------- Key: LBCLASSIC-166 URL: http://jira.qos.ch/browse/LBCLASSIC-166 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: 0.917 Reporter: Gabriele Contini Assignee: Logback dev list The issue was already described in: LBCLASSIC-87 by Lars Ködderitzsch {quote} As Jens already pointed out the most common pattern to logging (even in common libaries as Jakarta Commons, Spring whatsoever) is using a static logger, eg. public class XY { private static [final] Logger log = LoggerFactory.getLogger(XY.class); ... } If such libraries are shared (either by being in tomcats shared libs, or by being directly in the ear) by multiple webapps, the logger context wins in which the original loading of the logging class (aka XY, see above) happens. To make an example. An ear contains two webapplications A and B, both have different logger context CtxA and CtxB. A library (say Spring for instance) is place in the ear and both webapps reference the library through their MANIFEST.MF. On application startup webapp A gets initialized first, during initialisation the classes of the shared libary (Spring) are loaded, therefor static loggers initialized with the context CtxA. Now webapp B gets initialized, classes of the shared libary are already loaded by the EARClassloader, the loggers continue to use CtxA. At runtime regardless of wich logger context will be set by context selectors of the webapps, all logging done by the shared classes will always go to CtxA. One can argue that common libaries should not use static loggers, but always obtain loggers freshly from the LoggerFactory. But that is a pipe dream, because the de-facto pattern in obtaining and using a logger is through a static field as depicted above. To achieve true per-webapp logging, already initialized loggers need to be able to switch logger contexts, for instance through TreadLocal or other mechanisms. {quote} And was closed with: {quote} If you need static references problem to be dealt with, then please file a *new* jira issue. {quote} I want to separate hibernate logs in my j2ee application (under jboss). Hibernate is included in server libs, and it uses static loggers: {code} public class XY { private static [final] Logger log = LoggerFactory.getLogger(XY.class); ... } {code} I also want to use separate configuration files for each j2ee application (so sifting appender is not enough), thus i'm using the JndiContextSelector. Logback is unable to switch context once hibernate is initialized, and the logger separation doesn't work for static loggers in shared libraries. --- I also tried to do my own ContextSelector in order to have a Logger that perform a jndi lookup when it's needed but: * ''LoggerContext'' has a method ''getLogger(String)'' that is final. I can't override LoggerContext and return my own instance of Logger. * In my opinion the ''contextSelector.getLoggerContext()'' could return a ''ILoggerFactory'' (there is no need it returns a full ''LoggerContext'' Best regards. Gabriele Contini -- 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-11) Jetty 7.x support for logback-access
by Daniel Peters (JIRA) 25 Mar '10

25 Mar '10

Jetty 7.x support for logback-access ------------------------------------ Key: LBACCESS-11 URL: http://jira.qos.ch/browse/LBACCESS-11 Project: logback-access Issue Type: Improvement Affects Versions: 0.9.18 Environment: Jetty 7.0.1 - http://eclipse.org/jetty/ Reporter: Daniel Peters Assignee: Logback dev list Since Jetty moved to the Eclipse Foundation, all package names changed from "mortbay" to "eclipse", which is why logback-access 0.9.18 doesnt work with Jetty7. When configured like described in http://logback.qos.ch/access.html I get this: Caused by: java.lang.NoClassDefFoundError: org/mortbay/jetty/RequestLog Can you maybe create a 2nd Jetty RequestLogImpl that uses the new "org.eclipse.jetty"-imports? Thanks! -- 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 5