January 2012 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-221) SMTPAppender includes irrelevant logging events
by Chris Cheshire (JIRA) 06 Mar '12

06 Mar '12

SMTPAppender includes irrelevant logging events ----------------------------------------------- Key: LBCLASSIC-221 URL: http://jira.qos.ch/browse/LBCLASSIC-221 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.24 Environment: Java6, Tomcat6 Reporter: Chris Cheshire Assignee: Logback dev list The BufferSize parameter to SMTPAppender has been removed with no replacement. When the SMTPAppender is triggered by an error event it also includes the previous 255 logging events, whether they were errors or not (now that the buffer size is fixed). By using BufferSize = 1, I was able to send a single error email every time an error occurred with just that error. Now I get completely irrelevant logging events, potentially days old with nothing to do with the error being logged and no simple way to change this. I'm not sure what version this was introduced - I just upgraded from 0.9.17 to 0.9.24. -- 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 5

[JIRA] Created: (LBCORE-210) Upgrade Janino support to latest 2.6.1
by Jason Klapste (JIRA) 21 Feb '12

21 Feb '12

Upgrade Janino support to latest 2.6.1 -------------------------------------- Key: LBCORE-210 URL: http://jira.qos.ch/browse/LBCORE-210 Project: logback-core Issue Type: Improvement Components: Joran Affects Versions: 0.9.28, 0.9.29 Reporter: Jason Klapste Assignee: Logback dev list Logback officially supports 2.4.3 (from 2006!) and should probably be upgraded to a more recent version. Janino 2.6.1 *WAS* working previously in logback (0.9.27) until EnvUtil.isJaninoAvailable()'s check was added. org.codehaus.janino.Cookable does not exist in 2.6.1. -- 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

7 10

[JIRA] Created: (LBCLASSIC-281) Don't evaluate formattedMessage in LoggingEvent constructor
by Andrew Brett (JIRA) 16 Feb '12

16 Feb '12

Don't evaluate formattedMessage in LoggingEvent constructor ----------------------------------------------------------- Key: LBCLASSIC-281 URL: http://jira.qos.ch/browse/LBCLASSIC-281 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.29 Reporter: Andrew Brett Assignee: Logback dev list Whenever a ch.qos.logback.classic.spi.LoggingEvent is constructed, MessageFormatter.arrayFormat(...) is called, and the formattedMessage member variable assigned. This involves calling toString() on all arguments in argArray, which can be slow, and occurs even if the formattedMessage is not part of any appender layouts. For my project's purposes, I have a custom formatter which only outputs an abbreviated string form of certain objects with expensive toString() methods; however, I am still paying the overhead in the toString() calls, since they're made even when getFormattedMessage() is never called. Note that I don't control the source of the objects with expensive toString() methods, nor do I control the source everywhere they're logged, so I can't simply change them directly. formattedMessage is already evaluated lazily in getFormattedMessage(), so the only side effect of this change is the introspection of argsArray to look for a Throwable at the end, which is a trivial operation to perform separately. -- 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: (LBCORE-146) SiftingAppender TimeBasedRollingPolicy MaxHistory not deleting old files
by Hrotkó Gábor (JIRA) 03 Feb '12

03 Feb '12

SiftingAppender TimeBasedRollingPolicy MaxHistory not deleting old files ------------------------------------------------------------------------ Key: LBCORE-146 URL: http://jira.qos.ch/browse/LBCORE-146 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Environment: linux64, jdk1.6.0_17-b04, apache-tomcat-6.0.24 Reporter: Hrotkó Gábor Assignee: Logback dev list When I use SiftingAppender with TimeBasedRollingPolicy, old files does not get deleted when the MaxHistory is set. logback.xml snipet: <configuration debug="true" scan="true" scanPeriod="5 seconds"> <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <Key>userid</Key> <DefaultValue>base</DefaultValue> </discriminator> <sift> <appender name="FILE-${userid}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/usr/local/tomcat6/logs/myLog_${userid}.log</File> <Append>false</Append> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %level %mdc %logger.%method:%line - %msg%n</Pattern> </layout> <RollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>/usr/local/tomcat6/logs/myLog_${userid}.%d{yyyy-MM-dd}.log</FileNamePattern>  <MaxHistory>2</MaxHistory> </RollingPolicy> </appender> </sift> </appender> ... With the config above, the files gets sifted and rolled well, but old files not deleted. When I change the filenames, and delete the ${userid} sifting, it works well. ... <File>/usr/local/tomcat6/logs/myLog.log</File> ... <FileNamePattern>/usr/local/tomcat6/logs/myLog.%d{yyyy-MM-dd}.log</FileNamePattern> ... -- 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: (LBCLASSIC-321) set root level and log home (base) path for file appenders using MDC (context?) properties
by Miroslav Obradovic (JIRA) 29 Jan '12

29 Jan '12

set root level and log home (base) path for file appenders using MDC (context?) properties ------------------------------------------------------------------------------------------ Key: LBCLASSIC-321 URL: http://jira.qos.ch/browse/LBCLASSIC-321 Project: logback-classic Issue Type: New Feature Components: joran Reporter: Miroslav Obradovic Assignee: Logback dev list would it be possible to keep application depend only on slf4j at compile time, but still be able to pass context properties to logback.xml through MDC in a standalone app, assuming I take care not to get/access any loggers until I put the context properties into MDC? (I am aware that I could programatically get the root logger by name and cast it to logback Logger, and then set the level, and add a file appender, but this would require logback jars at compile time) -- 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

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch master updated. v_1.0.0-66-g0877b9c
by git-noreply＠pixie.qos.ch 27 Jan '12

27 Jan '12

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 0877b9c3e93e159adce108834e608b67929ec74d (commit) from 1b13450172993fdc8597e3a0e1bd11fb9a9459bf (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=0877b9c3e93e159adce10883… http://github.com/ceki/logback/commit/0877b9c3e93e159adce108834e608b67929ec… commit 0877b9c3e93e159adce108834e608b67929ec74d Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Jan 27 22:02:43 2012 +0100 typo fix diff --git a/logback-site/src/site/pages/manual/architecture.html b/logback-site/src/site/pages/manual/architecture.html index 9793c71..8cc282f 100644 --- a/logback-site/src/site/pages/manual/architecture.html +++ b/logback-site/src/site/pages/manual/architecture.html @@ -61,7 +61,7 @@ <a href="../access.html">access module documentation</a>. </p> - <p>In the reminder of this document, we will write "logback" to + <p>In the remainder of this document, we will write "logback" to refer to the logback-classic module. </p> ----------------------------------------------------------------------- Summary of changes: .../src/site/pages/manual/architecture.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

non serializing SocketAppender
by Enrico Spinielli 16 Jan '12

16 Jan '12

Hi, I am looking for some direction or historical memories about the possibility to have a SocketAppender that does not serialize the payload. (This is to be able to read at the other end with a non Java based program...) Browsing the code it seems that one possibility is to have a derived class of SocketAppender to implement getPST() to return a PreSerializationTransformer that does no transformations, but then the event object is (/seems to be) written to an ObjectOutputStream. This means, I guess, that even if you write a custom serialization code and avoid any transformations, in the end, the event will still be written to the pipe as a java object. Please comment on the above statements and provide directions or examples for further explorations. Thanks a lot in advance Bye -- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick "He who refuses to do arithmetic is doomed to talk nonsense."—John McCarthy

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch master updated. v_1.0.0-65-g1b13450
by git-noreply＠pixie.qos.ch 15 Jan '12

15 Jan '12

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 1b13450172993fdc8597e3a0e1bd11fb9a9459bf (commit) from eea3086a0b813a73f3539dbf286078403843839e (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=1b13450172993fdc8597e3a0… http://github.com/ceki/logback/commit/1b13450172993fdc8597e3a0e1bd11fb9a945… commit 1b13450172993fdc8597e3a0e1bd11fb9a9459bf Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Jan 15 22:25:49 2012 +0100 note about posting diff --git a/logback-site/src/site/pages/mailinglist.html b/logback-site/src/site/pages/mailinglist.html index 60f93ee..821e3e3 100644 --- a/logback-site/src/site/pages/mailinglist.html +++ b/logback-site/src/site/pages/mailinglist.html @@ -27,8 +27,9 @@ mailing list, a copy of that message is broadcast to everyone who is subscribed to that mailing list. Mailing lists provide a simple and effective communication mechanism. With potentially thousands - of subscribers, there is a common set of etiquette guidelines that - you should observe. Please keep on reading. + of subscribers, there is a common set of <a + href="http://www.shakthimaan.com/downloads/glv/presentations/mailing-list-etiquet…">etiquette + guidelines</a> that you should observe. </p> <h3>Respect the mailing list type</h3> @@ -45,6 +46,11 @@ not cross post. </p> + <p><span class="label notice">Note</span> <b>Only subscribers can + post to the logback-user and logback-dev mailing lists.</b> If you + are subscribed and your posts bounce, make sure that the address + you post from matches your subscription address.</p> + <table class="bodyTable"> <tr class="a"> <th>Name</th> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/mailinglist.html | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCORE-244) JaninoEventEvaluator causes Janino to use the TCCL
by Glyn Normington (JIRA) 12 Jan '12

12 Jan '12

JaninoEventEvaluator causes Janino to use the TCCL -------------------------------------------------- Key: LBCORE-244 URL: http://jira.qos.ch/browse/LBCORE-244 Project: logback-core Issue Type: Bug Affects Versions: 0.9.28, 0.9.29, 0.9.30, 1.0.0 Reporter: Glyn Normington Assignee: Logback dev list This is a regression compared to 0.9.24 which correctly specified logback's class loader as Janino's "parent" class loader. Details: http://mailman.qos.ch/pipermail/logback-user/2012-January/002917.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 1

Build failure: multiDate(ch.qos.logback.core.rolling.TimeBasedFileNamingAndTriggeringPolicyBaseTest): expected:<foo-2011-12/59.log> but was:<null>
by Glyn Normington 12 Jan '12

12 Jan '12

I'm trying to build logback. I cloned from github (HEAD is at commit eea3086a0b813a73f3539dbf286078403843839e) and ran "mvn install". There is one repeatable failure, multiDate(ch.qos.logback.core.rolling.TimeBasedFileNamingAndTriggeringPolicyBaseTest): expected:<foo-2011-12/59.log> but was:<null>, with the surefire report below. Environment: Mac OS X 10.7.2 Java 1.6.0_29 Maven 3.0.3 Am I alone in seeing this failure? Regards, Glyn P.S. The logback core tests took around 8 seconds, so the elapsed time below (9 days) is a little off. ------------------------------------------------------------------------------- Test set: ch.qos.logback.core.rolling.TimeBasedFileNamingAndTriggeringPolicyBaseTest ------------------------------------------------------------------------------- Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 780,969.877 sec <<< FAILURE! singleDate(ch.qos.logback.core.rolling.TimeBasedFileNamingAndTriggeringPolicyBaseTest) Time elapsed: 0 secmultiDate(ch.qos.logback.core.rolling.TimeBasedFileNamingAndTriggeringPolicyBaseTest) Time elapsed: 0.002 sec <<< FAILURE! java.lang.AssertionError: expected:<foo-2011-12/59.log> but was:<null> at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at ch.qos.logback.core.rolling.TimeBasedFileNamingAndTriggeringPolicyBaseTest.multiDate(TimeBasedFileNamingAndTriggeringPolicyBaseTest.java:65) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680)

1 0