Author: ceki Date: Mon Feb 26 08:27:06 2007 New Revision: 769 Modified: slf4j/trunk/slf4j-site/src/site/resources/faq.html slf4j/trunk/slf4j-site/src/site/resources/index.html slf4j/trunk/slf4j-site/src/site/resources/news.html
Log: minor doc enhancements Modified: slf4j/trunk/slf4j-site/src/site/resources/faq.html ============================================================================== --- slf4j/trunk/slf4j-site/src/site/resources/faq.html (original) +++ slf4j/trunk/slf4j-site/src/site/resources/faq.html Mon Feb 26 08:27:06 2007 @@ -275,7 +275,7 @@ <em>slf4j-simple.jar</em>, <em>slf4j-log4j12.jar</em>, and <em>slf4j-jdk14.jar</em>. These files ship with the <a href="download.html">official SLF4J distribution</a>. Please - note that all binding depend on <em>slf4j-api.jar</em>. + note that all bindings depend on <em>slf4j-api.jar</em>. </p> <p>The binding for logback-classic ships with the <a Modified: slf4j/trunk/slf4j-site/src/site/resources/index.html ============================================================================== --- slf4j/trunk/slf4j-site/src/site/resources/index.html (original) +++ slf4j/trunk/slf4j-site/src/site/resources/index.html Mon Feb 26 08:27:06 2007 @@ -52,13 +52,13 @@ <p>SLF4J does not rely on any special class loader machinery. In fact, the binding between SLF4J and a given logging API implementation is performed <em>statically</em> at compile time of - each binding. Each binding is hardwired to use one and only one specific - logging API implementation. Each binding corresponds to one jar - file. In your code, you simply drop the binding of your choice, that - is a jar file, onto the appropriate class path location. As a - consequence of this simple approach, SLF4J suffers from none of the - class loader problems or memory leaks observed with Jakarta Commons - Logging (JCL). + each binding. Each binding is hardwired to use one and only one + specific logging API implementation. Each binding corresponds to one + jar file. In your code, in addition to <em>slf4j-api.jar</em>, you + simply drop the binding of your choice, that is a jar file, onto the + appropriate class path location. As a consequence of this simple + approach, SLF4J suffers from none of the class loader problems or + memory leaks observed with Jakarta Commons Logging (JCL). </p> <p>We hope that simplicity of the SLF4J interfaces and the deployment @@ -68,8 +68,8 @@ <h3>Projects depending on SLF4j</h3> - <p>Here is a short list of projects currently depending on SLF4J (in - alphabetical order): + <p>Here is a non-exhaustive list of projects currently depending on + SLF4J, in alphabetical order: </p> <ul> Modified: slf4j/trunk/slf4j-site/src/site/resources/news.html ============================================================================== --- slf4j/trunk/slf4j-site/src/site/resources/news.html (original) +++ slf4j/trunk/slf4j-site/src/site/resources/news.html Mon Feb 26 08:27:06 2007 @@ -22,8 +22,9 @@ <h1>SLF4J News</h1> - <p>You can receive SLF4J related announcements by subscribing to the - <a href="http://www.slf4j.org/mailman/listinfo/announce">SLF4J + <p>Please note that you can receive SLF4J related announcements by + subscribing to the <a + href="http://www.slf4j.org/mailman/listinfo/announce">SLF4J announce</a> mailing list. </p> @@ -35,16 +36,19 @@ projects. More specifically, the <code>org.slf4j.LoggerFactory</code> class is now packaged within the <em>slf4j-api.jar</em> file instead of the various slf4j - bindings. It follows that client code needs to depend on only + bindings. <b>It follows that client code needs to depend on only slf4j-api in order to compile, while the various slf4j bindings are - only needed as runtime dependencies. See also the <a - href="faq.html#maven2">Maven2-related FAQ entry</a>. + only needed as runtime dependencies.</b> See also the <a + href="faq.html#maven2">Maven2-related FAQ entry</a>. Given the + practical significance of this change, we highly recommend that + library-authors upgrade to version 1.3 at their earliest + convenience. </p> - <p><a href="http://bugzilla.slf4j.org/show_bug.cgi?id=23">Bug - number 23</a> has been fixed, at the cost of minor and backward - compatible changes. In other words, jcl104-over-slf4j now - preserves caller location information. + <p><a href="http://bugzilla.slf4j.org/show_bug.cgi?id=23">Bug number + 23</a> has been fixed, at the cost of minor and backward compatible + changes. In other words, jcl104-over-slf4j now preserves caller + location information. </p> <p>It is now possible to obtain the root logger of the underlying _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev