[slf4j-dev] svn commit: r778 - slf4j/trunk/slf4j-site/src/site/pages
ceki at slf4j.org
ceki at slf4j.org
Sat Mar 3 22:06:04 CET 2007
Author: ceki
Date: Sat Mar 3 22:06:04 2007
New Revision: 778
Added:
slf4j/trunk/slf4j-site/src/site/pages/
slf4j/trunk/slf4j-site/src/site/pages/bug-reporting.html
slf4j/trunk/slf4j-site/src/site/pages/codes.html
slf4j/trunk/slf4j-site/src/site/pages/docs.html
slf4j/trunk/slf4j-site/src/site/pages/download.html
slf4j/trunk/slf4j-site/src/site/pages/faq.html
slf4j/trunk/slf4j-site/src/site/pages/inde_base.html
slf4j/trunk/slf4j-site/src/site/pages/index.html
slf4j/trunk/slf4j-site/src/site/pages/license.html
slf4j/trunk/slf4j-site/src/site/pages/mailing-lists.html
slf4j/trunk/slf4j-site/src/site/pages/manual.html
slf4j/trunk/slf4j-site/src/site/pages/news.html
slf4j/trunk/slf4j-site/src/site/pages/svn.html
Log:
moving files from slf4j-site/src/site/resources to slf4j-site/src/site/pages
Added: slf4j/trunk/slf4j-site/src/site/pages/bug-reporting.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/bug-reporting.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,98 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J Bug reporting</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+
+ <h1>Before you report a bug</h1>
+
+ <p>The SLF4J community consists of those who use SLF4J and its
+ implementations, help answer questions on discussions lists,
+ contribute documentation and patches, and those who develop and
+ maintain the code for SLF4J and its implementations. Almost all
+ those who assist on a day to day basis resolving bug reports do
+ this for a wide variety of reasons, and almost all of them do this
+ on their own time.
+ </p>
+
+ <p>Many bugs reported end up not being a bug in SLF4J, but are due
+ to misconfiguration, problems caused by installed applications,
+ the operating system, etc.
+ </p>
+
+ <p>Before reporting a bug please make every effort to resolve the
+ problem yourself. <em>Just reporting a bug will not fix it. A good
+ bug report includes a detailed description of the problem and a
+ succinct test case which can reproduce the problem.</em>
+ </p>
+
+ <h3>Review the documentation</h3>
+
+ <p>Review the documentation for the version of component you are
+ using. The problem you are having may already be addressed in the
+ docs.
+ </p>
+
+ <h3>Search the mailing list archives</h3>
+
+ <p>It is very likely you are not the first to run into a problem.
+ Others may have already found a solution. Our various <a
+ href="mailing-lists.html">mailing lists</a> are likely to have
+ discussed this problem before.
+ </p>
+
+ <h3>Search Bugzilla</h3>
+
+ <p>Please search the bug database to see if the bug you are seeing
+ has already been reported. The bug may have already been fixed
+ and is available in a later version. If someone else has reported
+ the same bug, you could add supporting information to help
+ reproduce and resolve the bug.
+ </p>
+
+ <ul>
+ <li>
+ <a href="http://bugzilla.slf4j.org/query.cgi?product=SLF4J">Search for <b>SLF4J</b> bugs</a>
+ </li>
+ </ul>
+ <h2>Reporting with Bugzilla</h2>
+
+ <p>Onlly after you have exhausted the aforementioned steps, should
+ you file a formal report in bugzilla.
+ </p>
+
+ <p>Please make sure you provide as much information as
+ possible. Its very hard to fix a bug if the person looking into
+ the problem can't reproduce it.
+ </p>
+
+ <ul>
+ <li><a
+ href="http://bugzilla.slf4j.org/enter_bug.cgi?product=SLF4J">Report
+ new <b>SLF4J</b> bug</a>
+ </li>
+ </ul>
+
+
+
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/codes.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/codes.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,79 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J Error Codes</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+ <center>
+ <h2>SLF4J warning or error messages and their meanings</h2>
+ <h3>Ceki Gülcü <br/>
+ created May 2006, last updated on May 2006</h3>
+ </center>
+
+
+ <a name="release">
+ </a>
+
+ <h3>The method
+ <code>o.a.commons.logging.impl.SLF4FLogFactory#release</code>
+ was invoked.
+ </h3>
+
+ <p>Given the structure of the commons-logging API, in particular
+ as implemented by SLF4J, the
+ <code>o.a.commons.logging.impl.SLF4FLogFactory#release()</code>
+ method should never be called. However, depending on the
+ deployment of <em>commons-logging.jar</em> files in your servlet
+ container, <code>release()</code> may be unexpectedly invoked by a
+ copy of <code>org.apache.commons.logging.LogFactory</code> class
+ shipping with <em>commons-logging.jar</em>.
+ </p>
+
+ <p>This is a relatively common occurrence with recent versions of
+ Tomcat, especially if you place <em>jcl104-over-slf4j.jar</em> in
+ <em>WEB-INF/lib</em> directory of your web-application instead of
+ <em>$TOMCAT_HOME/common/lib</em> where $TOMCAT_HOME stands for the
+ directory where Tomcat is installed. In order to fully benefit
+ from the stability offered by <em>jcl104-over-slf4j.jar</em>, we
+ recommend that you place <em>jcl104-over-slf4j.jar</em> in
+ <em>$TOMCAT_HOME/common/lib</em> without placing a copy in your
+ web-applications.
+ </p>
+
+ <p>Please also see <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=22">bug
+ #22</a>.</p>
+
+ <a name="null_LF">
+ </a>
+
+ <h3>Logging factory implementation cannot be null</h3>
+
+ <p>This error is reported when the <code>LoggerFactory</code>
+ class could not find an appropriate binding, indicating that no
+ appropriate SLF4J binding could be found. Placing one of
+ <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
+ <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or
+ <em>logback-classic.jar</em> should prove to be an effective
+ remedy.
+ </p>
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/docs.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/docs.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,46 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J Documentation</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+ <h1>Documentation</h1>
+
+ <p>Given the small size of SLF4J, its documentation is not very
+ lengthy.</p>
+
+ <ul>
+ <li><a href="manual.html">User manual</a></li>
+ <li><a href="api/index.html">javadocs</a></li>
+ <li><a href="xref/index.html">sources</a></li>
+ <li><a href="faq.html">FAQ</a></li>
+ </ul>
+
+ <h2>Articles</h2>
+
+ <ul>
+ <li><a
+ href="http://eclipsezone.com/articles/franey-logging/?source=archives">Universal
+ Logger Plug-ins for RCP Applications</a>, by John J. Franey
+ </li>
+ </ul>
+</h2>
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/download.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/download.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,46 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J Binary files</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+
+
+ <h2>Latest official SLF4J version</h2>
+
+ <p>Download version 1.3.0 including <i>full source code</i>,
+ class files and documentation in ZIP or TAR.GZ format: </p>
+
+ <ul>
+ <li><a href="dist/slf4j-1.3.0.tar.gz"><b>slf4j-1.3.0.tar.gz</b></a> </li>
+ <li><a href="dist/slf4j-1.3.0.zip"><b>slf4j-1.3.0.zip</b></a> </li>
+
+ </ul>
+
+
+ <h2>Previous versions</h2>
+
+ <p>Previous versions of SLF4J can be downloaded from the <A
+ href="dist/">main repository</A>.
+ </p>
+
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/faq.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/faq.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,849 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J FAQ</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+ <div class="section">
+
+ <h2><a name="top">Frequently Asked Questions about SLF4J</a></h2><p><b>Generalities</b></p>
+
+ <ol type="1">
+ <li><a href="#what_is">What is SLF4J?</a></li>
+
+ <li><a href="#when">When should SLF4J be used?</a></li>
+
+ <li><a href="#yet_another_facade"> Is SLF4J yet another loggingfacade?</a></li>
+
+ <li><a href="#why_new_project"> If SLF4J fixes JCL, then why
+ wasn't the fix made in JCL instead of creating a new project?
+ </a></li>
+
+ <li><a href="#need_to_recompile"> When using SLF4J, do I have to
+ recompile my application to switch to a different logging
+ system? </a></li>
+
+ <li><a href="#requirements">What are SLF4J's requirements?</a></li>
+
+
+ <li><a href="#license">Why is SLF4J licensed under X11 type
+ license instead of the Apache Software License? </a></li>
+
+ <li><a href="#where_is_binding">Where can I get a particular
+ SLF4J binding? </a></li>
+
+ <li><a href="#configure_logging">Should my library attempt to
+ configure logging?
+ </a>
+ </li>
+
+ <li><a href="#maven2">What about Maven 2 transitive
+ dependencies?
+ </a>
+ </li>
+ </ol>
+
+
+ <b>About the SLF4J API</b>
+
+ <ol type="1">
+
+ <li><a href="#string_or_object"> Why don't the printing methods
+ in the Logger interface accept message of type Object, but only
+ messages of type String? </a></li>
+
+ <li><a href="#exception_message">
+ Can I log an exception without an accompanying message?
+ </a></li>
+
+
+ <li><a href="#logging_performance"> What is the fastest way of
+ (not) logging? </a></li>
+
+ <li><a href="#string_contents"> How can I log the string
+ contents of a single (possibly complex) object? </a></li>
+
+
+ <li><a href="#fatal"> Why doesn't the
+ <code>org.slf4j.Logger</code> interface have methods for the
+ FATAL level? </a></li>
+
+ <li><a href="#trace"> Why doesn't the
+ <code>org.slf4j.Logger</code> interface have methods for the
+ TRACE level? </a></li></ol>
+
+
+ <b>Implementing the SLF4J API</b>
+
+ <ol type="1">
+
+ <li><a href="#slf4j_compatible"> How do I make my logging
+ framework SLF4J compatible? </a></li>
+
+ <li><a href="#marker_interface"> How can my logging system add
+ support for the <code>Marker</code> interface? </a></li>
+
+ </ol>
+
+
+ <b>General questions about logging</b>
+
+
+ <ol type="1">
+
+ <li><a href="#declared_static"> Should Logger members of a class
+ be declared as static? </a></li>
+
+ </ol>
+
+ </div>
+
+
+ <div class="section">
+
+ <h2>Generalities</h2>
+
+ <dl>
+ <dt><a name="what_is">What is SLF4J?</a></dt>
+ <dd>
+ <p>SLF4J is a simple facade for logging systems allowing the
+ end-user to plug-in the desired logging system at deployment
+ time.
+ </p>
+
+
+ <table border="0">
+ <tr><td align="right"><a href="#top">[top]</a></td></tr>
+ </table>
+ <hr />
+ </dd>
+
+ <dt><a name="when">
+ When should SLF4J be used?
+ </a></dt>
+
+ <dd>
+ <p>In short, libraries and other embedded components should
+ consider SLF4J for their logging needs because libraries
+ cannot afford to impose their choice of logging system on the
+ end-user. On the other hand, it does not necessarily make
+ sense for stand-alone applications to use SLF4J. Stand-alone
+ applications can invoke the logging system of their choice
+ directly.
+ </p>
+
+ <p>SLF4J is only a facade, meaning that it does not provide a
+ complete logging solution. Operations such as configuring
+ appenders or setting logging levels cannot be performed with
+ SLF4J. Thus, at same point in time, any non-trivial
+ application will need to directly invoke the underlying
+ logging system. In other words, complete independence from the
+ API underlying logging system is not possible for a
+ stand-alone application. Nevertheless, SLF4J reduces the
+ impact of this dependence to near-painless levels.
+ </p>
+
+ <p>Suppose that your CRM application uses log4j for its
+ logging. However, one of your important clients request that
+ logging be performed through JDK 1.4 logging. If your
+ application is riddled with thousands of direct log4j calls,
+ migration to JDK 1.4 would be a long and error-prone
+ process. Had you been invoking SLF4J API instead of log4j, the
+ migration could be completed in a matter of minutes instead of
+ hours.
+ </p>
+
+ <p>SLF4J lets component developers to defer the choice of the
+ logging system to the end-user but eventually a choice needs
+ to be made.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr>
+ </table><hr />
+
+ </dd>
+
+ <dt>
+ <a name="yet_another_facade">
+ Is SLF4J yet another logging facade? </a></dt>
+
+ <dd>
+ <p>SLF4J is conceptually similar to JCL. As such, it can be
+ thought of as yet another logging facade. However, SLF4J is
+ orders of magnitude simpler in design and arguably more
+ robust.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr />
+
+ </dd>
+ <dt>
+ <a name="why_new_project">
+ If SLF4J fixes JCL, then why wasn't the fix made in JCL
+ instead of creating a new project?
+ </a>
+ </dt>
+
+ <dd>
+ <p>This is a very good question. First, SLF4J static binding
+ approach is very simple, perhaps even laughably so. It was
+ not easy to convince developers of the validity of the
+ approach. It is only after SLF4J was released and started to
+ become accepted did the approach gain respectability in the
+ relevant community.
+ </p>
+
+ <p>Second, SLF4J offers two enhancements which developers
+ currently tend to underestimate. Parameterized log messages
+ solve an important problem associated with logging performance
+ in a pragmatic way. Marker objects, which are supported by the
+ <code>org.slf4j.Logger</code> interface, pave the way for
+ adoption of advanced logging systems and still leave the door
+ open to switching back to more traditional logging systems if
+ need be.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr /></dd>
+
+ <dt><a name="need_to_recompile">
+ When using SLF4J, do I have to recompile my application
+ to switch to a different logging system?
+ </a></dt>
+
+ <dd>
+ No, you do not need to recompile your application. You can
+ switch to a different logging system by removing the previous
+ SLF4J binding and replacing it with the binding of your choice.
+
+ <p>For example, if you were using the NOP implementation and
+ would like to switch to log4j version 1.2, simply replace
+ <em>slf4j-nop.jar</em> with <em>slf4j-log4j12.jar</em> on your
+ class path but do not forget to add log4j-1.2.x.jar as
+ well. Want to switch to JDK 1.4 logging? Just replace
+ <em>slf4j-log4j12.jar</em> with <em>slf4j-jdk14.jar</em>.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr>
+ </table><hr />
+ </dd>
+ <dt>
+ <a name="requirements">What are SLF4J's requirements?</a>
+ </dt>
+
+ <dd>
+
+ <p>In principle, SLF4J requires JDK 1.3 or above. However, if
+ the underlying logging system might have a higher
+ requirement. For instance, the <em>slf4j-jdk14</em> binding
+ requires JDK 1.4. Logback requires JDK 1.5, unless you
+ are using the 1.4 retro-translated jars.
+ </p>
+
+ <p> </p>
+
+ <table border="1">
+ <tr align="left">
+ <th>Binding</th>
+ <th>Requirements</th>
+ </tr>
+
+ <tr>
+ <td>slf4j-nop</td>
+ <td>JDK 1.3</td>
+ </tr>
+ <tr>
+ <td>slf4j-simple</td>
+ <td>JDK 1.3</td>
+ </tr>
+
+ <tr>
+ <td>slf4j-log4j12</td>
+ <td align="left">JDK 1.3, plus any other library
+ dependencies required by the log4j appenders in use</td>
+ </tr>
+ <tr>
+ <td>slf4j-jdk14</td>
+ <td>JDK 1.4 or above</td>
+ </tr>
+ <tr>
+ <td>logback-classic</td>
+ <td>JDK 1.5 or above, unless you are using the 1.4
+ retro-translated jars, plus any other library
+ dependencies required by the logback appenders in
+ use</td>
+ </tr>
+
+ </table>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr>
+ </table><hr />
+ </dd>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr>
+ </table><hr />
+ </dd>
+ <dt>
+ <a name="license">
+ Why is SLF4J licensed under X11 type license instead of the
+ Apache Software License?
+ </a>
+ </dt>
+
+ <dd>
+ <p>SLF4J is licensed under a permissive X11 type license
+ instead of the <a
+ href="http://www.apache.org/licenses/">ASL</a> or the <a
+ href="http://www.gnu.org/copyleft/lesser.html">LGPL</a>
+ because the X11 license is deemed by both the Apache Software
+ Foundation as well as the Free Software Foundation as
+ compatible with their respective licenses.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr>
+ </table><hr />
+ </dd>
+ <dt>
+ <a name="where_is_binding">
+ Where can I get a particular SLF4J binding?
+ </a>
+ </dt>
+
+ <dd>
+
+ <p>SLF4J bindings for <a
+ href="api/org/slf4j/impl/SimpleLogger.html">SimpleLogger</a>,
+ <a href="api/org/slf4j/impl/NOPLogger.html">NOPLogger</a>, <a
+ href="api/org/slf4j/impl/Log4jLoggerAdapter.html">LoggerLoggerAdapter</a>
+ and <a
+ href="api/org/slf4j/impl/JDK14LoggerAdapter.html">JDK14LoggerAdapter</a>
+ are contained within the files <em>slf4j-nop.jar</em>,
+ <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 bindings depend on <em>slf4j-api.jar</em>.
+ </p>
+
+ <p>The binding for logback-classic ships with the <a
+ href="http://logback.qos.ch/download.html">logback
+ distribution</a>. However, as with all other bindings, the
+ logback-classic binding requires <em>slf4j-api.jar</em>.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr />
+ </dd>
+
+ <dt><a name="configure_logging"> Should my library attempt to
+ configure logging? </a>
+ </dt>
+
+ <dd>
+ <p>Embedded components such as libraries do not need and
+ should not configure the logging system. They invoke SLF4J to
+ log but should let the end-user configure the logging
+ environment. When embedded components try to configure logging
+ on their own, they often override the end-user's wishes. At
+ the end of the day, it is the end-user who has to read the
+ logs and process them. She should be the person to decide how
+ she wants her logging configured.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr>
+ </table>
+ </dd>
+
+ <dt><a name="maven2">What about Maven2 transitive
+ dependencies? </a>
+ </dt>
+
+ <dd>
+ <p>As an author of a library built with Maven2, you might
+ want to test your application using a binding, say
+ slf4j-log4j12 or logback-classic, without forcing log4j or
+ logback-classic as a dependency upon your users. As of SLF4J
+ version 1.3, this quite easy to accomplish. But first, since
+ your library's code depends on the SLF4J API you will need to
+ declare slf4j-api as a compile-time (default scope)
+ dependency.
+ </p>
+ <p> </p>
+ <p class="source"><dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-api</artifactId>
+ <version>1.3.0</version>
+</dependency></p>
+
+ <p> </p>
+
+ <p>Limiting the transitivity of the SLF4J binding used in your
+ tests can be accomplished by declaring the scope of the
+ SLF4J-binding dependency as "test". Here is an example:</p>
+
+ <p> </p>
+
+ <p class="source"><dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-log4j12</artifactId>
+ <version>1.3.0</version>
+ <b><scope>test</scope></b>
+</dependency></p>
+
+ <p>Thus, as far as your users are concerned you are exporting
+ slf4j-api as a transitive dependency of your library, but not
+ any SLF4J-binding or an underlying logging system.
+ </p>
+
+ </dd>
+
+ </dl>
+ </div>
+
+ <div class="section">
+
+
+ <h2>About the SLF4J API</h2>
+
+ <dl>
+
+ <dt><a name="string_or_object"> Why don't the printing methods
+ in the Logger interface accept message of type Object, but only
+ messages of type String? </a>
+ </dt>
+
+ <dd>
+
+ <p>In SLF4J 1.0beta4, the printing methods such as debug(),
+ info(), warn(), error() in the <a
+ href="api/org/slf4j/Logger.html">Logger interface</a> were
+ modified so as to accept only messages of type String instead
+ of Object.
+ </p>
+
+ <p>Thus, the set of printing methods for the DEBUG level
+ became:</p>
+
+ <p class="source">debug(String msg);
+debug(String format, Object arg);
+debug(String format, Object arg1, Object arg2);
+debug(String msg, Throwable t);</p>
+
+ <p>Previously, the first argument in the above methods was of
+ type <code>Object</code>.</p>
+
+ <p>This change enforces the notion that logging systems are
+ about decorating and handling messages of type String, and not
+ any arbitrary type (Object).
+ </p>
+
+ <p>Just as importantly, the new set of method signatures offer
+ a clearer differentiation between the overladed methods
+ whereas previously the choice of the invoked method due to
+ Java overloding rules were not always easy to follow.</p>
+
+ <p>It was also easy to make mistakes. For example, previously
+ it was legal to write:</p>
+
+ <p class="source">logger.debug(new Exception("some error"));</p>
+
+ <p>Unfortunately, the above call did not print the stack trace
+ of the exception. Thus, a potentially crucial piece of
+ information could be lost. When the first parameter is
+ restricted to be of type String, then only the method
+ </p>
+ <p class="source">debug(String msg, Throwable t)</p>
+
+ <p>can be used to log exceptions. Note that this method
+ ensures that every logged exception is accompanied with a
+ descriptive message.</p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr />
+ </dd>
+
+ <dt>
+
+ <a name="exception_message">
+ Can I log an exception without an accompanying message?
+ </a>
+ </dt>
+ <dd>
+ <p>In short, no.</p>
+
+ <p>If <code>e</code> is an <code>Exception</code>, and you
+ would like to log an exception at the ERROR level, you must
+ add an accompanying message. For example,</p>
+
+ <p class="source">logger.error("some accompanying message", e);</p>
+
+ <p>You might correctly observe that not all exceptions have a
+ meaningful message to accompany them. Moreover, a good
+ exception should already contain a self explanatory
+ description. The accompanying message may therefore be
+ considered redundant.
+ </p>
+
+
+ <p>While these are valid arguments, there are three opposing
+ arguments also worth considering. First, on many, albeit not
+ all occasions, the accompanying message can convey useful
+ information nicely complementing the description contained in
+ the exception. Frequently, at the point where the exception is
+ logged, the developer has access to more contextual
+ information than at the point where the exception is
+ thrown. Second, it is not difficult to imagine more or less
+ generic messages, e.g. "Exception caught", "Exception
+ follows", that can be used as the first argument for
+ <code>error(String msg, Throwable t)</code> invocations.
+ Third, most log output formats display the message on a line,
+ followed by the exception on a separate line. Thus, the
+ message line would look inconsistent without a message.
+ </p>
+
+ <p>In short, if the user were allowed to log an exception
+ without an accompanying message, it would be the job of the
+ logging system to invent a message. This is actually what the
+ <a href="http://tinyurl.com/cr9kg">throwing(String
+ sourceClass, String sourceMethod, Throwable thrown)</a> method
+ in java.util.logging package does. (It decides on its own that
+ accompanying message is the string "THROW".)
+ </p>
+
+ <p>It may initially appear strange to require an accompanying
+ message to log an exception. Nevertheless, this is common
+ practice in <em>all</em> log4j derived systems such as
+ java.util.logging, logkit, etc. and of course log4j itself. It
+ seems that the current consensus considers requiring an
+ accompanying message as a good a thing (TM).
+ </p>
+
+ <table border="0">
+
+ <tr>
+ <td align="right">
+ <a href="#top">[top]</a></td></tr></table><hr />
+ </dd>
+
+ <dt><a name="logging_performance"> What is the fastest way of
+ (not) logging?</a></dt><dd>
+
+ <p> For some Logger <code>logger</code>, writing,</p>
+ <p class="source">logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));</p>
+
+ <p>incurs the cost of constructing the message parameter, that
+ is converting both integer <code>i</code> and
+ <code>entry[i]</code> to a String, and concatenating
+ intermediate strings. This, regardless of whether the message
+ will be logged or not.
+ </p>
+
+ <p>One possible way to avoid the cost of parameter
+ construction is by surrounding the log statement with a
+ test. Here is an example.</p>
+
+ <p class="source">if(logger.isDebugEnabled()) {
+ logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
+}</p>
+
+
+ <p>This way you will not incur the cost of parameter
+ construction if debugging is disabled for
+ <code>logger</code>. On the other hand, if the logger is
+ enabled for the DEBUG level, you will incur the cost of
+ evaluating whether the logger is enabled or not, twice: once in
+ <code>debugEnabled</code> and once in <code>debug</code>. This
+ is an insignificant overhead because evaluating a logger takes
+ less than 1% of the time it takes to actually log a statement.
+ </p>
+
+
+
+ <p><b>Better alternative based on format messages</b></p>
+
+ <p>There exists a very convenient alternative based on message
+ formats. Assuming <code>entry</code> is an object, you can write:
+ </p>
+
+
+ <p class="source">Object entry = new SomeObject();
+logger.debug("The entry is {}.", entry);</p>
+
+ <p>After evaluting whether to log or not, and only if the
+ decision is affirmative, will the logger implementation format
+ the message and replace the '{}' pair with the string value of
+ <code>entry</code>. In other words, tis form does not incur
+ the cost of parameter construction in case the log statement
+ is disabled.
+ </p>
+
+ <p>The following two lines will yield the exact same
+ output. However, the second form will outperform the first
+ form by a factor of at least 30, in case of a
+ <em>disabled</em> logging statement.
+ </p>
+
+ <p class="source">logger.debug("The new entry is "+entry+".");
+logger.debug("The new entry is {}.", entry);</p>
+
+
+ <p>A two argument variant is also availalble. For example, you can
+ write:</p>
+
+ <p class="source">logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);</p>
+
+ <p>If three or more arguments need to be passed, an
+ <code>Object[]</code> variant is also availalble. For example,
+ you can write:</p>
+
+ <p class="source">logger.debug("Value {} was inserted between {} and {}.",
+ new Object[] {newVal, below, above});</p>
+
+
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr /></dd><dt><a name="string_contents">
+ How can I log the string contents of a single (possibly
+ complex) object?
+ </a></dt><dd>
+ <p>
+ In relatively rare cases where the message to be logged is the
+ string form of an object, then the parameterized printing
+ method of the appropriate level can be used. Assuming
+ <code>complexObject</code> is an object of certain complexity,
+ for a log statement of level DEBUG, you can write:
+ </p>
+
+ <p class="source">logger.debug("{}", complexObject);</p>
+
+
+ <p>The logging system will invoke
+ <code>complexObject.toString()</code> method only after it has
+ ascertained that the log statement was enabled. Otherwise, the
+ cost of <code>complexObject.toString()</code> conversion will
+ be advantageously avoided.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr /></dd><dt><a name="fatal">
+ Why doesn't the <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>
+
+
+ <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>
+
+ <p>Assuming the ERROR level designates exceptional situations
+ meriting close attention, we are inclined to believe that the
+ FATAL level is superfluous.
+ </p>
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr /></dd><dt><a name="trace">
+ Why doesn't the <code>org.slf4j.Logger</code> interface
+ have methods for the TRACE level?
+ </a></dt><dd>
+
+ <p>The addition of the TRACE level has been frequently and
+ hotly debated request. By studying various projects, it looks
+ like the TRACE level is mostly used to disable logging output
+ from certain classes without needing to configure logging for
+ those classes. Indeed, the TRACE level is by default disabled
+ in log4j and other logging systems. We believe that the same
+ result could be achieved by adding the appropriate directives
+ in configuration files.
+ </p>
+
+ <p>Thus, in the majority of cases the TRACE level has the same
+ semantic meaning as DEBUG. In such case, the TRACE level
+ merely saves a few configuration directives. In the rare but
+ interesting cases where TRACE has a different meaning than
+ DEBUG, <a href="api/org/slf4j/Marker.html">Marker</a> objects
+ can be put to use to convey the desired new meaning.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table>
+
+ </dd>
+ </dl>
+ </div>
+
+
+ <div class="section">
+
+ <h2>Implementing the SLF4J API</h2><dl><dt><a name="slf4j_compatible">
+ How do I make my logging framework SLF4J
+ compatible?
+ </a>
+ </dt>
+ <dd>
+
+ <p>Adding supporting for the SLF4J is suprisingly
+ easy. Essentialy, you coping an existing binding and tailoring
+ it a little (as explained below) does the trick.
+ </p>
+
+ <p>If you are a Maven2 user, you can use the
+ slf4j-archetype. Invoke the following command to create a new
+ module called <em>slf4j-MY</em> with much of the plumbing
+ alredy in place.</p>
+
+ <p class="source">mvn archetype:create -DgroupId=org.slf4j -DartifactId=slf4j-MY \
+ -DarchetypeGroupId=org.slf4j -DarchetypeArtifactId=slf4j-archetype -DarchetypeVersion=1.1.0</p>
+
+ <p>At this stage, assuming your logging system has notion of a
+ logger, called say <code>MyLogger</code>, you need to provide
+ an adapter for <code>MyLogger</code> to
+ <code>org.slf4j.Logger</code> interface. Refer to slf4j-jcl,
+ slf4j-jdk14, and slf4j-log4j12 modules for examples of
+ adapters.
+ </p>
+
+ <p>Once you have written an appropriate adapter, say
+ <code>MyLoggerAdapter</code>, you need to provide a factory
+ class implementing the <code>org.slf4j.ILoggerFactory</code>
+ interface. This factory should return instances
+ <code>MyLoggerAdapter</code>. Let <code>MyLoggerFactory</code>
+ be the name of your factory class.
+ </p>
+
+ <p>Once you have the adapter, namely
+ <code>MyLoggerAdapter</code>, and a factory, namely
+ <code>MyLoggerFactory</code>, the last remaining step is to
+ modify the <code>StaticLoggerBinder</code> class so that it
+ reurns an new instance of <code>MyLoggerFactory</code>. You
+ will also need to modify the
+ <code>loggerFactoryClassStr</code> variable.
+ </p>
+
+ <p>That's it. You don't need to modify any other files.</p>
+
+ <p>In summary, to create an SLF4J binding for your logging
+ system, follow these steps:</p>
+
+ <ol>
+ <li>start with a copy of an existing module, or create a new
+ binding using slf4j-archetype as discussed above</li>
+ <li>create an adapter between your logging system and
+ <code>org.slf4j.Logger</code> interface
+ </li>
+ <li>create a factory for the adapter created in the previous step,</li>
+ <li>>modify <code>StaticLoggerBinder</code> class to use the
+ factory you created in the previous step</li>
+ </ol>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table><hr /></dd><dt><a name="marker_interface">
+ How can my logging system add support for
+ the <code>Marker</code> interface?
+ </a></dt><dd>
+ <p>Markers consitute a revolutionary concept which is
+ supported by LOGBack but not other existing logging
+ systems. Consequently, SLF4J confromant logging systems are
+ allowed to ignore marker data passed by the user.
+ </p>
+
+ <p>However, even though marker data may be ignored, the user
+ must still be allowed to specify marker data. Otherwise, users
+ would not be able to switch between logging systems that
+ support markers and those that do not. In order to provide
+ minimal support for markers, SLF4J conformant systems need to
+ to include certain Marker related classes, namely,
+ <code>org.slf4j.Marker</code>,
+ <code>org.slf4j.IMarkerFactory</code>,
+ <code>org.slf4j.MarkerFactory</code>,
+ <code>org.slf4j.impl.BasicMarker</code>,
+ <code>org.slf4j.impl.BasicMarkerFactory</code>,
+ <code>org.slf4j.impl.MarkerIgnoringBase</code>,
+ <code>org.slf4j.impl.StaticMarkerBinder</code> and
+ <code>org.slf4j.spi.MarkerFactoryBinder</code>. Al of these
+ classes are availalbe in the SLF4J subversion repository.
+ </p>
+
+ <p>The <code>MarkerIgnoringBase</code> class can serve as a
+ base for adapters or native implementations of logging systems
+ lacking marker support. In <code>MarkerIgnoringBase</code>,
+ methods taking marker data simply invoke the corresponding
+ method without the Marker argument, discarding any Marker data
+ passed as argument. Your SLF4J adapters can extend
+ <code>MarkerIgnoringBase</code> to quickly implement the
+ methods in <code>org.slf4j.Logger</code> which take a
+ <code>Marker</code> as the first argument.
+ </p>
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table></dd></dl></div><div class="section"><h2>General questions about logging</h2><dl><dt><a name="declared_static">
+ Should Logger members of a class be declared as static?
+ </a></dt><dd>
+
+ <p>This author recommends that loggers members be declared
+ as instance variables instead of static.
+ </p>
+
+ <p>Static logger members cost a single variable reference for
+ all instances of the class whereas an instance logger member
+ will cost a variable reference for every instance of the
+ class. For simple classes instantiated thousands of times
+ there might be a noticeable difference.
+ </p>
+
+ <p>However, more recent logging systems, e.g log4j or logback,
+ support a distinct logger context for each application running
+ in the application server. Thus, even if a single copy of
+ <em>log4j.jar</em> or <em>logback-classic.jar</em> is deployed
+ in the server, the logging system will be able to
+ differentiate between applications and offer a distinct
+ logging environment for each application.
+ </p>
+
+ <p>More specifically, each time a logger is retrieved by
+ invoking <code>LoggerFactory.getLogger()</code> method, the
+ underlying logging system will return an instance appropriate
+ for the current application. Please note that within the
+ <em>same</em> application retrieving a logger by a given name
+ will always return the same logger. For a given name, a
+ different logger will be returned only for different
+ applications.
+ </p>
+
+ <p>If the logger is static, then it will only be retrieved
+ once when the hosting class is loaded into memory. If the
+ hosting class is used in only in one application, there is not
+ much to be concerned about. However, if the hosting class is
+ shared between several applications, then all instances of the
+ shared class will log into the context of the application
+ which happened to fist load the shared class into memory -
+ hardly the behavior expected by the user.
+ </p>
+
+ <p>In summary, except for classes with few members
+ <em>and</em> instantiated very frequently, logger members
+ should be instance variables.
+ </p>
+
+
+ <table border="0"><tr><td align="right"><a href="#top">[top]</a></td></tr></table></dd></dl></div>
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/inde_base.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/inde_base.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,28 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+
+
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/index.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/index.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,95 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+
+ <h1>Simple Logging Facade for Java (SLF4J)</h1>
+
+ <p>The Simple Logging Facade for Java or (SLF4J) is intended to
+ serve as a simple facade for various logging APIs allowing to the
+ end-user to plug in the desired implementation at
+ <em>deployment</em> time. SLF4J also allows for a <a
+ href="manual.html#gradual">gradual migration path</a> away from
+ Jakarta Commons Logging (JCL).
+ </p>
+
+ <p>Logging API implementations can either choose to implement the
+ the SLF4J interfaces directly, e.g. <a
+ href="http://logback.qos.ch">logback</a> or <a
+ href="api/org/slf4j/impl/SimpleLogger.html">SimpleLogger</a>. Alternatively,
+ it is possible (and rather easy) to write SLF4J adapters for the
+ given API implementation, e.g. <a
+ href="api/org/slf4j/impl/Log4jLoggerAdapter.html">Log4jLoggerAdapter</a>
+ or <a
+ href="api/org/slf4j/impl/JDK14LoggerAdapter.html">JDK14LoggerAdapter</a>..
+ </p>
+
+ <h2>Simplicity</h2>
+
+ <p>The SLF4J interfaces and their various adapters are simple and
+ straightforward. Most developers familiar with the Java language
+ should be able to read and fully understand the code in less than
+ one hour.
+ </p>
+
+ <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, 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
+ model will make it easy for developers of other logging APIs to
+ conform to the SLF4J model.
+ </p>
+
+ <h3>Projects depending on SLF4j</h3>
+
+ <p>Here is a non-exhaustive list of projects currently depending on
+ SLF4J, in alphabetical order:
+ </p>
+
+ <ul>
+ <li><a href="http://directory.apache.org/">Apache Directory</a></li>
+ <li><a href="http://incubator.apache.org/graffito/">Apache Graffito</a></li>
+ <li><a href=" http://jackrabbit.apache.org/">Apache Jackrabbit</a></li>
+ <li><a href="http://mina.apache.org/">Apache Mina</a></li>
+ <li><a href="http://incubator.apache.org/wicket/">Apache Wicket 2.0</a></li>
+ <li><a href="http://apogee.nuxeo.org/">Apogee</a></li>
+ <li><a href="http://ha-jdbc.sourceforge.net/">HA-JDBC: High-Availability JDBC</a></li>
+ <li><a href="http://jetty.mortbay.org/">Jetty v6</a></li>
+ <li><a href="http://www.liferay.com/web/guest/home">LIFERAY</a></li>
+ <li><a href="http://www.unidata.ucar.edu/software/netcdf-java/">NetCDF</a></li>
+ <li><a href="http://proximity.abstracthorizon.org/index.html">Proximity</a></li>
+ <li><a href="http://www.quickfixj.org/">QuickFIX/J</a></li>
+ <li><a href="http://smsj.sourceforge.net/dependencies.html">SMSJ</a></li>
+ <li><a href="http://www.springframework.org/osgi">Spring-OSGi</a></li>
+ </ul>
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/license.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/license.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,70 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J License</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+
+ <h1>SLF4J License</h1>
+
+ <p>SLF4J source code and binaries are distributed under the
+ following license.
+ </p>
+
+ <div class="source">
+ Copyright (c) 2004-2007 QOS.ch
+ All rights reserved.
+
+ Permission is hereby granted, free of charge, to any person obtaining
+ a copy of this software and associated documentation files (the
+ "Software"), to deal in the Software without restriction, including
+ without limitation the rights to use, copy, modify, merge, publish,
+ distribute, sublicense, and/or sell copies of the Software, and to
+ permit persons to whom the Software is furnished to do so, subject to
+ the following conditions:
+
+ The above copyright notice and this permission notice shall be
+ included in all copies or substantial portions of the Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ </div>
+
+ <p>These terms are <em>identical</em> to those of the <a
+ href="http://en.wikipedia.org/wiki/MIT_License">MIT License</a>,
+ also called the X License or the X11 License, X11 License, which is
+ a simple, permissive non-copyleft free software license. It is
+ deemed compatible with virtually all types of licenses, commercial
+ or otherwise. In particular, the Free Software Foundation has
+ declared it compatible with
+ <a href="http://www.fsf.org/licensing/licenses/license-list.html#GPLCompatibleLicenses">
+ GNU GPL</a>. It is also known to be approved by the Apache Software
+ Foundation as compatible with <a
+ href="http://www.apache.org/licenses/">Apache Software License</a>.
+ </p>
+
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/mailing-lists.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/mailing-lists.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,131 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+ <h1>SLF4J Mailing Lists</h1>
+
+ <p>A mailing list is an electronic discussion forum that anyone can
+ subscribe to. When someone sends an email message to the 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.
+ </p>
+
+ <h3>Respect the mailing list type</h3>
+
+ <p>The "User" lists where you can send questions and comments about
+ configuration, setup, usage and other "user" types of questions.
+ The "Developer" lists where you can send questions and comments
+ about the actual software source code and general "development"
+ types of questions.
+ </p>
+
+ <p>Some questions are appropriate for posting on both the "user" and
+ the "developer" lists. In this case, pick one and only one. Do not
+ cross post.
+ </p>
+
+ <p>Please do your best to ensure that you are not sending HTML or
+ "Stylelized" email to the list. If you are using Outlook or Outlook
+ Express or Eudora, chances are that you are sending HTML email by
+ default. There is usually a setting that will allow you to send
+ "Plain Text" email.
+ </p>
+
+<!--
+ <p>These lists are archived at
+
+ <ul>
+ <li><a href="http://logging.apache.org/mail/">Full mbox archives of all lists</a></li>
+ <li> <a href="http://nagoya.apache.org/eyebrowse/">Eyebrowse Archives</a></li>
+ <li>The Aims Group <a href="http://marc.theaimsgroup.com/">Archives</a></li>
+ </ul>
+ </p>
+-->
+
+
+
+ <h3>slf4j-announcements list</h3>
+
+ <p>
+ <b>Low Traffic:</b>
+ <a href="http://slf4j.org/mailman/listinfo/announce">Subscribe</a> |
+ <a href="http://slf4j.org/mailman/options/announce">Unsubscribe</a>
+ <br/>
+ <b>Archives:</b>
+ <a href="http://www.slf4j.org/pipermail/announce/">Pipermail</a> |
+ <a href="http://marc.theaimsgroup.com/?l=slf4j-announce">MARC</a>
+ </p>
+ <p>The announcements list is reserved for important SLF4J API
+ related announcements. As such, the traffic on this list is
+ guaranteed to be very low.
+ </p>
+
+ <p>Given that implementations are expected to statically bind with
+ the SLF4J API, we recommend that any implementor of the SLF4J API
+ be subscribed at least to the announcements list.
+ </p>
+
+ <h3>slf4j-user list</h3>
+
+ <p>
+ <b>Medium Traffic:</b>
+ <a href="http://slf4j.org/mailman/listinfo/user">Subscribe</a> |
+ <a href="http://slf4j.org/mailman/options/user">Unsubscribe</a>
+ <br/>
+ <b>Archives:</b>
+ <a href="http://www.slf4j.org/pipermail/user/">Pipermail</a> |
+ <a href="http://news.gmane.org/gmane.comp.java.slf4j.user">Gmane</a> |
+ <a href="http://marc.theaimsgroup.com/?l=slf4j-user">MARC</a>
+
+ </p>
+
+ <p>This is the list for users of slf4j. It is also a good forum for
+ asking questions about how slf4j works, and how it can be
+ used. SLF4J developers are usually subscribed to to this list in
+ order to offer support.</p>
+
+
+ <h3>slf4j-dev list</h3>
+
+ <p>
+ <b>Medium Traffic:</b>
+ <a href="http://slf4j.org/mailman/listinfo/dev">Subscribe</a> |
+ <a href="http://slf4j.org/mailman/options/dev">Unsubscribe</a>
+ <br/>
+ <b>Archives:</b>
+ <a href="http://www.slf4j.org/pipermail/dev/">Pipermail</a> |
+ <a href="http://news.gmane.org/gmane.comp.java.slf4j.devel">Gmane</a> |
+ <a href="http://marc.theaimsgroup.com/?l=slf4j-dev">MARC</a> |
+ <a href="http://www.mail-archive.com/dev%40slf4j.org/">MailArchive</a> </p>
+ <p> </p>
+
+ <h2>On IRC</h2>
+
+ <p>We can also be reached by IRC at <span
+ class="big"><code>irc.freenode.net#slf4j</code></span>. </p>
+
+ <p> </p>
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/manual.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/manual.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,278 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J Manual</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+
+ <h1>SLF4J User manual</h1>
+
+ <p>The Simple Logging Facade for Java or (SLF4J) is intended to
+ serve as a simple facade for various logging APIs allowing to plug
+ in the desired implementation at deployment time.
+ </p>
+
+ <h2>Typical usage pattern</h2>
+
+ <pre class="source">
+ 1: <b>import org.slf4j.Logger;</b>
+ 2: <b>import org.slf4j.LoggerFactory;</b>
+ 3:
+ 4: public class Wombat {
+ 5:
+ 6: <b>final Logger logger = LoggerFactory.getLogger(Wombat.class);</b>
+ 7: Integer t;
+ 8: Integer oldT;
+ 9:
+10: public void setTemperature(Integer temparature) {
+11:
+12: oldT = t;
+13: t = temperature;
+14:
+15: <b>logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);</b>
+16:
+17: if(temperature.intValue() > 50) {
+18: <b>logger.info("Temperature has risen above 50 degrees.");</b>
+19: }
+20: }
+21: }
+ </pre>
+
+ <p>The example above illustrates the typical usage pattern for
+ SLF4j. Note the use of formatted log messages on line 15. See
+ the question <a href="faq.html#2.3">"What is the fastest way of
+ logging?"</a> in the FAQ for more details.
+ </p>
+
+ <h2>Swapping implementations at deployment time</h2>
+
+ <p>SLF4J supports multiple logging systems, namely, NOP,
+ Simple, log4j version 1.2, JDK 1.4 logging,
+ JCL and logback. The SLF4J distribution ships with several jar
+ files <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
+ <em>slf4j-log4j12.jar</em>, <em>slf4j-log4j13.jar</em>,
+ <em>slf4j-jdk14.jar</em> and <em>slf4j-jcl.jar</em>. Each of
+ these jar files is hardwired <em>at compile-time</em> to use
+ just one implementation, that is NOP, Simple, log4j version
+ 1.2, JDK 1.4 logging, and repectively
+ JCL. <span style="color:#D22">As of SLF4J version 1.1.0, all of the
+ bindings shipped with SLF4J depend on <em>slf4j-api.jar</em>
+ which must be present on the class path for the binding to
+ function properly.</span> </p>
+
+ <h2>Small applications</h2>
+
+ <p>Small applications where configuring a fully-fledged
+ logging systems can be somewhat of an overkill, can drop in
+ <em> <em>slf4j-api.jar+</em>slf4j-simple.jar</em> instead of a binding for a
+ fully-fledged logging system. </p>
+
+ <h2>Libraries</h2>
+
+ <p>Authors of widely-distributed components and libraries may
+ code against the SLF4J interface in order to avoid imposing an
+ logging system on the end-user. At deployment
+ time, the end-user may choose the desired logging system by inserting the corresponding jar file in her
+ classpath. This stupid, simple and robust approach avoids many
+ of the painful bugs associated with dynamic discovery
+ processes.
+ </p>
+
+ <h2>Simplicity</h2>
+
+ <p>The SLF4J interfaces and their various adapters are
+ extremely simple. Most developers familiar with the Java
+ language should be able to read and fully understand the code
+ in less than one hour.
+ </p>
+
+ <p>As noted earlier, SLF4J does not rely on any special class
+ loader machinery. Every variant of
+ <em>slf4j-<impl>.jar</em> is statically hardwired <em>at
+ compile time</em> to use one and only specific
+ implementation. Thus, SLF4J suffers from none of the <a
+ href="http://www.qos.ch/logging/classloader.jsp">class loader
+ problems observed when using JCL</a>.</p>
+
+ <p>Hopefully, the simplicity of the SLF4J interfaces and the
+ deployment model will make it easy for developers of other
+ logging APIs to conform to the SLF4J model.
+ </p>
+
+ <h2>Built-in support in logback</h2>
+
+ <p>The <code>ch.qos.logback.classic.Logger</code> class in logback directly
+ implements SLF4J's <code>org.slf4j.Logger</code> interface. Moreover,
+ logback makes extensive use of SLF4J internally.
+ </p>
+
+ <p>Logback's built-in (a.k.a. native) support for SLF4J means
+ that the adapter for does not need to wrap logback objects in
+ order to make them conform to SLF4J's <code>Logger</code>
+ interface. A logback
+ <code>ch.qos.logback.classic.Logger</code> <em>is</em> a
+ <code>org.slf4j.Logger</code>. Thus, using SLF4J in
+ conjunction with logback involves strictly zero memory and
+ computational overhead.
+ </p>
+
+
+ <a name="gradual"><h2>Gradual migration to SLF4J from Jakarta
+ Commons Logging (JCL)</h2></a>
+
+ <h2><em>jcl104-over-slf4j.jar</em></h2>
+
+ <p>To ease migration to SLF4J from JCL, recent SLF4J
+ distributions include the jar file
+ <em>jcl104-over-slf4j.jar</em>. This jar file is intended as a
+ drop-in replacement for JCL version 1.0.4. It implements the
+ public API of JCL but using SLF4J underneath, hence the name
+ "JCL over SLF4J."
+ </p>
+
+ <p>Our JCL over SLF4J implementation will allow you to migrate
+ to SLF4J gradually, especially if some of the libraries your
+ software depends on continue to use JCL for the foreseeable
+ future. You can immediately enjoy the benefits of SLF4J's
+ reliability and preserve backward compatibility at the same
+ time. Just replace <em>commons-logging.jar</em> with
+ <em>jcl104-over-slf4j.jar</em>. Subsequently, the selection of
+ the underlying logging system will be done by SLF4J instead of
+ JCL but without the class loader headaches. The underlying
+ logging system can be any of NOP, simple, jdk14 logging, log4j
+ or logback. Any existing dependency on commons-logging
+ therefore becomes less of an issue.
+ </p>
+
+ <h2><em>slf4j-jcl.jar</em></h2>
+
+ <p>Some of our users after having switched to SLF4J API
+ realize that in some contexts the use of JCL is mandatory and
+ their use of SLF4J can be a problem. For this uncommon but
+ important case, SLF4J offers a JCL binding, found in the file
+ <em>slf4j-jcl.jar</em>. The JCL binding will delegate all
+ logging calls made through SLF4J API to JCL. Thus, if for some
+ reason an existing application <em>must</em> use JCL, your
+ part of that application can still code against the SLF4J API
+ in a manner transparent to the larger application
+ environment. Your choice of SLF4J API will be invisible to the
+ rest of the application which can continue to use JCL.
+ </p>
+
+ <h2><em>jcl104-over-slf4j.jar</em> should not be confused with
+ <em>slf4j-jcl.jar</em></h2>
+
+
+ <p>JCL-over-SLF4J, i.e. <em>jcl104-over-slf4j.jar</em>, comes
+ in handy in situations where JCL needs to be supported for
+ backward compatibility reasons. It can be used to fix problems
+ associated with JCL, without necessarily adopting the SLF4J
+ API, a decision which can be deferred to a later time.
+ </p>
+
+ <p>On the other hand, <em>slf4j-jcl.jar</em> is useful <strong>after</strong> you have already adopted the SLF4J API for your component
+ which needs to be embedded in a larger application environment
+ where JCL is a formal requirement. Your software component can
+ still use SLF4J API without disrupting the larger
+ application. Indeed, <em>slf4j-jcl.jar</em> will delegate all
+ logging decisions to JCL so that the dependency on SLF4J API
+ by your component will be transparent to the larger whole. </p>
+
+ <p>Please note that <em>jcl104-over-slf4j.jar</em> and
+ <em>slf4j-jcl.jar</em> cannot be deployed at the same
+ time. The former jar file will cause JCL to delegate the
+ choice of the logging system to SLF4J and the latter jar file
+ will cause SLF4J to delegate the choice of the logging system
+ to JCL, resulting in an infinite loop.
+ </p>
+
+ <a name="summary"><h2>Summary</h2></a>
+
+ <table class="bodyTable" cellspacing="4" cellpadding="4">
+ <tr>
+ <th align="left">Advantage</th>
+ <th align="left">Description</th>
+ </tr>
+
+ <tr class="a">
+ <td>Swappable logging API implementations</td>
+ <td>The desired logging API can be plugged in at
+ deployment time by inserting the appropriate jar file on
+ your classpath.
+ </td>
+ </tr>
+
+
+ <tr class="b">
+ <td>Fail-fast operation</td>
+ <td>Assuming the appropriate jar file is available on the
+ classpath, under no circumstances will SLF4J cause your
+ application to fail. SLF4J's simple and robust design
+ ensures that SLF4J never causes exceptions to be thrown.
+
+ <p>Contrast this with
+ <code>LogConfigurationException</code> thrown by JCL which
+ will cause your otherwise functioning application to
+ fail. JCL-logging will throw a
+ <code>LogConfigurationException</code> in case the <a
+ href="http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/Log.html">Log</a>
+ interface and its dynamically discovered implementation
+ are loaded by different class loaders.
+ </p>
+ </td>
+ </tr>
+
+
+ <tr class="a">
+ <td>Adapter implementations for popular logging systems
+ </td>
+
+ <td>SLF4J supports popular logging systems, namely log4j,
+ JDK 1.4 logging, Simple logging and NOP whereas x4juli and
+ logback logging systems support the SLF4J API natively.
+ </td>
+
+ </tr>
+
+ <tr class="b">
+ <td>Easy migration path</td>
+
+ <td>
+ <p>The implementation of JCL over SLF4J, i.e
+ <em>jcl104-over-slf4j.jar</em>, will allow your project
+ to migrate to SLF4J piecemeal, without breaking
+ compatibility with existing software using
+ JCL.
+ </p>
+ </td>
+ </tr>
+
+ <tr class="a">
+ <td>Support for formated log messages</td>
+
+ <td>All SLF4J adapters support formated log messages with
+ significantly improved performace results.</td>
+ </tr>
+
+
+ </table>
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/news.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/news.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,591 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J News</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+
+ <h1>SLF4J News</h1>
+
+ <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>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>February 25th, 2007 - Release of SLF4J 1.3.0</h3>
+
+ <p>This release consists of rearrangement of classes among
+ 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. <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.</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>
+
+ <p>It is now possible to obtain the root logger of the underlying
+ logging implementation by requesting a logger named
+ "ROOT". This feature was requested by Sebastien Davids
+ in <a href="http://bugzilla.slf4j.org/show_bug.cgi?id=35">bug
+ report 35</a>. </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>January 24th, 2007 - Release of SLF4J 1.2</h3>
+ <p>This release includes several modifications to make SLF4J
+ an <a href="http://www.osgi.org/">OSGi</a>-friendly framework.
+ The modules' MANIFEST.MF files now include
+ OSGi metadata. Regarding these improvements, and OSGi in general, the
+ SLF4J project is happy to welcome John E. Conlon as a new committer.
+ </p>
+
+ <p>Marker objects are now Serializable.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>December 21st, 2006 - Release of SLF4J 1.1.0 (final)</h3>
+
+ <p>This release consists of minor bug fixes and documentation
+ changes. More importantly, the log4j-over-slf4j module has been
+ moved to the logback project, under the name <a
+ href="http://logback.qos.ch/bridge.html">log4j-bridge</a>.
+ </p>
+
+ <p>Added the file "org.apache.commons.logging.LogFactory" under
+ META-INF/services directory which went missing in the 1.1.0 series
+ of SLF4J. This fixes a compatibility problem with Apache Axis which
+ uses its own discovery mechanism, namely, commons-discovery version
+ 0.2. The problem was reported in bug <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=33">report 33</a>
+ by David Varnes.
+ </p>
+
+ <p>The file jcl104-over-slf4j.jar had various entries missing in its
+ MANIFEST.MF file, as reported by Boris Unkel in <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=30">bug number
+ 30</a>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>November 16th, 2006 - Release of SLF4J 1.1.0-RC1</h3>
+
+ <p>This release consists of packaging related bug fix in addition to
+ minor documentation changes.
+ </p>
+
+ <p>Contrary to RC0, RC1 no longer uses SNAPSHOT versions for the
+ slf4j-parent pom. The solution to <a
+ href="http://ceki.blogspot.com/2006/11/solution-to-maven2-version-number.html">Maven
+ version problem</a> does not work for public projects such as SLF4J
+ because SNAPHOTs are not allowed on ibiblio.
+ </p>
+
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>November 4th, 2006 - Release of SLF4J 1.1.0-RC0</h3>
+
+ <p>This release consists of bug fixes. Moreover, since the major
+ packaging related changes in 1.1.0-beta0 seem to work well, this
+ release is marked as RC0.</p>
+
+ <p>Fixed the JDK 1.5 dependency for the SLF4J build, as reported by
+ Boris Unkel in <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=28">bug number
+ 28</a>. SLF4J now explicitly declares a dependency on JDK 1.4 in its
+ pom.xml file.
+ </p>
+
+ <p>Fixed an incorrect reference to the logback project in slf4j-api
+ pom file. This bug was reported by Boris Unkel in <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=29">bug number
+ 29</a>.
+ </p>
+
+ <p>Fixed a syncroisation problem in factories of almost all SLF4J
+ bindings. This bug was reported independenly by Howard M. Lewis Ship
+ and Boris Unkel in bug reports <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=26">26</a> and
+ respectively <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=26">27</a>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>September 7th, 2006 - Release of SLF4J 1.1.0-beta0</h3>
+
+ <p>Release 1.1.0-beta0 is a relatively important release with a
+ refactoring of the way class files are organized in jar files. In
+ previous releases, each binding was self-contained in a single jar
+ file. In this release, each and every binding depends on
+ <em>slf4j-api.jar</em> which contains the bulk of the classes
+ required to use SLF4J, except for one or two adapter classes. Only
+ the adapter classes are now shipped with each specific binding jar
+ as appropriate for the underlying logging system..
+ </p>
+
+ <p>This release is built using Maven instead of Ant. As for the java
+ code, it has not been changed.</p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>June 8th, 2006 - Release of SLF4J 1.0.2</h3>
+
+ <p>Release 1.0.2 is a maintenance release containing bug fixes
+ only.</p>
+
+ <ul>
+
+ <li>Fixed <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=22">bug number
+ 22</a> reported by Bjorn Danielsson. This version of the SLF4J API
+ will no longer systematically throw an exception when the
+ <code>o.a.c.l.impl.SLF4FLogFactory#release()</code> method is
+ invoked. Instead, the <code>release()</code> method will issue a
+ <a href="http://www.slf4j.org/codes.html">warning</a>.
+
+ </li>
+
+ </ul>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>May 1st, 2006 - Release of SLF4J 1.0.1</h3>
+
+ <p>Release 1.0.1 is a maintenance release containing bug fixes only.
+
+ <ul>
+
+ <li>Fixed <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=20">bug number
+ 20</a> reported by Steve Bate. <code>JDK14LoggerAdapter</code>
+ will now correctly relay the logger name to the underlying JDK 14
+ logging system.
+ </li>
+
+ <li>Added the file "org.apache.commons.logging.LogFactory" under
+ META-INF/services directory in the jcl104-over-slf4j jar
+ file. This fixes a compatibility problem with Apache Axis which
+ uses its own discovery mechanism, namely, commons-discovery
+ version 0.2. The bug was reported by Dave Wallace.
+ </li>
+
+ </ul>
+ </p>
+
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>March 8th, 2006 - Release of SLF4J 1.0</h3>
+
+ <p>This is release labeled as 1.0 (final) contains few relatively
+ minor changes:
+ </p>
+
+ <ul>
+ <li>As <a
+ href="http://marc.theaimsgroup.com/?t=114063163800004">discussed</a>
+ on the slf4j user list, <code>SimpleLogger</code> now directs its
+ output to stderr instead of stdout.
+ </li>
+
+ <li>Modified <code>JDK14LoggerAdapter</code> so that caller
+ information is now correctly printed, as reported in <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=13">bug 13</a> by
+ Peter Royal.
+ </li>
+
+ <li>Minor additions to the Marker interface.</li>
+
+ </ul>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>February 4th, 2006 - Release of SLF4J 1.0-RC6 and NLOG4J
+ 1.2.22</h3>
+
+ <p>The <code>MarkingLogger</code> interface has been removed and its
+ contents merged into <code>org.slf4j.Logger</code>. This change
+ should not adversely affect end-users. However, SLF4J bindings need
+ to be updated. This has been done for all the bindings shipped with
+ SLF4J distribution as well as NLOG4J. As for x4juli, the update is
+ planned for its next release.
+ </p>
+
+ <p>The merge between the <code>MarkingLogger</code> and
+ <code>Logger</code> interfaces has been motivated by the need to
+ allow end-users to easily switch between logging systems that
+ support markers and those that do not.
+ </p>
+
+ <p>Added a default instance to SimpleLoggerFactory to serve as a
+ last resort fallback mechanism. This instance is designed to be used
+ by a very specific group of users, namely for those developing
+ logging systems (e.g. log4j or LOGBack). It is not intended for
+ end-users of the SLF4J API.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>January 9th, 2006 - Release of SLF4J 1.0-RC5 and NLOG4J
+ 1.2.21</h3>
+
+ <p>A maintenance release correcting bugs <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=11">#11</a> and <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=12">#12</a> and in
+ general improved resilience to null input parameters across
+ implementations. Many thanks to Boris Unckel and Kenneth for
+ reporting the null input issue.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>December 27th, 2005 - Release of SLF4J 1.0-RC4 and NLOG4J
+ 1.2.20</h3>
+
+
+ <p>The printing methods in <code>org.slf4j.Logger</code> interface
+ now support passing 3 or more parameters in an <code>Object</code>
+ array. This was a frequently requested feature missing in previous
+ versions of SLF4J.
+ </p>
+
+ <p>NLOG4J 1.2.20 reflects the addition of new methods in the
+ <code>org.slf4j.Logger</code> interface.</p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>December 8th, 2005 - Release of SLF4J 1.0-RC3</h3>
+
+ <p>Maintenance release fixing reported bugs <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=6">#6</a> and <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=7">#7</a>.
+ </p>
+
+
+ <h3>November 28th, 2005 - Release of SLF4J 1.0-RC2</h3>
+
+ <p>In response to a request by Greg Wilkins, this release adds the
+ jar file <em>slf4j-jcl.jar</em>, an SLF4J binding for JCL. Please
+ read the <a href="manual.html#gradual">gradual migration section</a>
+ in the manual for more details.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>November 21st, 2005 - Release of SLF4J 1.0-RC1</h3>
+
+ <p>A maintenance release correcting bugs <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=4">#4</a> and <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=5">#5</a>. Many
+ thanks to Christian Beil for accurately reporting bug #4.
+ </p>
+
+ <p>There has been also an effort to minimize the file sizes of the
+ various jar files produced by SLF4J, resulting in jar files
+ approximately 40% smaller than in version 1.0beta9.
+ </p>
+
+ <p>Given that the SLF4J API is now deemed stable, this release is
+ marked as RC1, that is release candidate number 1.
+ </p>
+
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>October 19th, 2005 - Release of SLF4J 1.0-beta9</h3>
+
+ <p>The SLF4J distribution now includes two distinct bindings
+ <em>slf4j-log4j12.jar</em> and <em>slf4j-log4j13.jar</em> in order
+ to differentiate between log4j version 1.2 and version 1.3. This
+ distinction is absolutely necessary because log4j 1.2 and 1.3 are
+ not run-time compatible, although they are mostly compile-time
+ compatible.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>October 19th, 2005 - Release of SLF4J 1.0-beta8 and NLOG4J 1.2.18</h3>
+
+
+ <p>Added a new SLF4J binding, <em>slf4j-log4j.jar</em>, intended to
+ be used in conjunction with vanilla <em>log4j.jar</em>, as
+ distributed by the <a href="http://logging.apache.org">Apache
+ Logging Services</a> project. The slf4j-log4j binding is quite
+ similar in structure to the JDK 1.4 binding that existed
+ previously.
+ </p>
+
+ <p>The slf4j-log4j binding addresses compatibility problems which
+ arose when copies of both <em>log4j.jar</em> and <em>nlog4j.jar</em>
+ lay on the class path, in particular when it was undesirable or
+ impossible to remove the preexisting <em>log4j.jar</em> file.
+ </p>
+
+ <p>Methods in the <code>org.slf4j.Logger</code> interface related to
+ markers were moved to a separate super interface called <a
+ href="api/org/slf4j/MarkingLogger.html">
+ <code>org.slf4j.MarkingLogger</code></a>. This refactoring reduces
+ the weight of the <a href="api/org/slf4j/Logger.html">
+ <code>Logger</code></a> interface.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>August 28th, 2005 - Release of SLF4J 1.0-beta7 and NLOG4J 1.2.17</h3>
+
+ <p>Spurred by <a
+ href="http://bugzilla.slf4j.org/show_bug.cgi?id=3">bug report
+ #3</a>, SLF4J binding code has been refactored and
+ simplified. Logging systems implementing SLF4J interfaces have to
+ have less work in order to bind with SLF4J. Moreover, these changes
+ have no incidence on the published interface of SLF4J.
+ </p>
+
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>August 26th, 2005 - Release of SLF4J 1.0-beta6</h3>
+
+ <p>To ease migration to SLF4J from JCL, this release includes a jar
+ file called <em>jcl-over-slf4j-1.0.4.jar</em>. This jar file can be
+ used as drop-in replacement for JCL version 1.0.4. It implements the
+ public API of JCL using SLF4J underneath.
+ </p>
+
+ <p>Thus, you can immediately benefit from the advantages of SLF4J
+ without waiting for all the libraries you depend on to migrate to
+ SLF4J first.</p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>August 16th, 2005 - Release of NLOG4J 1.2.16</h3>
+
+ <p>This release adds solves a compatibility problem between log4j
+ and nlog4j. Previous to this release, code compiled with log4j
+ would not run correctly with nlog4j.
+ </p>
+
+ <p>With the fixes introduced in NLOG4J 1.2.16, code compiled with
+ log4j 1.2.x will run without problems when deployed using NLOG4j.
+ </p>
+
+ <p>However, the inverse is not true. Code compiled with nlog4j can
+ only be deployed using nlog4j.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>August 12th, 2005 - Release of SLF4J 1.0-beta5 and NLOG4J
+ 1.2.15</h3>
+
+ <p>This release adds support for the <a
+ href="api/org/slf4j/Marker.html">Marker</a> interface. Thus, log
+ statements can be decorated with Marker data allowing more
+ expressive power in the processing of log statements.
+ </p>
+
+ <p>For the sake of IoC frameworks, <code>Logger</code> instances can
+ new be queried for their <a
+ href="api/org/slf4j/Logger.html#getName()">name</a>.
+ </p>
+
+ <p>With the addition of markers, sub-domains are no longer
+ needed.</p>
+
+ <p>The <code>LoggerFactoryAdapter</code> has been simplified and
+ renamed as <a
+ href="api/org/slf4j/ILoggerFactory.html"><code>ILoggerFactory</code></a>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>July 5th, 2005 - Release of NLOG4J 1.2.14</h3>
+
+ <p>This release fixes compatibility problems between NLOG4J and
+ Jakarta Commons Logging.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>June 28th, 2005 - Release of SLF4J 1.0-beta4 and NLOG4J
+ 1.2.13</h3>
+
+ <p>Following discussions on the SLF4J developers list, the
+ signatures of the printing methods in <a
+ href="api/org/slf4j/Logger.html"><code>org.slf4j.Logger</code></a>
+ interface have been modified to admit messages of type
+ <code>String</code> instead of type <code>Object</code> as
+ previously. The current set of printing methods is listed below.
+ </p>
+
+ <pre class="source">
+ void debug(String msg);
+ void debug(String format, Object arg);
+ void debug(String format, Object arg1, Object arg2);
+ void debug(String msg, Throwable t);
+
+ void error(String msg);
+ void error(String format, Object arg;)
+ void error(String format, Object arg1, Object arg2);
+ void error(String msg, Throwable t);
+
+ void info(String msg);
+ void info(String format, Object arg);
+ void info(String format, Object arg1, Object arg2);
+ void info(String msg, Throwable t);
+
+ void warn(String msg);
+ void warn(String format, Object arg);
+ void warn(String format, Object arg1, Object arg2);
+ void warn(String msg, Throwable t); </pre>
+
+
+ <p>NLOG4J release 1.2.13 reflects changes in the SLF4J API.
+ </p>
+
+ <p>You can download SLF4J and NLOG4J, including full source code,
+ class files and documentation on our <a
+ href="download.html">download page</a>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>May 17th, 2005 - SLF4J version 1.0-beta-3 released</h3>
+
+ <p>In response to user comments, the <code>org.slf4j.ULogger</code>
+ interface has been renamed as <code>org.slf4j.Logger</code>.
+ </p>
+
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>May 17th, 2005 - NLOG4J version 1.2.12 released</h3>
+
+ <p>SLF4J.ORG is proud to release NLOG4J 1.2.12, a log4j-replacement
+ with native SLF4J API support. Except for users of LF5, chainsaw or
+ <code>NTEvenAppender</code>, NLOG4J should be considered as a 100%
+ compatible, drop-in replacement for log4j version 1.2.9.
+ </p>
+
+ <p>This release reflects changes in the SLF4J API, i.e renaming of
+ <code>org.slf4j.ULogger</code> interface as
+ <code>org.slf4j.Logger</code>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>May 17th, 2005 - SLF4J version 1.0-beta-3 released</h3>
+
+ <p>SLF4J.ORG is proud to release SLF4J 1.0-beta-3. In response to
+ user comments, the <code>org.slf4j.ULogger</code> interface has been
+ renamed as <code>org.slf4j.Logger</code>.
+ </p>
+
+ <p>You can download SLF4J, including full source code, class files
+ and documentation on our <a href="download.html">download page</a>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>May 14th, 2005 - NLOG4J version 1.2.11 released</h3>
+
+ <p>SLF4J.ORG is proud to release NLOG4J 1.2.11, a log4j-replacement
+ with native SLF4J API support. Except for users of LF5, chainsaw or
+ <code>NTEvenAppender</code>, NLOG4J should be considered as a 100%
+ compatible, drop-in replacement for log4j version 1.2.9.
+ </p>
+
+ <p>You can download NLOG4J version 1.2.11, including full source
+ code, class files and documentation on our <a
+ href="download.html">download page</a>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>May 4th, 2005 - SLF4J version 1.0-beta-2 released</h3>
+
+ <p>SLF4J.ORG is proud to release SLF4J 1.0-beta-2. This release
+ contains cosmetic or javadoc changes. For example, the project has a
+ new logo.
+ </p>
+
+ <p>You can download SLF4J version 1.0-beta2, including full source
+ code, class files and documentation on our <a
+ href="download.html">download page</a>.
+ </p>
+
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>1 May 2005 - not-log4j-1.2.10 released</h3>
+
+ <p>Subsequent to the recall of log4j 1.2.10, SLF4J.ORG releases
+ non-log4j-1.2.10 for those interested in SLF4J support in log4j.
+ </p>
+
+ <p>You can download not-log4j version 1.2.10, including full source
+ code, class files and documentation on our <a
+ href="download.html">download page</a>.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+
+ <h3>22 April 2005 - SLF4J project goes live</h3>
+
+ <p>The SLF4J project site, including SVN repositories go
+ live. Users can download SLF4J version 1.0-beta1.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>15 April 2005 - start of work on SLF4J source code</h3>
+
+ <p>Start of work on the SLF4j source code.
+ </p>
+
+ <hr noshade="noshade" size="1"/>
+
+ <h3>13 April 2005 - start of work on SLF4J project</h3>
+
+ <p>Launch of the SLF4J project. Work has begun on the web-site, svn
+ repositories as well as the source code.
+ </p>
+
+
+
+
+</div>
+</body>
+</html>
Added: slf4j/trunk/slf4j-site/src/site/pages/svn.html
==============================================================================
--- (empty file)
+++ slf4j/trunk/slf4j-site/src/site/pages/svn.html Sat Mar 3 22:06:04 2007
@@ -0,0 +1,76 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+<title>SLF4J</title>
+<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
+</head>
+<body>
+ <script>
+prefix='';
+</script>
+
+<script src="templates/header.js"></script>
+<div id="left">
+ <script src="templates/left.js"></script>
+</div>
+<div id="right">
+ <script src="templates/right.js"></script>
+</div>
+<div id="content">
+
+ <h1>Source code repositories</h1>
+
+ <p>SLF4j developers live in different countries throughout the
+ world. To enable them to work together, we keep the source code in
+ a revision control system called Subversion. SLF4J developers have write
+ access to the Subversion repository, enabling them to make changes
+ to the source code. Everyone else has read access to the repository, so
+ you may check out the most up-to-date development version of the
+ software. Note that the latest version in the Subversion repository
+ many not work as expected, it may not even compile properly. If you
+ are looking for a stable release of the source code, you should
+ download an official distribution instead of the latest version from Subversion. </p>
+
+
+ <p>There are several ways to access the Subversion repository:</p>
+
+ <h2>Web Access</h2>
+
+ <p>If you just wish to browse around or download a few individual
+ files, the best tool is the web-based ViewVC interface for
+ Subversion repositories:
+ </p>
+
+ <table cellspacing="6">
+ <tr>
+ <td>For SLF4J </td>
+ <td><a href="http://svn.slf4j.org/viewvc/slf4j/trunk/">
+ http://svn.slf4j.org/viewvc/slf4j/trunk/</a>
+ </td>
+ </tr>
+
+ </table>
+
+ <h2>Checking out a read-only copy</h2>
+
+
+ <p>To access the Subversion repositories anonymously, you will need
+ a Subversion client.
+ </p>
+
+ <p>To check out the SLF4j module, issue the following command: </p>
+
+ <pre class="cmd">svn checkout <b>http://svn.slf4j.org/repos/slf4j/trunk</b></pre>
+
+ <p>Note that anonymous access allows read-only access only. For
+ read-write access please contact the <a
+ href="http://slf4j.org/mailman/listinfo/dev">slf4j developer list</a>.
+ </p>
+
+
+
+
+</div>
+</body>
+</html>
More information about the slf4j-dev
mailing list