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 14b4011e47ee2c6452af2cf066b5d930d4da11b3 (commit) from 990f24180a7fe18040a851a71f6fab06a4f18604 (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=14b4011e47ee2c6452af2cf066b... http://github.com/ceki/slf4j/commit/14b4011e47ee2c6452af2cf066b5d930d4da11b3 commit 14b4011e47ee2c6452af2cf066b5d930d4da11b3 Author: Ceki Gulcu <ceki@qos.ch> Date: Wed Jul 14 17:01:14 2010 +0200 doc edits diff --git a/slf4j-site/src/site/pages/codes.html b/slf4j-site/src/site/pages/codes.html index ff2281c..bcbd015 100644 --- a/slf4j-site/src/site/pages/codes.html +++ b/slf4j-site/src/site/pages/codes.html @@ -320,21 +320,20 @@ version does not match that of the binding</a></h3> <p>Mixing mixing different versions of slf4j artifacts can cause - problems. For example, if you are using slf4j-api-1.5.5.jar, then - you should also use slf4j-simple-1.5.5.jar, using - slf4j-simple-1.4.2.jar will not work. + problems. For example, if you are using + slf4j-api-${project.version}.jar, then you should also use + slf4j-simple-${project.version}.jar, using slf4j-simple-1.5.5.jar + will not work. </p> - <p>In general, you should make sure that the slf4j-api version - matches that of the slf4j binding. + <p class="red">In general, you should make sure that the + slf4j-api version matches that of the slf4j binding. </p> <p>At initialization time, if SLF4J suspects that there may be a - mismatch problem, it emits a warning about the said mismatch. - </p> - - <p>For the exact details of the version mismatch detection - mechanism, please refer to the <a + version mismatch problem, it will emit a warning about the + suspected mismatch. For the exact details of the version mismatch + detection mechanism, please refer to the <a href="faq.html#version_checks">relevant entry</a> in the FAQ. </p> diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index 2b26572..d079147 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -1245,9 +1245,9 @@ try { <dd> <p>The version check performed by SLF4J API during its - initialization is an elective process. Conforming SLF4J - implementations may choose <em>not</em> to participate, in - which case, no version check will be performed. + initialization is an <em>elective</em> process. Conforming SLF4J + implementations may choose <em>not</em> to participate, in which + case, no version check will be performed. </p> <p>However, if an SLF4J implementation decides to participate, @@ -1273,23 +1273,17 @@ try { <p><b>As of SLF4J 1.5.5</b>, all bindings shipped within the SLF4J distribution, e.g. slf4j-logj12, slf4j-simple and slf4j-jdk14, declare the REQUESTED_API_VERSION field with a - value equal to their SLF4J version. It follows that, for - example if slf4j-simple-1.5.6.jar is mixed with - slf4j-api-1.5.5.jar, then a version mismatch warning will be - issued. Note that SLF4J versions prior to 1.5.5 did not have a - version check mechanism. Only slf4j-api-1.5.5.jar and later - can emit version mismatch warnings. (Actually, version 1.5.4 - offered a check policy which was much too restrictive and - inconsistent with the size of our user base. Consequently, - SLF4J version 1.5.5 was released just a day after 1.5.4.) - </p> - - <p>Given its large installed user base and several external - implementations, it would have been unwise to expect all SLF4J - implementations to closely follow SLF4J's release schedule, let - alone align their release schedules with SLF4J. Hence, the - elective version check policy. + value equal to their SLF4J version. It follows that, for example + if slf4j-simple-1.5.8.jar is mixed with slf4j-api-1.6.0.jar, + given that 1.5.8 is not on the compatibility list of SLF4J + version 1.6.x, a version mismatch warning will be issued. </p> + + <p>Note that SLF4J versions prior to 1.5.5 did not have a + version check mechanism. Only slf4j-api-1.5.5.jar and later can + emit version mismatch warnings. + </p> + </dd> diff --git a/slf4j-site/src/site/pages/manual.html b/slf4j-site/src/site/pages/manual.html index 0f51f00..0c79c40 100644 --- a/slf4j-site/src/site/pages/manual.html +++ b/slf4j-site/src/site/pages/manual.html @@ -191,9 +191,9 @@ public class HelloWorld { (JCL). </p> - <p>Hopefully, the simplicity of the SLF4J interfaces and the - deployment model will make it easy for developers of other - logging frameworks to conform to the SLF4J model. + <p>Given the simplicity of the SLF4J interfaces and its + deployment model, developers of new logging frameworks should + find it very easy to write SLF4J bindings. </p> <h3><a name="libraries" href="#libraries">Libraries</a></h3> @@ -201,17 +201,20 @@ public class HelloWorld { <p>Authors of widely-distributed components and libraries may code against the SLF4J interface in order to avoid imposing an logging framework on the end-user of the component or library. - He or she may choose the desired logging framework at deployment - time by inserting the desired slf4j binding on the classpath, - which may be changed later by replacing an existing binding with - another on the class path and restarting the application. This - approach has proven to be simple and very robust. + Thus, the end-user may choose the desired logging framework at + deployment time by inserting the corresponding slf4j binding on + the classpath, which may be changed later by replacing an + existing binding with another on the class path and restarting + the application. This approach has proven to be simple and very + robust. </p> <p><b>As of SLF4J version 1.6.0</b>, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of - throwing an exception, SLF4J will emit a single warning message + throwing a <code>NoClassDefFoundError</code> because the + <code>org.slf4j.impl.StaticLoggerBinder</code> class is missing, + SLF4J version 1.6.0 and later will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. For example, let Wombat be some biology-related framework depending on SLF4J for @@ -220,8 +223,9 @@ public class HelloWorld { but no binding. Even in the absence of any SLF4J binding on the class path, Wombat's distribution will still work out-of-the-box, and without requiring the end-user to download a - binding from SLF4J's web-site. Only when the end-user wishes to - enable logging will she need to install a binding. + binding from SLF4J's web-site. Only when the end-user decides to + enable logging will she need to install the SLF4J binding + corresponding to the logging framework chosen by the end-user. </p> <h3><a name="consolidate" href="#consolidate">Consolidate ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/codes.html | 19 +++++++++---------- slf4j-site/src/site/pages/faq.html | 32 +++++++++++++------------------- slf4j-site/src/site/pages/manual.html | 26 +++++++++++++++----------- 3 files changed, 37 insertions(+), 40 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java