- logback-dev - mailman3.qos.ch

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v0.9.18-8-g75e4494
by git-noreply＠pixie.qos.ch 06 Jan '10

06 Jan '10

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 75e4494c35db38d4af92ced77109deb1407ec713 (commit) from e4839ddb7eda16fa1565afbc30b5b3698f89eb0b (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=75e4494c35db38d4af92ced7… http://github.com/ceki/logback/commit/75e4494c35db38d4af92ced77109deb1407ec… commit 75e4494c35db38d4af92ced77109deb1407ec713 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Jan 6 23:27:50 2010 +0100 Added OnMarkerEvaluator. When used in conjuction with SMTPAppender, it triggers outgoing email when an event includes a matching Marker. diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/boolex/OnMarkerEvaluator.java b/logback-classic/src/main/java/ch/qos/logback/classic/boolex/OnMarkerEvaluator.java new file mode 100644 index 0000000..0904efc --- /dev/null +++ b/logback-classic/src/main/java/ch/qos/logback/classic/boolex/OnMarkerEvaluator.java @@ -0,0 +1,58 @@ +/** + * Logback: the reliable, generic, fast and flexible logging framework. + * Copyright (C) 1999-2009, QOS.ch. All rights reserved. + * + * This program and the accompanying materials are dual-licensed under + * either the terms of the Eclipse Public License v1.0 as published by + * the Eclipse Foundation + * + * or (per the licensee's choosing) + * + * under the terms of the GNU Lesser General Public License version 2.1 + * as published by the Free Software Foundation. + */ +package ch.qos.logback.classic.boolex; + +import java.util.ArrayList; +import java.util.List; + +import org.slf4j.Marker; + +import ch.qos.logback.classic.spi.ILoggingEvent; +import ch.qos.logback.core.boolex.EvaluationException; +import ch.qos.logback.core.boolex.EventEvaluatorBase; + +/** + * Evaluates to true when the logging event passed as parameter contains one of + * the user-specified markers. + * + * @author Ceki Gülcü + */ +public class OnMarkerEvaluator extends EventEvaluatorBase<ILoggingEvent> { + + List<String> markerList = new ArrayList<String>(); + + public void addMarker(String markerStr) { + markerList.add(markerStr); + } + + /** + * Return true if event passed as parameter contains one of the specified + * user-markers. + */ + public boolean evaluate(ILoggingEvent event) throws NullPointerException, + EvaluationException { + + Marker eventsMarker = event.getMarker(); + if (eventsMarker == null) { + return false; + } + + for (String markerStr : markerList) { + if (eventsMarker.contains(markerStr)) { + return true; + } + } + return false; + } +} diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/pattern/ThrowableProxyConverter.java b/logback-classic/src/main/java/ch/qos/logback/classic/pattern/ThrowableProxyConverter.java index 2b20c85..0ea00dc 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/pattern/ThrowableProxyConverter.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/pattern/ThrowableProxyConverter.java @@ -37,7 +37,6 @@ public class ThrowableProxyConverter extends ThrowableHandlingConverter { int lengthOption; List<EventEvaluator<ILoggingEvent>> evaluatorList = null; - final int MAX_ERROR_COUNT = 4; int errorCount = 0; @SuppressWarnings("unchecked") @@ -116,10 +115,10 @@ public class ThrowableProxyConverter extends ThrowableHandlingConverter { } } catch (EvaluationException eex) { errorCount++; - if (errorCount < MAX_ERROR_COUNT) { + if (errorCount < CoreConstants.MAX_ERROR_COUNT) { addError("Exception thrown for evaluator named [" + ee.getName() + "]", eex); - } else if (errorCount == MAX_ERROR_COUNT) { + } else if (errorCount == CoreConstants.MAX_ERROR_COUNT) { ErrorStatus errorStatus = new ErrorStatus( "Exception thrown for evaluator named [" + ee.getName() + "].", this, eex); diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/boolex/OnMarkerEvaluatorTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/OnMarkerEvaluatorTest.java new file mode 100644 index 0000000..d628307 --- /dev/null +++ b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/OnMarkerEvaluatorTest.java @@ -0,0 +1,55 @@ +package ch.qos.logback.classic.boolex; + +import static org.junit.Assert.assertFalse; +import static org.junit.Assert.assertTrue; + +import org.junit.Before; +import org.junit.Test; +import org.slf4j.MarkerFactory; + +import ch.qos.logback.classic.Level; +import ch.qos.logback.classic.LoggerContext; +import ch.qos.logback.classic.spi.LoggingEvent; +import ch.qos.logback.core.boolex.EvaluationException; + + +public class OnMarkerEvaluatorTest { + + + LoggerContext lc = new LoggerContext(); + LoggingEvent event = makeEvent(); + OnMarkerEvaluator evaluator = new OnMarkerEvaluator(); + + @Before + public void before() { + evaluator.setContext(lc); + } + + @Test + public void smoke() throws EvaluationException { + evaluator.addMarker("M"); + evaluator.start(); + + event.setMarker(MarkerFactory.getMarker("M")); + assertTrue(evaluator.evaluate(event)); + } + + @Test + public void nullMarkerInEvent() throws EvaluationException { + evaluator.addMarker("M"); + evaluator.start(); + assertFalse(evaluator.evaluate(event)); + } + + @Test + public void nullMarkerInEvaluator() throws EvaluationException { + evaluator.addMarker("M"); + evaluator.start(); + assertFalse(evaluator.evaluate(event)); + } + + + LoggingEvent makeEvent() { + return new LoggingEvent("x", lc.getLogger("x"), Level.DEBUG, "msg", null, null); + } +} diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/boolex/PackageTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/PackageTest.java index 5ee17d6..6f8165e 100644 --- a/logback-classic/src/test/java/ch/qos/logback/classic/boolex/PackageTest.java +++ b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/PackageTest.java @@ -17,9 +17,7 @@ import org.junit.runner.RunWith; import org.junit.runners.Suite; import org.junit.runners.Suite.SuiteClasses; -import ch.qos.logback.classic.jmx.JMXConfiguratorTest; - @RunWith(Suite.class) -(a)SuiteClasses(JMXConfiguratorTest.class) +(a)SuiteClasses({JaninoEventEvaluatorTest.class, OnMarkerEvaluatorTest.class}) public class PackageTest { } \ No newline at end of file diff --git a/logback-core/src/main/java/ch/qos/logback/core/CoreConstants.java b/logback-core/src/main/java/ch/qos/logback/core/CoreConstants.java index d42c015..ac1d8fd 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/CoreConstants.java +++ b/logback-core/src/main/java/ch/qos/logback/core/CoreConstants.java @@ -50,9 +50,6 @@ public class CoreConstants { * By convention, we assume that the static method named "valueOf" taking * a string argument can restore a given object from its string * representation. - * - * <p>Classes participating in this convention must be declared - * as stringStorable in a (logback) context. */ static public final String VALUE_OF = "valueOf"; @@ -93,6 +90,9 @@ public class CoreConstants { public static long REFERENCE_BIPS = 9000; + // maximum error acoutn to report + static public final int MAX_ERROR_COUNT = 4; + static public final char DOT = '.'; static public final char TAB = '\t'; diff --git a/logback-core/src/main/java/ch/qos/logback/core/WriterAppender.java b/logback-core/src/main/java/ch/qos/logback/core/WriterAppender.java index acc6430..d4e66d6 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/WriterAppender.java +++ b/logback-core/src/main/java/ch/qos/logback/core/WriterAppender.java @@ -265,7 +265,6 @@ public class WriterAppender<E> extends UnsynchronizedAppenderBase<E> { if (!isStarted()) { return; } - try { String output = this.layout.doLayout(event); synchronized (this) { diff --git a/logback-core/src/main/java/ch/qos/logback/core/net/SMTPAppenderBase.java b/logback-core/src/main/java/ch/qos/logback/core/net/SMTPAppenderBase.java index 469c1ce..37744f1 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/net/SMTPAppenderBase.java +++ b/logback-core/src/main/java/ch/qos/logback/core/net/SMTPAppenderBase.java @@ -30,6 +30,7 @@ import javax.mail.internet.MimeMessage; import javax.mail.internet.MimeMultipart; import ch.qos.logback.core.AppenderBase; +import ch.qos.logback.core.CoreConstants; import ch.qos.logback.core.Layout; import ch.qos.logback.core.boolex.EvaluationException; import ch.qos.logback.core.boolex.EventEvaluator; @@ -43,7 +44,8 @@ import ch.qos.logback.core.util.OptionHelper; * An abstract class that provides support for sending events to an email * address. * - * <p>See http://logback.qos.ch/manual/appenders.html#SMTPAppender for further + * <p> + * See http://logback.qos.ch/manual/appenders.html#SMTPAppender for further * documentation. * * @author Ceki Gülcü @@ -70,6 +72,8 @@ public abstract class SMTPAppenderBase<E> extends AppenderBase<E> { protected EventEvaluator<E> eventEvaluator; + private int errorCount = 0; + /** * return a layout for the subjet string as appropriate for the module. If the * subjectStr parameter is null, then a default value for subjectStr should be @@ -153,7 +157,10 @@ public abstract class SMTPAppenderBase<E> extends AppenderBase<E> { sendBuffer(eventObject); } } catch (EvaluationException ex) { - addError("SMTPAppender's EventEvaluator threw an Exception" + ex); + errorCount ++; + if (errorCount < CoreConstants.MAX_ERROR_COUNT) { + addError("SMTPAppender's EventEvaluator threw an Exception" + ex); + } } } @@ -162,9 +169,10 @@ public abstract class SMTPAppenderBase<E> extends AppenderBase<E> { /** * This method determines if there is a sense in attempting to append. * - * <p> It checks whether there is a set output target and also if there is a - * set layout. If these checks fail, then the boolean value <code>false</code> - * is returned. + * <p> + * It checks whether there is a set output target and also if there is a set + * layout. If these checks fail, then the boolean value <code>false</code> is + * returned. */ public boolean checkEntryConditions() { if (!this.started) { @@ -350,8 +358,8 @@ public abstract class SMTPAppenderBase<E> extends AppenderBase<E> { } /** - * The <b>To</b> option takes a string value which should be an e-mail - * address of one of the recipients. + * The <b>To</b> option takes a string value which should be an e-mail address + * of one of the recipients. */ public void addTo(String to) { this.to.add(to); @@ -384,8 +392,8 @@ public abstract class SMTPAppenderBase<E> extends AppenderBase<E> { } /** - * The <b>EventEvaluator</b> option takes a string value representing the - * name of the class implementing the {@link EventEvaluators} interface. A + * The <b>EventEvaluator</b> option takes a string value representing the name + * of the class implementing the {@link EventEvaluators} interface. A * corresponding object will be instantiated and assigned as the event * evaluator for the SMTPAppender. */ diff --git a/logback-examples/src/main/java/chapter4/mail/EMail.java b/logback-examples/src/main/java/chapter4/mail/EMail.java index f2fc78e..e592035 100644 --- a/logback-examples/src/main/java/chapter4/mail/EMail.java +++ b/logback-examples/src/main/java/chapter4/mail/EMail.java @@ -24,8 +24,7 @@ import ch.qos.logback.core.util.StatusPrinter; /** * This application generates log messages in numbers specified by the - * user. See - * also configuration scripts rolling.properties and rolling.xml. + * user. * */ public class EMail { static public void main(String[] args) throws Exception { diff --git a/logback-examples/src/main/java/chapter4/mail/EMail.java b/logback-examples/src/main/java/chapter4/mail/Marked_EMail.java similarity index 64% copy from logback-examples/src/main/java/chapter4/mail/EMail.java copy to logback-examples/src/main/java/chapter4/mail/Marked_EMail.java index f2fc78e..113eecd 100644 --- a/logback-examples/src/main/java/chapter4/mail/EMail.java +++ b/logback-examples/src/main/java/chapter4/mail/Marked_EMail.java @@ -15,26 +15,24 @@ package chapter4.mail; import org.slf4j.Logger; import org.slf4j.LoggerFactory; +import org.slf4j.Marker; +import org.slf4j.MarkerFactory; import ch.qos.logback.classic.LoggerContext; import ch.qos.logback.classic.joran.JoranConfigurator; import ch.qos.logback.core.util.StatusPrinter; - - /** - * This application generates log messages in numbers specified by the - * user. See - * also configuration scripts rolling.properties and rolling.xml. + * This application generates a number of message many of which are of LEVEL. + * However, only one message bears the "NOTIFY_ADMIN" marker. * */ -public class EMail { +public class Marked_EMail { static public void main(String[] args) throws Exception { - if (args.length != 2) { + if (args.length != 1) { usage("Wrong number of arguments."); } - int runLength = Integer.parseInt(args[0]); - String configFile = args[1]; + String configFile = args[0]; LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); JoranConfigurator configurator = new JoranConfigurator(); @@ -42,29 +40,31 @@ public class EMail { configurator.setContext(lc); configurator.doConfigure(configFile); StatusPrinter.printInCaseOfErrorsOrWarnings(lc); - - Logger logger = LoggerFactory.getLogger(EMail.class); + Logger logger = LoggerFactory.getLogger(Marked_EMail.class); + + int runLength = 100; for (int i = 1; i <= runLength; i++) { if ((i % 10) < 9) { logger.debug("This is a debug message. Message number: " + i); } else { - logger.warn("This is a warning message. Message number: " + i); + logger.error("This is an error message. Message number: " + i); } } - logger.error("At last an error.", new Exception("Just testing")); - + Marker notifyAdminMarker = MarkerFactory.getMarker("NOTIFY_ADMIN"); + logger.error(notifyAdminMarker, + "This is a serious an error requiring the admin's attention", + new Exception("Just testing")); + StatusPrinter.printInCaseOfErrorsOrWarnings(lc); } static void usage(String msg) { System.err.println(msg); - System.err.println("Usage: java " + EMail.class.getName() + - " runLength configFile\n" + - " runLength (integer) the number of logs to generate\n" + - " configFile a logback configuration file in XML format." + - " XML files must have a '.xml' extension."); + System.err.println("Usage: java " + Marked_EMail.class.getName() + + " configFile\n" + + " configFile a logback configuration file in XML format."); System.exit(1); } } diff --git a/logback-examples/src/main/java/chapter4/mail/mailWithMarker.xml b/logback-examples/src/main/java/chapter4/mail/mailWithMarker.xml new file mode 100644 index 0000000..4277f37 --- /dev/null +++ b/logback-examples/src/main/java/chapter4/mail/mailWithMarker.xml @@ -0,0 +1,21 @@ +<?xml version="1.0" encoding="UTF-8" ?> + +<configuration> + <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender"> + <evaluator class="ch.qos.logback.classic.boolex.OnMarkerEvaluator"> + <marker>NOTIFY_ADMIN</marker> + </evaluator> + <BufferSize>1050</BufferSize> + <SMTPHost>${smtpHost}</SMTPHost> + <To>${to}</To> + <From>${from}</From> + <layout class="ch.qos.logback.classic.html.HTMLLayout"/> + </appender> + + <root> + <level value ="debug"/> + <appender-ref ref="EMAIL" /> + </root> +</configuration> + + diff --git a/logback-site/src/site/pages/manual/appenders.html b/logback-site/src/site/pages/manual/appenders.html index a7474d2..48c55d2 100644 --- a/logback-site/src/site/pages/manual/appenders.html +++ b/logback-site/src/site/pages/manual/appenders.html @@ -2431,7 +2431,7 @@ Context ctx = new InitialContext(env);</pre> <p>You can pass the required parameters on the command line:</p> <div class="source"><pre>java -Dfrom=source(a)xyz.com -Dto=recipient(a)xyz.com -DsmtpHost=some_smtp_host \ - src/main/java/chapter4.mail.EMail 10000 chapter4/mail/mail2.xml + chapter4.mail.EMail 10000 src/main/java/chapter4/mail/mail2.xml </pre></div> <p>Be sure to replace with values as appropriate for your @@ -2471,23 +2471,26 @@ Context ctx = new InitialContext(env);</pre> <h3>Triggering event</h3> - <p>By default, the <code>SMTPAppender</code> will initiate the - transmission of an email message as a response to an event of - level <em>ERROR</em> or higher. However, it is possible to - override this default behavior by providing a custom - implementation of the <code>EventEvaluator</code> interface. - </p> + <p>If the Evaluator property is not set, the + <code>SMTPAppender</code> defaults to an <a + href="../xref/ch/qos/logback/classic/boolex/OnErrorEvaluator.html">OnErrorEveluator</a> + instance which triggers email transmission when it encounters an + event of level ERROR. While triggering an outgoing email in + response to an error is relatively reasonably, it is possible to + override this default behavior by providing a different + implementation of the <code>EventEvaluator</code> interface. + </p> <p>The <code>SMTPAppender</code> submits each incoming event to its evaluator by calling <code>evaluate()</code> method in order to check whether the event should trigger an email or just be placed in the cyclic buffer. When the evaluator gives a positive - answer to its evaluation, an email is sent. The + answer to its evaluation, an email is sent out. The <code>SMTPAppender</code> contains one and only one evaluator - object. This object may possess its own state. For illustrative - purposes, the <code>CounterBasedEvaluator</code> class listed - next, implements an event evaluator whereby every 1024th event - triggers an email message. + object. This object may manage its own internal state. For + illustrative purposes, the <code>CounterBasedEvaluator</code> + class listed next, implements an event evaluator whereby every + 1024th event triggers an email message. </p> <em>Example 4.<span class="autoEx"/>: A <code>EventEvaluator</code> implementation @@ -2560,6 +2563,55 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval </configuration></pre> + <h3><a name="OnMarkerEvaluator" href="#OnMarkerEvaluator">Marker + based triggering</a> + </h3> + + <p>Although reasonable, a policy whereby event's of level ERROR + trigger an outgoing email may result in too many emails, + cluttering the targeted user's mailbox. Logback ships with another + triggering policy, called <a + href="../xref/ch/qos/logback/classic/boolex/OnMarkerEvaluator.html">OnMarkerEvaluator</a>. It + is based on markers allowing for a very effective way for trigger + control. In essence, emails are triggered only if the event is + marked with a user-specified marker. An example should make the + point clearer. + </p> + + <p>The <a href="../xref/chapter4/mail/Marked_EMail.html">Marked_EMail</a> application contains several logging + statements some of which are of level ERROR. One noteworthy + statement contains a marker. Here is the relevant code. + </p> + + <pre class="prettyprint source">Marker notifyAdminMarker = MarkerFactory.getMarker("NOTIFY_ADMIN"); +logger.error(notifyAdminMarker, + "This is a serious an error requiring the admin's attention", + new Exception("Just testing"));</pre> + + + <em>Example 4.<span class="autoEx"/>: <code>SMTPAppender</code> with + <code>OnMarkerEvaluator</code> (logback-examples/src/main/java/chapter4/mail/mailWithMarker.xml)</em> + + <pre class="prettyprint source"><configuration> + <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender"> + <b><evaluator class="ch.qos.logback.classic.boolex.OnMarkerEvaluator"> + <marker>NOTIFY_ADMIN</marker> + </evaluator></b> + <BufferSize>1050</BufferSize> + <SMTPHost>${smtpHost}</SMTPHost> + <To>${to}</To> + <From>${from}</From> + <layout class="ch.qos.logback.classic.html.HTMLLayout"/> + </appender> + + <root> + <level value ="debug"/> + <appender-ref ref="EMAIL" /> + </root> +</configuration></pre> + + + <h3><a name="smtpAuthentication" href="#smtpAuthentication">Authentication/STARTTLS/SSL</a></h3> ----------------------------------------------------------------------- Summary of changes: ...nErrorEvaluator.java => OnMarkerEvaluator.java} | 36 +++++++-- .../classic/pattern/ThrowableProxyConverter.java | 5 +- .../classic/boolex/OnMarkerEvaluatorTest.java | 55 ++++++++++++++ .../ch/qos/logback/classic/boolex/PackageTest.java | 4 +- .../java/ch/qos/logback/core/CoreConstants.java | 6 +- .../java/ch/qos/logback/core/WriterAppender.java | 1 - .../ch/qos/logback/core/net/SMTPAppenderBase.java | 26 +++++--- .../src/main/java/chapter4/mail/EMail.java | 3 +- .../mail/{EMail.java => Marked_EMail.java} | 38 +++++----- .../mail/{mail2.xml => mailWithMarker.xml} | 8 ++- logback-site/src/site/pages/manual/appenders.html | 76 ++++++++++++++++--- 11 files changed, 196 insertions(+), 62 deletions(-) copy logback-classic/src/main/java/ch/qos/logback/classic/boolex/{OnErrorEvaluator.java => OnMarkerEvaluator.java} (57%) create mode 100644 logback-classic/src/test/java/ch/qos/logback/classic/boolex/OnMarkerEvaluatorTest.java copy logback-examples/src/main/java/chapter4/mail/{EMail.java => Marked_EMail.java} (64%) copy logback-examples/src/main/java/chapter4/mail/{mail2.xml => mailWithMarker.xml} (64%) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCORE-135) Limit the number of outgoing emails via SMTPAppender
by Ceki Gulcu (JIRA) 06 Jan '10

06 Jan '10

Limit the number of outgoing emails via SMTPAppender ---------------------------------------------------- Key: LBCORE-135 URL: http://jira.qos.ch/browse/LBCORE-135 Project: logback-core Issue Type: New Feature Components: Appender Affects Versions: unspecified Reporter: Ceki Gulcu Assignee: Logback dev list Limit the rate of outgoing emails via SMTPAppender. Under certain circumctances, there might be a repetition of errors and the emails triggered thereby quickly become irritating. This was also requested in http://stackoverflow.com/questions/1993038/logback-smtpappender-limiting-ra… -- 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 0

[JIRA] Created: (LBCLASSIC-179) please add Eclipse Buddy Policy
by ekkehard gentz (JIRA) 05 Jan '10

05 Jan '10

please add Eclipse Buddy Policy ------------------------------- Key: LBCLASSIC-179 URL: http://jira.qos.ch/browse/LBCLASSIC-179 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.18 Reporter: ekkehard gentz Assignee: Logback dev list if you're using LogBack in an Eclipse Equinox OSGI environment and you write Appenders or Converters then logback.classic must "know" them. One way is to use a Fragment Bundle with logback.classic as host bundle. But Fragments are not very flexible and you have to restart your OSGI Framework. If using Eclipse Equinox as OSGI Framework you can use Eclipse Buddy Policy read more here: http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements It would be great if you add the following line to MANIFEST.MF of logback.classic bundle: Eclipse-BuddyPolicy: registered If running in other OSGI Frameworks like Felix this line will be ignored, but running Equinox you can now do the following: my.appender.bundle has Dependency to logback.classic as Required Bundle and I can add Eclipse-RegisterBuddy: logback.classic Now my Bundle is a Buddy of logback.classic and logback.classic 'knows' my classes -- 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 0

[JIRA] Created: (LBCLASSIC-178) Logger.callAppenders() doesn´t call TurboFilters
by David Sanz (JIRA) 03 Jan '10

03 Jan '10

Logger.callAppenders() doesn´t call TurboFilters ------------------------------------------------ Key: LBCLASSIC-178 URL: http://jira.qos.ch/browse/LBCLASSIC-178 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.18 Environment: Platform independent Reporter: David Sanz Assignee: Logback dev list Using JMSQueueAppender for remote logging, and Logger.callAppenders() in the server sid,e never reload de logback configuration files. I am developing a client application, let´s say App1. App1 use the logback JMSQueueAppender, to deliver logging events to a Message Driven Bean, in the server side. As proposed in the logback manual my Message Driven Bean implements the following lines (simplified to make the explanation easier to understand) public void onMessage(javax.jms.Message message) { ILoggingEvent event; ... ObjectMessage objectMessage = (ObjectMessage) message; event = (ILoggingEvent) objectMessage.getObject(); Logger log = (Logger) LoggerFactory.getLogger(event.getLoggerName()); log.callAppenders(event); This is the only way i use Logger in the server side. I never use calls like log.debug(...) or similars In the server-side (MDB) I have set up a configuration with these line: <configuration scan="true" scanPeriod="30 seconds" > File automatically reload every 30 seconds. The problem is that it never reloads the configuration file. The cause is the following. In the logback site we can read, about the scan attribute in the configuration file: " Behind the scenes, when you set the scan attribute to true, a TurboFilter called ReconfigureOnChangeFilter will be installed. TurboFilters are described in a later chapter. As a consequence, scanning is done "in-thread", that is anytime a printing method of logger is invoked. " And the fact is that Logger.callAppenders() doesn´t check the turbofilters, and thus it never reloads the configuration file. Proposed solution: (may be is not de correct one, but i think it could solve the problem): Modify callAppenders(ILoggingEvent event) Add the following line at the beggining of the method: boolean enabled = isEnabledFor(event.getLevel()); //call indirectly turbofilters and besides we could use enabled to return directly (if not enabled) if (!enabled) { return } So the new code could be something like /** * Invoke all the appenders of this logger. * * @param event * The event to log */ public void callAppenders(ILoggingEvent event) { boolean enabled = isEnabledFor(event.getLevel()); if (!enabled) { return ; } int writes = 0; for (Logger l = this; l != null; l = l.parent) { writes += l.appendLoopOnAppenders(event); if (!l.additive) { break; } } // No appenders in hierarchy if (writes == 0) { loggerContext.noAppenderDefinedWarning(this); } } 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 6

logback async appender
by Gordon Sims 02 Jan '10

02 Jan '10

We recently switched several applications from log4j to logback and were wondering about the lack of async appender in logback. Is it not needed? I thought it was a good thing for performance and reliability reasons. I see there is an old enhancement request for it in logback bugzilla, http://bugzilla.qos.ch/show_bug.cgi?id=55 It seems that someone attempted this earlier this year (but maybe hasn't checked in yet?) http://old.nabble.com/how-to-get-appender-ref-list-via-Joran-to22295581.htm… If needed and desired, we could work on a patch for this feature. In general, should it work similar to the log4j one? Or is someone else already working on it? thanks, -Gordon

3 3

[JIRA] Created: (LBCLASSIC-175) ILoggingEvent prepareForDeferredProcessing does not include callerDataArray
by Konstantin Alexandrov (JIRA) 02 Jan '10

02 Jan '10

ILoggingEvent prepareForDeferredProcessing does not include callerDataArray --------------------------------------------------------------------------- Key: LBCLASSIC-175 URL: http://jira.qos.ch/browse/LBCLASSIC-175 Project: logback-classic Issue Type: Bug Components: layout Reporter: Konstantin Alexandrov Assignee: Logback dev list I've implement asynchronous file appender, and enqueue events, but %caller pattern can not be used in the case of deferred processing becouse caller information is losed. My suggestion is to create Throwable object in prepareForDeferredProcessing -- 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 7

[JIRA] Created: (LBCORE-132) Provide interface with method prepareForDeferredProcessing()
by Torsten Juergeleit (JIRA) 02 Jan '10

02 Jan '10

Provide interface with method prepareForDeferredProcessing() ------------------------------------------------------------ Key: LBCORE-132 URL: http://jira.qos.ch/browse/LBCORE-132 Project: logback-core Issue Type: Improvement Reporter: Torsten Juergeleit Assignee: Logback dev list Currently both logback event classes (LoggingEvent and AccessEvent) are implementing the method prepareForDeferredProcessing(). To allow calling this method for both event types from within a logback-core appender (e.g. the one suggested in LBCLASSIC-177) this method has to be defined within a logback-core interface. Additionally the method prepareForDeferredProcessing() should support two behaviors: 1) preparing only the "cheap" stuff like thread name or MDC 2) preparing everything including the "expensive" stuff like caller data -> this would solve LBCLASSIC-175 So how about defining an interface like the following? package ch.qos.logback.core.spi; public interface Event { void prepareForDeferredProcessing(boolean doFullPreparation); } Maybe the method getTimeStamp() implemented by both event types could be part of this interface as well. -- 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 0

[JIRA] Created: (LBCLASSIC-172) Use WeakHashMap instead of Hashtable in LoggerContext
by Joern Huxhorn (JIRA) 15 Dec '09

15 Dec '09

Use WeakHashMap instead of Hashtable in LoggerContext ----------------------------------------------------- Key: LBCLASSIC-172 URL: http://jira.qos.ch/browse/LBCLASSIC-172 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.18 Reporter: Joern Huxhorn Assignee: Logback dev list Preventing garbage-collection of unused Loggers is a bad idea. The following code should not fail: for(int i=0;i<10000000;i++) { LoggerFactory.getLogger("Foo."+i).debug("Foo!"); } -- 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 17

[JIRA] Created: (LBCLASSIC-102) Suggestion: Change logger name of inner classes.
by Joern Huxhorn (JIRA) 15 Dec '09

15 Dec '09

Suggestion: Change logger name of inner classes. ------------------------------------------------ Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Logback dev list At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons. -- 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 14

[JIRA] Created: (LBCLASSIC-174) LoggingContextSelect JNDI No context creating threads in a EJB
by Miguel Goyena (JIRA) 14 Dec '09

14 Dec '09

LoggingContextSelect JNDI No context creating threads in a EJB -------------------------------------------------------------- Key: LBCLASSIC-174 URL: http://jira.qos.ch/browse/LBCLASSIC-174 Project: logback-classic Issue Type: Bug Environment: Application (EJB jar, WAR) deployed in JBOSS 5.0.1 Reporter: Miguel Goyena Assignee: Logback dev list I'm using LoggingContextSelect JNDI. My application es an ear deployed in JBOSS, with three WAR and a EJB session jar. One of the servlet in a WAR uses the Sesssion EJB. In the EJB Session Method I create a Thread, and start it MandarMensajes threadException = new MandarMensajes(tipo,cuantos,cadaCuanto); threadException.start(); In this thread the run method uses logback for logging. Logger logger = LoggerFactory.getLogger(this); logger.logDebug("Hello"); But the logger I get have a default context!!!!!!, not the context defined in the JNDI. Only happends this when a use the thread in the Session EJB. If I use the MandarMensajes thread in the servlet everything is correct. If I get a logger anywhere else in the EJB Session everything is correct. If I use the run() method of ManderMensajes in the EJB Session everything is correct. Even if I get the MDC objet when thread is executing, all the values I put in servletare there; b ut the context is default, so it never uses my logback-Application.xml config file!!!!. -- 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 0