October 2009 - logback-dev - mailman3.qos.ch

WriterAppender.subAppend behaviour in case of IOExceptions
by Syvalta 27 Nov '09

27 Nov '09

Hi, I noticed WriterAppender.subAppend stops appending if an IOException occurs during write. This is bit problematic if interruption is used as a cancellation mechanism (as suggested in JCiP). The problem is that if a thread happens to be logging at the time it is interrupted, logging (for that appender) will be ceased for the lifetime of the application (or until Logback is re-initialized). Additionally, if there are some transient errors, logging won't continue after recovery. At least it seems so, but I might be wrong. I could provide a patch which changes the behavior, but it seems changes are non-trivial. I would be glad to receive some advice. - how backward compatible the changes should be? Can I remove methods, add abstract methods etc. or should backward compatibility be preserved (and if it is, does that increase the likelihood of the patch being applied)? - in what level at hierarchy this should be done? I have thought at WriterAppender, but that would require adding a method to create OutputStream, which subclasses would implement. Currently subclasses set writer to WriterAppender, so this would change it to the opposite. Another option would be to do it at FileAppender level, but I haven't investigated that option much yet. - should there be some "throttling", so that under persistent error state new outputstream would not be tried to be created in every logging call. I think so, perhaps some condition like "try in first 10 calls, but after that only every 30 sec). - should the log events be buffered under presence of error (of course limited amount with fifo or something)? - is there any chance that this kind of patch would be accepted? Do you see this kind of feature useful? Hope you understand at least something from my post, I admit it is "bit" unclear :) -- View this message in context: http://www.nabble.com/WriterAppender.subAppend-behaviour-in-case-of-IOExcep… Sent from the Logback Dev mailing list archive at Nabble.com.

2 2

[JIRA] Created: (LBCLASSIC-121) Make some of the Import-Package declarations in logback-classic OSGi bundle optional
by Pavol Juhos (JIRA) 25 Nov '09

25 Nov '09

Make some of the Import-Package declarations in logback-classic OSGi bundle optional ------------------------------------------------------------------------------------ Key: LBCLASSIC-121 URL: http://jira.qos.ch/browse/LBCLASSIC-121 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.15 Environment: OSGi Service Platform Release 4 Reporter: Pavol Juhos Assignee: Logback dev list Priority: Minor It might be a good idea to mark some additional packages imported by logback-classis bundle as optional. Namely this applies to packages javax.servlet, javax.servlet.http, javax.management By importing package javax.servlet you are forcing the users to deploy Sevlet API bundle even in non-web application environment. The current <Import-Package> declaration in maven-bundle-plugin configuration: <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> Suggested update: <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, javax.servlet.*;resolution:=optional, javax.management;resolution:=optional, * </Import-Package> Feel free to close this as invalid if the above mentioned packages are _always_ required for correct operation of logback-classic. -- 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-151) Export-Package: org.slf4j.impl; version="1.5.6" but 1.5.8 required
by Bulat Nigmatullin (JIRA) 18 Nov '09

18 Nov '09

Export-Package: org.slf4j.impl;version="1.5.6" but 1.5.8 required ----------------------------------------------------------------- Key: LBCLASSIC-151 URL: http://jira.qos.ch/browse/LBCLASSIC-151 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Reporter: Bulat Nigmatullin Assignee: Logback dev list Priority: Minor In pom.xml you says <properties> −  <slf4j.version>1.5.8</slf4j.version> <consolePlugin.version>1.1.0</consolePlugin.version> </properties> but in MANIFEST.MF exported org.slf4j.impl version 1.5.6. Please, fix version in MANIFEST.MF and upload it to Maven repository. -- 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-108) LOGBack Classic Bundle does not declare ch.qos.logback.core.rolling as Import-Package
by Christian Brensing (JIRA) 18 Nov '09

18 Nov '09

LOGBack Classic Bundle does not declare ch.qos.logback.core.rolling as Import-Package ------------------------------------------------------------------------------------- Key: LBCLASSIC-108 URL: http://jira.qos.ch/browse/LBCLASSIC-108 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Reporter: Christian Brensing Assignee: Logback dev list Priority: Minor The LOGBack Classic Bundle has no Import-Package for ch.qos.logback.core.rolling (and rolling.helper), resulting in a ClassNotFoundException when using e.g. the RollingFileAppender from the Core-Bundle. The ClassNotFoundException will be raised because the Bundle which initializes the LoggerContext (Classic) can not load the Appender from the Core-Bundle. The Bnd-Tool by Peter Kriens and the Maven-Felix-Plugin only detects package dependencies that are imported in java classes. Runtime dependencies like Appenders must be explicitly configured in the bnd-file or pom. This issue is identically to the one I reported for the SpringSource-Bundle-Repository, see https://issuetracker.springsource.com/browse/BRITS-165. -- 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-149) ContextNameConverter does not use the context of the event
by Ceki Gulcu (JIRA) 13 Nov '09

13 Nov '09

ContextNameConverter does not use the context of the event ---------------------------------------------------------- Key: LBCLASSIC-149 URL: http://jira.qos.ch/browse/LBCLASSIC-149 Project: logback-classic Issue Type: Bug Reporter: Ceki Gulcu Assignee: Logback dev list ContextNameConverter instead of reading the context name found in the event passed as parameter, uses the context to which it (the ContextNameConverter instance) is attached to. Usually the two contexts are the same. However, when an event is sent to a remote server, the wrong information is displayed. -- 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] Created: (LBCORE-98) TimeBasedRollingPolicy: name of file in zip archive is <FileNamePattern>.nanos.tmp
by Anders Wallgren (JIRA) 13 Nov '09

13 Nov '09

TimeBasedRollingPolicy: name of file in zip archive is <FileNamePattern>.nanos.tmp ---------------------------------------------------------------------------------- Key: LBCORE-98 URL: http://jira.qos.ch/browse/LBCORE-98 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.15 Environment: Windows Reporter: Anders Wallgren Assignee: Logback dev list Priority: Minor The name of the filename in the zip archive is a temp filename, based on the FileNamePattern, no the FileNamePattern itself. -- 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: (LBCORE-101) OSGi manifest headers too restrictive
by david varnes (JIRA) 12 Nov '09

12 Nov '09

OSGi manifest headers too restrictive ------------------------------------- Key: LBCORE-101 URL: http://jira.qos.ch/browse/LBCORE-101 Project: logback-core Issue Type: Bug Affects Versions: 0.9.15 Reporter: david varnes Assignee: Logback dev list This issue is very similar and could be addressed at the same time as LBCLASSIC-119, LBCLASSIC-121 & LBCLASSIC-131. The Import-Package definition for logback-core requires that the javax.* packages be available at runtime. The pom.xml file and my usage seem to indicate that they should be optional. Attached patch adds javax.* as 'optional' in addition to the exiting janino declaration. 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

2 2

[JIRA] Created: (LBCORE-118) EvaluatorFilter returns OnMatch when marker is null
by Manuel Kueblboeck (JIRA) 10 Nov '09

10 Nov '09

EvaluatorFilter returns OnMatch when marker is null --------------------------------------------------- Key: LBCORE-118 URL: http://jira.qos.ch/browse/LBCORE-118 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows XP Reporter: Manuel Kueblboeck Assignee: Logback dev list Priority: Minor <appender name="Alert" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="isAlert"> <expression>marker.getName().equals("Alert")</expression> </evaluator> <OnMatch>ACCEPT</OnMatch> <OnMismatch>DENY</OnMismatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>ALERT: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </layout> </appender> In the above example, when an event is logged without an attached marker, the filter returns OnMatch. I would expect that it returns OnMismatch. A work around for this issue is to change the expression to this: <expression>marker != null && marker.getName().equals("Alert")</expression> -- 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 3

[JIRA] Created: (LBCLASSIC-155) ThrowableProxy passed into EventEvaluator
by Hontvári József (JIRA) 10 Nov '09

10 Nov '09

ThrowableProxy passed into EventEvaluator ----------------------------------------- Key: LBCLASSIC-155 URL: http://jira.qos.ch/browse/LBCLASSIC-155 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.917 Reporter: Hontvári József Assignee: Logback dev list In an event evaluator which is called in the option part of an "ex" formatting specifier I cannot use a "throwable instanceof example" expression, because the evaluator receives a ThrowableProxy and not a Throwable. Here is a stack trace, dumped from the evaluator expression. It does include a ThrowableProxyConverter.convert call: java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at mireka.E.f(E.java:21) at SC.eval0(SC.java:3) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.janino.ScriptEvaluator.evaluate(ScriptEvaluator.java) at org.codehaus.janino.ScriptEvaluator.evaluate(ScriptEvaluator.java) at ch.qos.logback.core.boolex.JaninoEventEvaluatorBase.evaluat (JaninoEventEvaluatorBase.java:53) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:109) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:31) at ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:32) at ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:110) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:132) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:51) at ch.qos.logback.core.WriterAppender.subAppend(WriterAppender.java:267) at ch.qos.logback.core.WriterAppender.append(WriterAppender.java:117) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:89) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:271) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:258) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:440) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:394) at ch.qos.logback.classic.Logger.debug(Logger.java:517) at org.subethamail.smtp.server.Session.run(Session.java:119) -- 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-119) Missing Export-Package declarations in logback-classic OSGi bundle
by Pavol Juhos (JIRA) 08 Nov '09

08 Nov '09

Missing Export-Package declarations in logback-classic OSGi bundle ------------------------------------------------------------------ Key: LBCLASSIC-119 URL: http://jira.qos.ch/browse/LBCLASSIC-119 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Environment: OSGi environment Reporter: Pavol Juhos Assignee: Logback dev list Priority: Critical logback-classic OSGi bundle doesn't export logback implementation packages. These packages need to be imported by bundles implementing custom logback Appenders etc. The problem is most likely caused a misconfiguration of maven-bundle-plugin in logback-classic POM. Current configuration: <instructions> <Export-Package>ch.qos.logback.classic.*</Export-Package> <Export-Package>org.slf4j.impl;version=1.5.6</Export-Package> <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> Suggested configuration: <instructions> <Export-Package>ch.qos.logback.classic.*, org.slf4j.impl;version=1.5.6 </Export-Package> <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> Second Export-Package declaration seems to override the first one. -- 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