[slf4j-dev] [GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v_1.6.1-41-gced19de
added by portage for gitosis-gentoo
git-noreply at pixie.qos.ch
Mon Aug 15 18:59:56 CEST 2011
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 "SLF4J: Simple Logging Facade for Java".
The branch, master has been updated
via ced19dedec4206252d911b9c947c439117ee6702 (commit)
from e452403419909770f558226c639a7d7e94d1715d (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=slf4j.git;a=commit;h=ced19dedec4206252d911b9c947c439117ee6702
http://github.com/ceki/slf4j/commit/ced19dedec4206252d911b9c947c439117ee6702
commit ced19dedec4206252d911b9c947c439117ee6702
Author: Ceki Gulcu <ceki at qos.ch>
Date: Mon Aug 15 18:57:38 2011 +0200
- Fix #138
- FAQ entry on the FATAL level now is based on the superiority of markers
diff --git a/pom.xml b/pom.xml
index 5f688b0..db7496a 100644
--- a/pom.xml
+++ b/pom.xml
@@ -35,7 +35,7 @@
<modules>
<module>slf4j-api</module>
- <module>slf4j-scala-api</module>
+ <!--<module>slf4j-scala-api</module>-->
<module>slf4j-simple</module>
<module>slf4j-nop</module>
<module>slf4j-jdk14</module>
diff --git a/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java b/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java
index c2063f3..49e97fe 100644
--- a/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java
+++ b/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java
@@ -26,10 +26,7 @@ package org.slf4j;
import java.io.IOException;
import java.net.URL;
-import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.Enumeration;
-import java.util.List;
+import java.util.*;
import org.slf4j.helpers.NOPLoggerFactory;
import org.slf4j.helpers.SubstituteLoggerFactory;
@@ -212,15 +209,19 @@ public final class LoggerFactory {
paths = loggerFactoryClassLoader
.getResources(STATIC_LOGGER_BINDER_PATH);
}
- List implementationList = new ArrayList();
+ // use Set instead of list in order to deal with bug #138
+ // LinkedHashSet appropriate here because it preserves insertion order during iteration
+ Set implementationSet = new LinkedHashSet();
while (paths.hasMoreElements()) {
URL path = (URL) paths.nextElement();
- implementationList.add(path);
+ implementationSet.add(path);
}
- if (implementationList.size() > 1) {
+ if (implementationSet.size() > 1) {
Util.report("Class path contains multiple SLF4J bindings.");
- for (int i = 0; i < implementationList.size(); i++) {
- Util.report("Found binding in [" + implementationList.get(i) + "]");
+ Iterator iterator = implementationSet.iterator();
+ while(iterator.hasNext()) {
+ URL path = (URL) iterator.next();
+ Util.report("Found binding in [" + path + "]");
}
Util.report("See " + MULTIPLE_BINDINGS_URL + " for an explanation.");
}
diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html
index ef70379..dbae2c6 100644
--- a/slf4j-site/src/site/pages/faq.html
+++ b/slf4j-site/src/site/pages/faq.html
@@ -994,38 +994,63 @@ logger.debug("The new entry is {}.", entry);</pre>
<dt>
<a name="fatal" href="#fatal"> Why doesn't the
- <code>org.slf4j.Logger</code> interface have methods for the FATAL
- level? </a>
+ <code>org.slf4j.Logger</code> interface have methods for the
+ FATAL level? </a>
</dt>
<dd>
- <p>From the stand point of a logging system, the distinction
- between a fatal error and an error is usually not very
- useful. Most programmers exit the application when a fatal
- error is encountered. However, a logging library cannot (and
- should not) decide on its own to terminate an
- application. The initiative to exit the application must be
- left to the developer.
+ <p>The <a href="apidocs/org/slf4j/Marker.html">Marker</a>
+ interface, part of the <code>org.slf4j</code> package, renders
+ the FATAL level largely redundant. If a given error requires
+ attention beyond that allocated for ordinary errors, simply mark
+ the logging statement with a specially designated marker which
+ can be named "FATAL" or any other name to your liking.
</p>
-
-
- <p>Thus, the most the FATAL level can do is to
- <em>highlight</em> a given error as the cause for
- application to crash. However, errors are by definition
- exceptional events that merit attention. If a given
- situation causes errors to be logged, the causes should be
- attended to as soon as possible. However, if the "error" is
- actually a normal situation which cannot be prevented but
- merits being aware of, then it should be marked as WARN, not
- ERROR.
+
+ <p>Here is an example,</p>
+
+<pre class="prettyprint">import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.slf4j.Marker;
+import org.slf4j.MarkerFactory;
+
+class Bar {
+ void foo() {
+ <b>Marker fatal = MarkerFactory.getMarker("FATAL");</b>
+ Logger logger = LoggerFactory.getLogger("aLogger");
+
+ try {
+ ... obtain a JDBC connection
+ } catch (JDBException e) {
+ logger.error(<b>fatal</b>, "Failed to obtain JDBC connection", e);
+ }
+ }
+}</pre>
+
+
+ <p>While markers are part of the SLF4J API, only logback
+ supports markers off the shelf. For example, if you add the
+ <code>%marker</code> conversion word to its pattern, logback's
+ <code>PatternLayout</code> will add marker data to its
+ output. Marker data can be used to <a
+ href="http://logback.qos.ch/manual/filters.html">filter
+ messages</a> or even <a
+ href="http://logback.qos.ch/manual/appenders.html#OnMarkerEvaluator">trigger</a>
+ an outgoing email <a
+ href="http://logback.qos.ch/recipes/emailPerTransaction.html">at
+ the end of an individual transaction</a>.
</p>
-
- <p>Assuming the ERROR level designates exceptional situations
- meriting close attention, we are inclined to believe that the
- FATAL level is superfluous.
+
+ <p>In combination with logging frameworks such as log4j and
+ java.util.logging which do not support markers, marker data will
+ be silently ignored.</p>
+
+ <p>Markers add a new dimension with infinite possible values for
+ processing log statements compared to five values, namely ERROR,
+ WARN, INFO, DEBUG and TRACE, allowed by levels. At present time,
+ only logback supports marker data. However, nothing prevents
+ other logging frameworks from making use of marker data.
</p>
-
-
<hr />
</dd>
diff --git a/slf4j-site/src/site/pages/news.html b/slf4j-site/src/site/pages/news.html
index a60a10e..55c91f5 100644
--- a/slf4j-site/src/site/pages/news.html
+++ b/slf4j-site/src/site/pages/news.html
@@ -29,7 +29,14 @@
<hr noshade="noshade" size="1"/>
- <h3>, 2011 - Release of SLF4J 1.6.2</h3>
+ <h3>August xth, 2011 - Release of SLF4J 1.6.2</h3>
+
+
+ <p>Fixed <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=138">bug
+ #138</a>. SLF4J will no longer complain about multiple SLF4J
+ bindings when running under a Weblogic server.
+ </p>
<p>Added certain missing classes to the log4j-over-slf4j module as
requested in <a
-----------------------------------------------------------------------
Summary of changes:
pom.xml | 2 +-
.../src/main/java/org/slf4j/LoggerFactory.java | 19 +++---
slf4j-site/src/site/pages/faq.html | 77 +++++++++++++-------
slf4j-site/src/site/pages/news.html | 9 ++-
4 files changed, 70 insertions(+), 37 deletions(-)
hooks/post-receive
--
SLF4J: Simple Logging Facade for Java
More information about the slf4j-dev
mailing list