July 2006 - logback-dev - mailman3.qos.ch

svn commit: r368 - logback/access/trunk/src/site/xdocTemplates
by noreply.seb＠qos.ch 28 Jul '06

28 Jul '06

Author: seb Date: Fri Jul 28 11:01:54 2006 New Revision: 368 Modified: logback/access/trunk/src/site/xdocTemplates/repos.xml Log: changed title Modified: logback/access/trunk/src/site/xdocTemplates/repos.xml ============================================================================== --- logback/access/trunk/src/site/xdocTemplates/repos.xml (original) +++ logback/access/trunk/src/site/xdocTemplates/repos.xml Fri Jul 28 11:01:54 2006 @@ -9,7 +9,7 @@ <body> <div class="section"> - <h2>Repository</h2> + <h2>Source Repository</h2> </div> <p>

1 0

svn commit: r367 - logback/classic/trunk/src/site/xdocTemplates
by noreply.seb＠qos.ch 28 Jul '06

28 Jul '06

Author: seb Date: Fri Jul 28 11:01:52 2006 New Revision: 367 Modified: logback/classic/trunk/src/site/xdocTemplates/repos.xml Log: changed title Modified: logback/classic/trunk/src/site/xdocTemplates/repos.xml ============================================================================== --- logback/classic/trunk/src/site/xdocTemplates/repos.xml (original) +++ logback/classic/trunk/src/site/xdocTemplates/repos.xml Fri Jul 28 11:01:52 2006 @@ -8,7 +8,7 @@ <body> <div class="section"> - <h2>Repository</h2> + <h2>Source Repository</h2> </div> <p>

1 0

svn commit: r366 - logback/skin/trunk/src/main/resources/css
by noreply.ceki＠qos.ch 27 Jul '06

27 Jul '06

Author: ceki Date: Thu Jul 27 22:52:58 2006 New Revision: 366 Modified: logback/skin/trunk/src/main/resources/css/site.css Log: Modified css Modified: logback/skin/trunk/src/main/resources/css/site.css ============================================================================== --- logback/skin/trunk/src/main/resources/css/site.css (original) +++ logback/skin/trunk/src/main/resources/css/site.css Thu Jul 27 22:52:58 2006 @@ -241,11 +241,16 @@ } .source { - border: 1px solid #999; - font-family: Courier, monospace; - padding: 12px; - margin: 1em 7px 1em 7px; + border-top: 1px solid #DDDDDD; + border-bottom: 1px solid #DDDDDD; + background:#eee; + font-family: Courier, "MS Courier New", Prestige, Everson Monocourrier, monospace; + padding-bottom: 0.5ex; + padding-top: 0.5ex; + padding-left: 1ex; white-space: pre; + width: 55em; + } .source pre {

1 0

svn commit: r365 - logback/classic/trunk/src/site/xdocTemplates
by noreply.ceki＠qos.ch 27 Jul '06

27 Jul '06

Author: ceki Date: Thu Jul 27 22:47:17 2006 New Revision: 365 Modified: logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml Log: - The introduction section and the architecture repeat the same text. (I did not have time to perform the clean up.) - Changed "source" style to use the 'white-space: pre;' style. It's much more convenient than having to format source code manually. - In the short manual, use the letter L instead of C in logger related rules. - removed 3 paragraphs discussing object rendering as this concept is not implemented in LB. - performed many indentation related changes. Modified: logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml ============================================================================== --- logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml (original) +++ logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml Thu Jul 27 22:47:17 2006 @@ -10,9 +10,9 @@ <table> <tr> - <td> + <td valign="top" align="top"> <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/2.5/"> - <img alt="Creative Commons License" border="0" valign="top" + <img alt="Creative Commons License" border="0" valign="top" align="top" src="http://creativecommons.org/images/public/somerights20.png"/> </a> </td> @@ -108,7 +108,7 @@ messages are formatted and where they are reported. </p> <p> - The Loggers are defined in the classic module. On the other + Loggers are defined in the classic module. On the other hand, Appenders and Layouts are defined in the core module of logback. </p> @@ -141,17 +141,11 @@ </div> <p> - For example, the logger named - <code>"com.foo"</code> - is a parent of the logger named - <code>"com.foo.Bar"</code> - . Similarly, - <code>"java"</code> - is a parent of - <code>"java.util"</code> - and an ancestor of - <code>"java.util.Vector"</code> - . This naming scheme should be familiar to most developers. + For example, the logger named <code>"com.foo"</code> is a parent + of the logger named <code>"com.foo.Bar"</code> . Similarly, + <code>"java"</code> is a parent of <code>"java.util"</code> and + an ancestor of <code>"java.util.Vector"</code> . This naming + scheme should be familiar to most developers. </p> <p> The root logger resides at the top of the logger hierarchy. @@ -161,44 +155,36 @@ <li>it always exists,</li> <li>it cannot be retrieved by name.</li> </ol> - All other loggers are retrieved with the class static + + <p>All other loggers are retrieved with the class static LoggerFactory.getLogger method. This method takes the name of the desired logger as a parameter. Some of the basic methods in the Logger interface are listed below. - <div class="source"> - <p>package org.slf4j;</p> + </p> - <p>public interface Logger {</p> - <p> - // Creation and retrieval method: - <br /> - public static Logger getLogger(String name); - <br /> - </p> - <p> - // printing methods: - <br /> - public void debug(Object message); - <br /> - public void info(Object message); - <br /> - public void warn(Object message); - <br /> - public void error(Object message); - <br /> - public void fatal(Object message); - <br /> - </p> - <p>}</p> - </div> - <p> - Loggers may be assigned levels. The set of possible levels, - that is DEBUG, INFO, WARN, ERROR and FATAL are defined in - the org.apache.log4j.Level class. Although we do not - encourage you to do so, you may define your own levels by - sub-classing the Level class. A perhaps better approach will - be explained later on. + <div class="source">package org.slf4j; + +public interface Logger { + + // Creation and retrieval method: + public static Logger getLogger(String name); + + // printing methods: + public void debug(Object message); + public void info(Object message); + public void warn(Object message); + public void error(Object message); + public void fatal(Object message); +}</div> + + <p> + Loggers may be assigned levels. The set of possible levels, that + is DEBUG, INFO, WARN and ERROR are defined in the + org.apache.log4j.Level class. The level class cannot be + sub-classed as a much better approach exist in the form of + Marker objects. </p> + <p> If a given logger is not assigned a level, then it inherits one from its closest ancestor with an assigned level. More @@ -208,10 +194,10 @@ <div class="definition"> <div class="deftitle">Level Inheritance</div> <p> - The inherited level for a given logger C, is equal to - the first non-null level in the logger hierarchy, - starting at C and proceeding upwards in the hierarchy - towards the root logger. + The inherited level for a given logger <em>L</em>, is equal to + the first non-null level in the logger hierarchy, starting at + <em>L</em> and proceeding upwards in the hierarchy towards the + root logger. </p> </div> <p> @@ -426,22 +412,13 @@ </table> <p> - In example 4, the loggers - <code>root</code> - and - <code>X</code> - and are assigned the levels - <code>Proot</code> - and + In example 4, the loggers <code>root</code> and <code>X</code> + and are assigned the levels <code>Proot</code> and <code>Px</code> - respectively. The loggers - <code>X.Y</code> - and - <code>X.Y.Z</code> - inherits their level value from their nearest parent - <code>X</code> - having an assigned level. + respectively. The loggers <code>X.Y</code> and + <code>X.Y.Z</code> inherits their level value from their nearest + parent <code>X</code> having an assigned level. </p> <p> @@ -452,20 +429,16 @@ <p> By definition, the printing method determines the level of a - logging request. For example, if - <code>c</code> - is a logger instance, then the statement - <code>c.info("..")</code> - is a logging request of level INFO. + logging request. For example, if <code>c</code> is a logger + instance, then the statement <code>c.info("..")</code> is a + logging request of level INFO. </p> <p> - A logging request is said to be - <em>enabled</em> - if its level is higher than or equal to the level of its - logger. Otherwise, the request is said to be - <em>disabled</em> - . A logger without an assigned level will inherit one from - the hierarchy. This rule is summarized below. + A logging request is said to be <em>enabled</em> if its level is + higher than or equal to the level of its logger. Otherwise, the + request is said to be <em>disabled</em>. A logger without an + assigned level will inherit one from the hierarchy. This rule is + summarized below. </p> <div class="definition"> <div class="deftitle">Basic Selection Rule</div> @@ -491,74 +464,25 @@ </p> <p>Here is an example of this rule.</p> - <div class="source"> - <p> - // get a logger instance named "com.foo", with an - <span class="blue">INFO</span> - level. - <br /> - Logger logger = LoggerFactory.getLogger("com.foo"); - <br /> - </p> - <p> - Logger barlogger = - LoggerFactory.getLogger("com.foo.Bar"); - <br /> - </p> - <p> - // This request is enabled, because - <span class="green">WARN</span> - >= - <span class="blue">INFO</span> - . - <br /> - logger. - <span class="green">warn</span> - ("Low fuel level."); - <br /> - </p> - <p> - // This request is disabled, because - <span class="green">DEBUG</span> - < - <span class="blue">INFO</span> - . - <br /> - logger. - <span class="green">debug</span> - ("Starting search for nearest gas station."); - <br /> - </p> - <p> - // The logger instance barlogger, named "com.foo.Bar", - <br /> - // will inherit its level from the logger named - <br /> - // "com.foo" Thus, the following request is enabled - <br /> - // because - <span class="green">INFO</span> - >= - <span class="blue">INFO</span> - . - <br /> - barlogger. - <span class="green">info</span> - ("Located nearest gas station."); - <br /> - </p> - <p> - // This request is disabled, because - <span class="green">DEBUG</span> - < - <span class="blue">INFO</span> - . - <br /> - barlogger. - <span class="green">debug</span> - ("Exiting gas station search"); - <br /> - </p> + <div class="source">// get a logger instance named "com.foo", with an <span class="blue">INFO</span> level. + Logger logger = LoggerFactory.getLogger("com.foo"); + + Logger barlogger = LoggerFactory.getLogger("com.foo.Bar"); + + // This request is enabled, because <span class="green">WARN</span> >= <span class="blue">INFO</span> + logger.<span class="green">warn</span>("Low fuel level."); + + + // This request is disabled, because <span class="green">DEBUG</span> < <span class="blue">INFO</span>. + logger.<span class="green">debug</span>("Starting search for nearest gas station."); + // The logger instance barlogger, named "com.foo.Bar", + // will inherit its level from the logger named + // "com.foo" Thus, the following request is enabled + // because <span class="green">INFO</span> >= <span class="blue">INFO</span>. + barlogger.<span class="green">info</span>("Located nearest gas station."); + + // This request is disabled, because <span class="green">DEBUG</span> < <span class="blue">INFO</span>. + barlogger.<span class="green">debug</span>("Exiting gas station search"); </div> <p> @@ -567,29 +491,23 @@ method with the same name will always return a reference to the exact same logger object. </p> + <p>For example, in</p> - <div class="source"> - Logger x = LoggerFactory.getLogger("wombat"); - <br /> - Logger y = LoggerFactory.getLogger("wombat"); - </div> - <code>x</code> - and - <code>y</code> - refer to - <em>exactly</em> - the same logger object. + <div class="source">Logger x = LoggerFactory.getLogger("wombat"); +Logger y = LoggerFactory.getLogger("wombat");</div> + <p><code>x</code> and <code>y</code> refer to <em>exactly</em> the + same logger object. + </p> <p> - Thus, it is possible to configure a logger and then to - retrieve the same instance somewhere else in the code - without passing around references. In fundamental - contradiction to biological parenthood, where parents always - preceed their children, logback classic loggers can be - created and configured in any order. In particular, a - "parent" logger will find and link to its descendants even - if it is instantiated after them. + Thus, it is possible to configure a logger and then to retrieve + the same instance somewhere else in the code without passing + around references. In fundamental contradiction to biological + parenthood, where parents always preceed their children, logback + classic loggers can be created and configured in any order. In + particular, a "parent" logger will find and link to its + descendants even if it is instantiated after them. </p> <p> Configuration of the logback environment is typically done @@ -598,18 +516,16 @@ discussed shortly. </p> <p> - Logback makes it easy to name loggers by - <em>software component</em> - . This can be accomplished by statically instantiating a - logger in each class, with the logger name equal to the - fully qualified name of the class. This is a useful and - straightforward method of defining loggers. As the log - output bears the name of the generating logger, this naming - strategy makes it easy to identify the origin of a log - message. However, this is only one possible, albeit common, - strategy for naming loggers. Logback does not restrict the - possible set of loggers. The developer is free to name the - loggers as desired. + Logback makes it easy to name loggers by <em>software + component</em>. This can be accomplished by statically + instantiating a logger in each class, with the logger name equal + to the fully qualified name of the class. This is a useful and + straightforward method of defining loggers. As the log output + bears the name of the generating logger, this naming strategy + makes it easy to identify the origin of a log message. However, + this is only one possible, albeit common, strategy for naming + loggers. Logback does not restrict the possible set of + loggers. The developer is free to name the loggers as desired. </p> <p> Nevertheless, naming loggers after the class where they are @@ -619,65 +535,57 @@ <div class="section"> <h3>Appenders and Layouts</h3> </div> - <p> - The ability to selectively enable or disable logging - requests based on their logger is only part of the picture. - Log4j allows logging requests to print to multiple - destinations. In log4j speak, an output destination is - called an appender. Currently, appenders exist for the - console, files, GUI components, remote socket servers, JMS, - NT Event Loggers, and remote UNIX Syslog daemons. It is also - possible to log asynchronously. + + <p> The ability to selectively enable or disable logging requests + based on their logger is only part of the picture. Logback allows + logging requests to print to multiple destinations. In logback + speak, an output destination is called an appender. Currently, + appenders exist for the console, files, remote socket servers, + JMS, and remote UNIX Syslog daemons. It is also possible to log + asynchronously. </p> + <p>More than one appender can be attached to a logger.</p> <p> - The addAppender method adds an appender to a given logger. - Each enabled logging request for a given logger will be - forwarded to all the appenders in that logger as well as the - appenders higher in the hierarchy. In other words, appenders - are inherited additively from the logger hierarchy. For - example, if a console appender is added to the root logger, - then all enabled logging requests will at least print on the - console. If in addition a file appender is added to a - logger, say C, then enabled logging requests for C and C's - children will print on a file and on the console. It is - possible to override this default behavior so that appender - accumulation is no longer additive by setting the additivity - flag to false. + The addAppender method adds an appender to a given logger. Each + enabled logging request for a given logger will be forwarded to + all the appenders in that logger as well as the appenders higher + in the hierarchy. In other words, appenders are inherited + additively from the logger hierarchy. For example, if a console + appender is added to the root logger, then all enabled logging + requests will at least print on the console. If in addition a + file appender is added to a logger, say <em>L</em>, then enabled + logging requests for <em>L</em> and <em>L</em>'s children will + print on a file and on the console. It is possible to override + this default behavior so that appender accumulation is no longer + additive by setting the additivity flag to false. </p> + <p> The rules governing appender additivity are summarized below. </p> <div class="definition"> + <div class="deftitle">Appender Additivity</div> - <p> - The output of a log statement of logger - <em>C</em> - will go to all the appenders in - <em>C</em> - and its ancestors. This is the meaning of the term - "appender additivity". + + <p> + The output of a log statement of logger <em>L</em> will go to + all the appenders in <em>L</em> and its ancestors. This is the + meaning of the term "appender additivity". </p> - <p> - However, if an ancestor of logger - <em>C</em> - , say - <em>P</em> - , has the additivity flag set to false, then - <em>C</em> - 's output will be directed to all the appenders in - <em>C</em> - and it's ancestors upto and including - <em>P</em> - but not the appenders in any of the ancestors of - <em>P</em> - . + + <p> However, if an ancestor of logger <em>L</em> , say + <em>P</em>, has the additivity flag set to false, then + <em>L</em>'s output will be directed to all the appenders in + <em>L</em> and it's ancestors upto and including <em>P</em> but + not the appenders in any of the ancestors of <em>P</em> . </p> + <p> - Loggers have their additivity flag set to true by - default. + Loggers have their additivity flag set to true by default. </p> + </div> The table below shows an example: @@ -749,19 +657,17 @@ <p> - More often than not, users wish to customize not only the - output destination but also the output format. This is - accomplished by associating a - <em>layout</em> - with an appender. The layout is responsible for formatting - the logging request according to the user's wishes, whereas - an appender takes care of sending the formatted output to - its destination. The PatternLayout, part of the standard - log4j distribution, lets the user specify the output format - according to conversion patterns similar to the C language - <code>printf</code> - function. + More often than not, users wish to customize not only the output + destination but also the output format. This is accomplished by + associating a <em>layout</em> with an appender. The layout is + responsible for formatting the logging request according to the + user's wishes, whereas an appender takes care of sending the + formatted output to its destination. The PatternLayout, part of + the standard logback distribution, lets the user specify the + output format according to conversion patterns similar to the C + language <code>printf</code> function. </p> + <p> For example, the PatternLayout with the conversion pattern "%r [%t] %-5p %c - %m%n" will output something akin to: @@ -779,89 +685,50 @@ associated with the log request. The text after the '-' is the message of the statement. </p> - <p> - Just as importantly, log4j will render the content of the - log message according to user specified criteria. For - example, if you frequently need to log - <code>Oranges</code> - , an object type used in your current project, then you can - register an - <code>OrangeRenderer</code> - that will be invoked whenever an orange needs to be logged. - </p> - <p> - Object rendering follows the class hierarchy. For example, - assuming oranges are fruits, if you register an - <code>FruitRenderer</code> - , all fruits including oranges will be rendered by the - <code>FruitRenderer</code> - , unless of course you registered an orange specific - <code>OrangeRenderer</code> - . - </p> - <p> - Object renderers have to implement the ObjectRenderer - interface. - </p> <h4>More sophitsicated ways of logging</h4> <p> If you are a SLF4J user (if not, you should be...), you'll - notice that the methods used to request logging do not only - take a String as a parameter. Some methods allow more - sophisticated parameter configurations. + notice that the methods used to request logging do not only take + a String as a parameter. Some methods allow more sophisticated + parameter configurations. </p> - <p> - For some Logger - <code>logger</code> - , writing, - </p> + <p> For some Logger <code>logger</code>, writing, </p> + <div class="source"> - logger.debug("Entry number: " + i + " is " + - String.valueOf(entry[i])); + logger.debug("Entry number: " + i + " is " + + String.valueOf(entry[i])); </div> - <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> 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 + One possible way to avoid the cost of parameter construction is + by surrounding the log statement with a test. Here is an example. </p> <div class="source"> - if(logger.isDebugEnabled()) { - <br /> - logger.debug("Entry number: " + i + " is " + - String.valueOf(entry[i])); - <br /> - } - </div> +if(logger.isDebugEnabled()) { + logger.debug("Entry number: " + i + " is " + + String.valueOf(entry[i])); +} </div> - <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> 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> <h4>Better alternative based on format messages</h4>

1 0

svn commit: r364 - logback/skin/trunk/src/main/resources/css
by noreply.ceki＠qos.ch 27 Jul '06

27 Jul '06

Author: ceki Date: Thu Jul 27 22:20:22 2006 New Revision: 364 Modified: logback/skin/trunk/src/main/resources/css/site.css Log: Using the 'white-space: pre;' style to format source. It's much more convenient than having to format source code manually. Modified: logback/skin/trunk/src/main/resources/css/site.css ============================================================================== --- logback/skin/trunk/src/main/resources/css/site.css (original) +++ logback/skin/trunk/src/main/resources/css/site.css Thu Jul 27 22:20:22 2006 @@ -245,6 +245,7 @@ font-family: Courier, monospace; padding: 12px; margin: 1em 7px 1em 7px; + white-space: pre; } .source pre {

1 0

svn commit: r363 - logback/classic/trunk/src/site/xdocTemplates
by noreply.ceki＠qos.ch 27 Jul '06

27 Jul '06

Author: ceki Date: Thu Jul 27 22:00:25 2006 New Revision: 363 Modified: logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml Log: - Changed the license to Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 License instead of Apache License. We can do this because Ceki is the author of the original document which was donated to the ASF. Modified: logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml ============================================================================== --- logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml (original) +++ logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml Thu Jul 27 22:00:25 2006 @@ -6,14 +6,28 @@ <div class="author"> Authors: Ceki Gülcü, Sébastien Pennec </div> - <p> - Copyright © 2000-2006, The Apache Software Foundation. - Licensed under the Apache License, Version 2.0. The present - short manual also borrows some text from "The complete log4j - manual", which contains more detailed and up to date - information, by Ceki Gülcü. - </p> + + <table> + <tr> + <td> + <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/2.5/"> + <img alt="Creative Commons License" border="0" valign="top" + src="http://creativecommons.org/images/public/somerights20.png"/> + </a> + </td> + <td> + <p>Copyright © 2000-2006, QOS.ch </p> + + <p>This work is licensed under a <a rel="license" + href="http://creativecommons.org/licenses/by-nc-nd/2.5/">Creative + Commons Attribution-Noncommercial-No Derivative Works 2.5 + License</a>. + </p> + </td> + </tr> + </table> + <div class="section"> <h2>Introduction</h2> </div>

1 0

svn commit: r362 - logback/topLevel/trunk/src/site/xdocTemplates
by noreply.seb＠qos.ch 27 Jul '06

27 Jul '06

Author: seb Date: Thu Jul 27 18:55:17 2006 New Revision: 362 Modified: logback/topLevel/trunk/src/site/xdocTemplates/index.xml Log: because he cares about his name :) Modified: logback/topLevel/trunk/src/site/xdocTemplates/index.xml ============================================================================== --- logback/topLevel/trunk/src/site/xdocTemplates/index.xml (original) +++ logback/topLevel/trunk/src/site/xdocTemplates/index.xml Thu Jul 27 18:55:17 2006 @@ -3,7 +3,7 @@ <document> <properties> - <author email="ceki at qos ddoott ch ">Ceki Gulcu</author> + <author email="ceki at qos ddoott ch ">Ceki Gülcü</author> <title>${pom.name} download</title> </properties>

1 0

svn commit: r361 - logback/classic/trunk/src/site/xdocTemplates
by noreply.seb＠qos.ch 27 Jul '06

27 Jul '06

Author: seb Date: Thu Jul 27 18:52:41 2006 New Revision: 361 Added: logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml Modified: logback/classic/trunk/src/site/xdocTemplates/documentation.xml Log: first commit of a short introduction to logback classic Modified: logback/classic/trunk/src/site/xdocTemplates/documentation.xml ============================================================================== --- logback/classic/trunk/src/site/xdocTemplates/documentation.xml (original) +++ logback/classic/trunk/src/site/xdocTemplates/documentation.xml Thu Jul 27 18:52:41 2006 @@ -12,16 +12,20 @@ <h2>Documentation</h2> </div> + <p>Here are some documents about ${pom.name}.</p> <p> - Here are some documents about ${pom.name}. - </p> - <p> - This section is pretty light at the moment, but will grow with the developping - of ${pom.name}. + This section is pretty light at the moment, but will grow + with the developping of ${pom.name}. </p> <ul> <li> + <a href="shortIntro.html"> + A Short Introduction to logback classic + </a> + + </li> + <li> <a href="apidocs/index.html">${pom.name} Javadoc</a> </li> </ul> Added: logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml ============================================================================== --- (empty file) +++ logback/classic/trunk/src/site/xdocTemplates/shortIntro.xml Thu Jul 27 18:52:41 2006 @@ -0,0 +1,924 @@ +<document> + <body> + <div class="section"> + <h2>Short introduction</h2> + </div> + <div class="author"> + Authors: Ceki Gülcü, Sébastien Pennec + </div> + <p> + Copyright © 2000-2006, The Apache Software Foundation. + Licensed under the Apache License, Version 2.0. The present + short manual also borrows some text from "The complete log4j + manual", which contains more detailed and up to date + information, by Ceki Gülcü. + </p> + + <div class="section"> + <h2>Introduction</h2> + </div> + <p> + Logging is a low-tech way of debugging your code. It might + also be the only way, when debuggers are not available or + applicable. Logback classic can help you insert logging + functionalities in your code without polluting its + readability with useless statements, or diminishing its + performance. + </p> + <p> + Logback is intended as a successor to the popular log4j + project. It was also designed by Ceki Gülcü, the + founder of the log4j project. It builds upon experience + gained in building industrial-strength logging systems going + back as far as 1999. + </p> + <p> + Logback's basic architecture is sufficiently generic so as + to apply under different circumstances. At present time, + logback is divided into three modules, Core, Classic and + Access. + </p> + <p> + The Core module lays the groundwork for the other two + modules. The Classic module can be assimilated to an + improved version of log4j. Logback Classic natively + implements the + <a href="http://www.slf4j.org">SLF4J API</a> + so that you can readily switch back and forth between + logback and other logging systems such as log4j or JDK14 + Logging. The Access module integrates with Servlet + containers to provide HTPP-access log functionality. Note + that you can easily build your own modules on top of the + Core module. + </p> + <p> + Before rushing to install and configure logback classic on + your own application, here is a presentation of how things + work. + </p> + + <div class="section"> + <h2>Logback architecture</h2> + + <p> + Logback's basic architecture is sufficiently generic so + as to apply under different circumstances. At present + time, logback is divided into three modules, Core, + Classic and Access. + </p> + <p> + The Core module lays the groundwork for the other two + modules. The Classic module extends the core module, it + can be assimilated to an improved version of log4j. + Logback Classic natively implements the SLF4J API so + that you can readily switch back and forth between + logback and other logging systems such as log4j or JDK14 + Logging. The Access module also extends the core + functionnalities and integrates with Servlet containers + to provide HTPP-access log functionality. + </p> + <p> + Note that you can easily build your own modules on top + of the Core module. + </p> + </div> + + <div class="section"> + <h2>Logger, Appenders and Layouts</h2> + </div> + <p> + Logback classic has three main components: Loggers, + Appenders and Layouts. These three types of components work + together to enable developers to log messages according to + message type and level, and to control at runtime how these + messages are formatted and where they are reported. + </p> + <p> + The Loggers are defined in the classic module. On the other + hand, Appenders and Layouts are defined in the core module + of logback. + </p> + + <div class="section"> + <h3>Logger hierarchy</h3> + </div> + <p> + The first and foremost advantage of any logging API over + plain System.out.println resides in its ability to disable + certain log statements while allowing others to print + unhindered. This capability assumes that the logging space, + that is, the space of all possible logging statements, is + categorized according to some developer-chosen criteria. + Loggers are named entities. + </p> + <p> + Logger names are case-sensitive and they follow the + hierarchical naming rule: + </p> + <div class="definition"> + <div class="deftitle">Named Hierarchy</div> + <p> + A logger is said to be an ancestor of another logger if + its name followed by a dot is a prefix of the descendant + logger name. A logger is said to be a parent of a child + logger if there are no ancestors between itself and the + descendant logger. + </p> + </div> + + <p> + For example, the logger named + <code>"com.foo"</code> + is a parent of the logger named + <code>"com.foo.Bar"</code> + . Similarly, + <code>"java"</code> + is a parent of + <code>"java.util"</code> + and an ancestor of + <code>"java.util.Vector"</code> + . This naming scheme should be familiar to most developers. + </p> + <p> + The root logger resides at the top of the logger hierarchy. + It is exceptional in two ways: + </p> + <ol> + <li>it always exists,</li> + <li>it cannot be retrieved by name.</li> + </ol> + All other loggers are retrieved with the class static + LoggerFactory.getLogger method. This method takes the name of + the desired logger as a parameter. Some of the basic methods in + the Logger interface are listed below. + <div class="source"> + <p>package org.slf4j;</p> + + <p>public interface Logger {</p> + <p> + // Creation and retrieval method: + <br /> + public static Logger getLogger(String name); + <br /> + </p> + <p> + // printing methods: + <br /> + public void debug(Object message); + <br /> + public void info(Object message); + <br /> + public void warn(Object message); + <br /> + public void error(Object message); + <br /> + public void fatal(Object message); + <br /> + </p> + <p>}</p> + </div> + <p> + Loggers may be assigned levels. The set of possible levels, + that is DEBUG, INFO, WARN, ERROR and FATAL are defined in + the org.apache.log4j.Level class. Although we do not + encourage you to do so, you may define your own levels by + sub-classing the Level class. A perhaps better approach will + be explained later on. + </p> + <p> + If a given logger is not assigned a level, then it inherits + one from its closest ancestor with an assigned level. More + formally: + </p> + + <div class="definition"> + <div class="deftitle">Level Inheritance</div> + <p> + The inherited level for a given logger C, is equal to + the first non-null level in the logger hierarchy, + starting at C and proceeding upwards in the hierarchy + towards the root logger. + </p> + </div> + <p> + To ensure that all loggers can eventually inherit a level, + the root logger always has an assigned level. + </p> + <p> + Below are four examples with various assigned level values + and the resulting inherited levels according to the above + rule. + </p> + + <table class="exampleTable"> + <tr> + <th> + Logger + <br /> + name + </th> + <th> + Assigned + <br /> + level + </th> + + <th> + Inherited + <br /> + level + </th> + </tr> + <tr> + <td>root</td> + <td>Proot</td> + <td>Proot</td> + </tr> + <tr> + <td>X</td> + <td>none</td> + <td>Proot</td> + </tr> + + <tr> + <td>X.Y</td> + <td>none</td> + <td>Proot</td> + </tr> + <tr> + <td>X.Y.Z</td> + <td>none</td> + <td>Proot</td> + </tr> + </table> + <p> + In example 1 above, only the root logger is assigned a + level. + </p> + This level value, + <code>Proot</code> + , is inherited by the other loggers + <code>X</code> + , + <code>X.Y</code> + and + <code>X.Y.Z</code> + <table class="exampleTable"> + <tr> + <th> + Logger + <br /> + name + </th> + <th> + Assigned + <br /> + level + </th> + + <th> + Inherited + <br /> + level + </th> + </tr> + <tr align="left"> + <td>root</td> + <td>Proot</td> + <td>Proot</td> + </tr> + <tr align="left"> + <td>X</td> + <td>Px</td> + <td>Px</td> + </tr> + + <tr align="left"> + <td>X.Y</td> + <td>Pxy</td> + <td>Pxy</td> + </tr> + <tr align="left"> + <td>X.Y.Z</td> + <td>Pxyz</td> + <td>Pxyz</td> + </tr> + </table> + + <p> + In example 2, all loggers have an assigned level value. + There is no need for level inheritence. + </p> + + <table class="exampleTable"> + <tr> + <th> + Logger + <br /> + name + </th> + <th> + Assigned + <br /> + level + </th> + <th> + Inherited + <br /> + level + </th> + </tr> + <tr align="left"> + <td>root</td> + <td>Proot</td> + <td>Proot</td> + </tr> + + <tr align="left"> + <td>X</td> + <td>Px</td> + <td>Px</td> + </tr> + <tr align="left"> + <td>X.Y</td> + <td>none</td> + <td>Px</td> + </tr> + <tr align="left"> + <td>X.Y.Z</td> + <td>Pxyz</td> + <td>Pxyz</td> + </tr> + </table> + <p> + In example 3, the loggers + <code>root</code> + , + <code>X</code> + and + <code>X.Y.Z</code> + are assigned the levels + <code>Proot</code> + , + <code>Px</code> + and + <code>Pxyz</code> + respectively. The logger + <code>X.Y</code> + inherits its level value from its parent + <code>X</code> + . + </p> + <table class="exampleTable"> + + <tr> + <th> + Logger + <br /> + name + </th> + <th> + Assigned + <br /> + level + </th> + <th> + Inherited + <br /> + level + </th> + </tr> + <tr align="left"> + <td>root</td> + <td>Proot</td> + <td>Proot</td> + </tr> + + <tr align="left"> + <td>X</td> + <td>Px</td> + <td>Px</td> + </tr> + <tr align="left"> + <td>X.Y</td> + <td>none</td> + <td>Px</td> + </tr> + <tr align="left"> + <td>X.Y.Z</td> + <td>none</td> + <td>Px</td> + </tr> + </table> + + <p> + In example 4, the loggers + <code>root</code> + and + <code>X</code> + and are assigned the levels + <code>Proot</code> + and + <code>Px</code> + + respectively. The loggers + <code>X.Y</code> + and + <code>X.Y.Z</code> + inherits their level value from their nearest parent + <code>X</code> + having an assigned level. + </p> + + <p> + In a more graphic way, here is how you the logger hierarchy + works: + </p> + + + <p> + By definition, the printing method determines the level of a + logging request. For example, if + <code>c</code> + is a logger instance, then the statement + <code>c.info("..")</code> + is a logging request of level INFO. + </p> + <p> + A logging request is said to be + <em>enabled</em> + if its level is higher than or equal to the level of its + logger. Otherwise, the request is said to be + <em>disabled</em> + . A logger without an assigned level will inherit one from + the hierarchy. This rule is summarized below. + </p> + <div class="definition"> + <div class="deftitle">Basic Selection Rule</div> + + <p> + A log request of level + <em>p</em> + in a logger with (either assigned or inherited, + whichever is appropriate) level + <em>q</em> + , is enabled if + <em>p >= q</em> + . + </p> + + </div> + + <p> + This rule is at the heart of logback classic. It assumes + that levels are ordered. For the standard levels, we have + <code>DEBUG < INFO < WARN < ERROR</code> + . + </p> + <p>Here is an example of this rule.</p> + + <div class="source"> + <p> + // get a logger instance named "com.foo", with an + <span class="blue">INFO</span> + level. + <br /> + Logger logger = LoggerFactory.getLogger("com.foo"); + <br /> + </p> + <p> + Logger barlogger = + LoggerFactory.getLogger("com.foo.Bar"); + <br /> + </p> + <p> + // This request is enabled, because + <span class="green">WARN</span> + >= + <span class="blue">INFO</span> + . + <br /> + logger. + <span class="green">warn</span> + ("Low fuel level."); + <br /> + </p> + <p> + // This request is disabled, because + <span class="green">DEBUG</span> + < + <span class="blue">INFO</span> + . + <br /> + logger. + <span class="green">debug</span> + ("Starting search for nearest gas station."); + <br /> + </p> + <p> + // The logger instance barlogger, named "com.foo.Bar", + <br /> + // will inherit its level from the logger named + <br /> + // "com.foo" Thus, the following request is enabled + <br /> + // because + <span class="green">INFO</span> + >= + <span class="blue">INFO</span> + . + <br /> + barlogger. + <span class="green">info</span> + ("Located nearest gas station."); + <br /> + </p> + <p> + // This request is disabled, because + <span class="green">DEBUG</span> + < + <span class="blue">INFO</span> + . + <br /> + barlogger. + <span class="green">debug</span> + ("Exiting gas station search"); + <br /> + </p> + </div> + + <p> + Calling the + <code>getLogger</code> + method with the same name will always return a reference to + the exact same logger object. + </p> + <p>For example, in</p> + <div class="source"> + Logger x = LoggerFactory.getLogger("wombat"); + <br /> + Logger y = LoggerFactory.getLogger("wombat"); + </div> + <code>x</code> + and + <code>y</code> + refer to + <em>exactly</em> + the same logger object. + + + <p> + Thus, it is possible to configure a logger and then to + retrieve the same instance somewhere else in the code + without passing around references. In fundamental + contradiction to biological parenthood, where parents always + preceed their children, logback classic loggers can be + created and configured in any order. In particular, a + "parent" logger will find and link to its descendants even + if it is instantiated after them. + </p> + <p> + Configuration of the logback environment is typically done + at application initialization. The preferred way is by + reading a configuration file. This approach will be + discussed shortly. + </p> + <p> + Logback makes it easy to name loggers by + <em>software component</em> + . This can be accomplished by statically instantiating a + logger in each class, with the logger name equal to the + fully qualified name of the class. This is a useful and + straightforward method of defining loggers. As the log + output bears the name of the generating logger, this naming + strategy makes it easy to identify the origin of a log + message. However, this is only one possible, albeit common, + strategy for naming loggers. Logback does not restrict the + possible set of loggers. The developer is free to name the + loggers as desired. + </p> + <p> + Nevertheless, naming loggers after the class where they are + located seems to be the best strategy known so far. + </p> + + <div class="section"> + <h3>Appenders and Layouts</h3> + </div> + <p> + The ability to selectively enable or disable logging + requests based on their logger is only part of the picture. + Log4j allows logging requests to print to multiple + destinations. In log4j speak, an output destination is + called an appender. Currently, appenders exist for the + console, files, GUI components, remote socket servers, JMS, + NT Event Loggers, and remote UNIX Syslog daemons. It is also + possible to log asynchronously. + </p> + <p>More than one appender can be attached to a logger.</p> + <p> + The addAppender method adds an appender to a given logger. + Each enabled logging request for a given logger will be + forwarded to all the appenders in that logger as well as the + appenders higher in the hierarchy. In other words, appenders + are inherited additively from the logger hierarchy. For + example, if a console appender is added to the root logger, + then all enabled logging requests will at least print on the + console. If in addition a file appender is added to a + logger, say C, then enabled logging requests for C and C's + children will print on a file and on the console. It is + possible to override this default behavior so that appender + accumulation is no longer additive by setting the additivity + flag to false. + </p> + <p> + The rules governing appender additivity are summarized + below. + </p> + <div class="definition"> + <div class="deftitle">Appender Additivity</div> + <p> + The output of a log statement of logger + <em>C</em> + will go to all the appenders in + <em>C</em> + and its ancestors. This is the meaning of the term + "appender additivity". + </p> + <p> + However, if an ancestor of logger + <em>C</em> + , say + <em>P</em> + , has the additivity flag set to false, then + <em>C</em> + 's output will be directed to all the appenders in + <em>C</em> + and it's ancestors upto and including + <em>P</em> + but not the appenders in any of the ancestors of + <em>P</em> + . + </p> + <p> + Loggers have their additivity flag set to true by + default. + </p> + </div> + The table below shows an example: + + <table class="bodyTable"> + <tr> + <th>Logger Name</th> + <th>Added Appenders</th> + <th>Additivity Flag</th> + <th>Output Targets</th> + <th>Comment</th> + </tr> + <tr> + <td>root</td> + <td>A1</td> + <td>not applicable</td> + <td>A1</td> + <td> + The root logger is anonymous but can be accessed + with the Logger.getRootLogger() method. There is no + default appender attached to root. + </td> + </tr> + <tr> + <td>x</td> + <td>A-x1, A-x2</td> + <td>true</td> + <td>A1, A-x1, A-x2</td> + <td>Appenders of "x" and root.</td> + </tr> + <tr> + <td>x.y</td> + <td>none</td> + <td>true</td> + <td>A1, A-x1, A-x2</td> + <td>Appenders of "x" and root.</td> + </tr> + <tr> + <td>x.y.z</td> + <td>A-xyz1</td> + <td>true</td> + <td>A1, A-x1, A-x2, A-xyz1</td> + <td>Appenders in "x.y.z", "x" and root.</td> + </tr> + <tr> + <td>security</td> + <td>A-sec</td> + <td class="blue">false</td> + <td>A-sec</td> + <td> + No appender accumulation since the additivity flag + is set to + <code>false</code> + . + </td> + </tr> + <tr> + <td>security.access</td> + <td>none</td> + <td>true</td> + <td>A-sec</td> + <td> + Only appenders of "security" because the additivity + flag in "security" is set to + <code>false</code> + . + </td> + </tr> + </table> + + + <p> + More often than not, users wish to customize not only the + output destination but also the output format. This is + accomplished by associating a + <em>layout</em> + with an appender. The layout is responsible for formatting + the logging request according to the user's wishes, whereas + an appender takes care of sending the formatted output to + its destination. The PatternLayout, part of the standard + log4j distribution, lets the user specify the output format + according to conversion patterns similar to the C language + <code>printf</code> + function. + </p> + <p> + For example, the PatternLayout with the conversion pattern + "%r [%t] %-5p %c - %m%n" will output something akin to: + </p> + + <div class="source"> + 176 [main] INFO org.foo.Bar - Located nearest gas station. + </div> + + <p> + The first field is the number of milliseconds elapsed since + the start of the program. The second field is the thread + making the log request. The third field is the level of the + log statement. The fourth field is the name of the logger + associated with the log request. The text after the '-' is + the message of the statement. + </p> + <p> + Just as importantly, log4j will render the content of the + log message according to user specified criteria. For + example, if you frequently need to log + <code>Oranges</code> + , an object type used in your current project, then you can + register an + <code>OrangeRenderer</code> + that will be invoked whenever an orange needs to be logged. + </p> + <p> + Object rendering follows the class hierarchy. For example, + assuming oranges are fruits, if you register an + <code>FruitRenderer</code> + , all fruits including oranges will be rendered by the + <code>FruitRenderer</code> + , unless of course you registered an orange specific + <code>OrangeRenderer</code> + . + </p> + <p> + Object renderers have to implement the ObjectRenderer + interface. + </p> + + <h4>More sophitsicated ways of logging</h4> + + <p> + If you are a SLF4J user (if not, you should be...), you'll + notice that the methods used to request logging do not only + take a String as a parameter. Some methods allow more + sophisticated parameter configurations. + </p> + + <p> + For some Logger + <code>logger</code> + , writing, + </p> + <div class="source"> + logger.debug("Entry number: " + i + " is " + + String.valueOf(entry[i])); + </div> + + <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> + + <div class="source"> + if(logger.isDebugEnabled()) { + <br /> + logger.debug("Entry number: " + i + " is " + + String.valueOf(entry[i])); + <br /> + } + </div> + + + <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> + + <h4>Better alternative based on format messages</h4> + + <p> + There exists a very convenient alternative based on message + formats. Assuming + <code>entry</code> + is an object, you can write: + </p> + + + <div class="source"> + Object entry = new SomeObject(); + <br /> + logger.debug("The entry is {}.", entry); + </div> + + <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> + + <div class="source"> + logger.debug("The new entry is "+entry+"."); + <br /> + logger.debug("The new entry is {}.", entry); + </div> + + + <p> + A two argument variant is also availalble. For example, you + can write: + </p> + + <div class="source"> + logger.debug("The new entry is {}. It replaces {}.", entry, + oldEntry); + </div> + + <p> + If three or more arguments need to be passed, an + <code>Object[]</code> + variant is also availalble. For example, you can write: + </p> + + + <div class="source"> + logger.debug("Value {} was inserted between {} and {}.", new + Object[] {newVal, below, above}); + </div> + + + + + + + </body> +</document>

1 0

svn commit: r360 - logback/skin/trunk/src/main/resources/css
by noreply.seb＠qos.ch 27 Jul '06

27 Jul '06

Author: seb Date: Thu Jul 27 18:51:13 2006 New Revision: 360 Modified: logback/skin/trunk/src/main/resources/css/site.css Log: added some styles for the docs Modified: logback/skin/trunk/src/main/resources/css/site.css ============================================================================== --- logback/skin/trunk/src/main/resources/css/site.css (original) +++ logback/skin/trunk/src/main/resources/css/site.css Thu Jul 27 18:51:13 2006 @@ -1,183 +1,197 @@ - /* Logback CSS Theme for Maven 2, from LB-Skin */ - body { - margin: 0px; - padding: 0px 0px 10px 0px; + margin: 0px; + padding: 0px 0px 10px 0px; } img { - border:none; + border: none; } acronym { - cursor: help; - border-bottom: 1px dotted #feb; + cursor: help; + border-bottom: 1px dotted #feb; } -div.clear{ - clear:both; - visibility: hidden; +div.clear { + clear: both; + visibility: hidden; } -div.clear hr{ - display: none; + +div.clear hr { + display: none; } -body, td, select, input, li{ - font-family: Verdana, Helvetica, Arial, sans-serif; - font-size: 13px; +body,td,select,input,li { + font-family: Verdana, Helvetica, Arial, sans-serif; + font-size: 13px; } -code{ - font-family: Courier, monospace; - font-size: 13px; + +code { + font-family: Courier, monospace; + font-size: 13px; } a { - text-decoration: none; + text-decoration: none; } + a:link { color: navy; - /*color:#36a;*/ + /*color:#36a;*/ } -a:visited { - /*color:#47a;*/ - color: navy; -} -a:active, a:hover { - /*color:#69c;*/ - color: navy; - text-decoration: underline; + +a:visited { /*color:#47a;*/ + color: navy; } + +a:active,a:hover { /*color:#69c;*/ + color: navy; + text-decoration: underline; +} + #legend li.externalLink { - background: url(../images/external.png) left top no-repeat; - padding-left: 18px; + background: url(../images/external.png) left top no-repeat; + padding-left: 18px; } -a.externalLink, a.externalLink:link, a.externalLink:visited, a.externalLink:active, a.externalLink:hover { - background: url(../images/external.png) right center no-repeat; - padding-right: 18px; + +a.externalLink,a.externalLink:link,a.externalLink:visited,a.externalLink:active,a.externalLink:hover + { + background: url(../images/external.png) right center no-repeat; + padding-right: 18px; } + #legend li.newWindow { - background: url(../images/newwindow.png) left top no-repeat; - padding-left: 18px; + background: url(../images/newwindow.png) left top no-repeat; + padding-left: 18px; } -a.newWindow, a.newWindow:link, a.newWindow:visited, a.newWindow:active, a.newWindow:hover { - background: url(../images/newwindow.png) right center no-repeat; - padding-right: 18px; + +a.newWindow,a.newWindow:link,a.newWindow:visited,a.newWindow:active,a.newWindow:hover + { + background: url(../images/newwindow.png) right center no-repeat; + padding-right: 18px; } h2 { - padding: 4px 4px 2px 0px; - border: 0px solid #999; - color: navy; - /*background-color: #ddd;*/ - /*background-color: rgb(144,223,144);*/ - background-color: white; - font-weight:900; - font-size: x-large; + padding: 4px 4px 2px 0px; + border: 0px solid #999; + color: navy; + /*background-color: #ddd;*/ /*background-color: rgb(144,223,144);*/ + background-color: white; + font-weight: 900; + font-size: x-large; } + h3 { - padding: 4px 4px 4px 0px; - border: 0px solid #aaa; - /*color: #900;*/ - color: navy; - /*background-color: #eee;*/ - background-color: white; - font-weight: normal; - font-size: large; + padding: 4px 4px 4px 0px; + border: 0px solid #aaa; + /*color: #900;*/ + color: navy; + /*background-color: #eee;*/ + background-color: white; + font-weight: normal; + font-size: large; } + h4 { - padding: 4px 4px 4px 0px; - border: 0px solid #bbb; - /*color: #900;*/ - color: navy; - background-color: white; - font-weight: normal; - font-size: large; + padding: 4px 4px 4px 0px; + border: 0px solid #bbb; + /*color: #900;*/ + color: navy; + background-color: white; + font-weight: normal; + font-size: large; } + h5 { - padding: 4px 4px 4px 6px; - color: #900; - font-size: normal; + padding: 4px 4px 4px 6px; + color: #900; + font-size: normal; } + p { - line-height: 1.3em; - font-size: small; + line-height: 1.3em; + font-size: small; } - -#bannerLeft, #bannerRight { - font-size: xx-large; - font-weight: bold; +#bannerLeft,#bannerRight { + font-size: xx-large; + font-weight: bold; } -#bannerLeft img, #bannerRight img { - margin: 0px; + +#bannerLeft img,#bannerRight img { + margin: 0px; } -.xleft, #bannerLeft img { - float:left; - text-shadow: #7CFC00; + +.xleft,#bannerLeft img { + float: left; + text-shadow: #7CFC00; } -.xright, #bannerRight img { - float:right; - text-shadow: #7CFC00; + +.xright,#bannerRight img { + float: right; + text-shadow: #7CFC00; } #breadcrumbs { - padding: 3px 10px 3px 10px; - font-size:small; - border: 1px solid #663300; - /*border-bottom: 1px solid #aaa; + padding: 3px 10px 3px 10px; + font-size: small; + border: 1px solid #663300; + /*border-bottom: 1px solid #aaa; /* background-color: #ccc; lime; border-color: #663300;*/ - background-color: #ffd0a0; - max-width: 77em; + background-color: #ffd0a0; + max-width: 77em; } + #leftColumn { - margin: 10px 0 0 5px; - border: 1px solid #999; - /*background-color: #eee;*/ - /*background-color: rgb(144,223,144);*/ - background-color: #ddd; - width: 15em; /* was: 170/190 */ - float:left; - overflow: auto; + margin: 10px 0 0 5px; + border: 1px solid #999; + /*background-color: #eee;*/ /*background-color: rgb(144,223,144);*/ + background-color: #ddd; + width: 15em; /* was: 170/190 */ + float: left; + overflow: auto; } + #navcolumn h5 { - margin: 0; - font-size: small; - border-bottom: 1px solid #aaaaaa; - padding-top: 2px; - color: #000; + margin: 0; + font-size: small; + border-bottom: 1px solid #aaaaaa; + padding-top: 2px; + color: #000; } #bodyColumn { - max-width: 60em; - margin-right: 1.5em; - margin-left: 217px;/*was: 197*/ + max-width: 60em; + margin-right: 1.5em; + margin-left: 217px; /*was: 197*/ } + #legend { - padding: 8px 0 8px 0; + padding: 8px 0 8px 0; } #navcolumn ul { - padding: 8px 4px 0 8px; + padding: 8px 4px 0 8px; margin: 5px; - padding: 0; - font-size: medium; - /*font-weight:bold;*/ + padding: 0; + font-size: medium; + /*font-weight:bold;*/ } #navcolumn li { - line-height:150%; - list-style-type: none; - background-image: none; - background-repeat: no-repeat; - background-position: 0 0.4em; - padding-left: 16px; - list-style-position: outside; - font-size: smaller; - /*background: #EEEEEE; + line-height: 150%; + list-style-type: none; + background-image: none; + background-repeat: no-repeat; + background-position: 0 0.4em; + padding-left: 16px; + list-style-position: outside; + font-size: smaller; + /*background: #EEEEEE; padding-left: 2ex; border-top: 0px solid #AAAAAA; border-right: 1px solid #AAAAAA; @@ -186,12 +200,12 @@ } #navcolumn img { - margin-top: 10px; - margin-bottom: 3px; + margin-top: 10px; + margin-bottom: 3px; } #lastPublished { - font-size: x-small; + font-size: x-small; } strong { @@ -201,103 +215,149 @@ } table { - padding:0px; - width: 100%; - margin-left: -2px; - margin-right: -2px; + padding: 0px; + width: 100%; + margin-left: -2px; + margin-right: -2px; } table.bodyTable th { - color: white; - background-color: #bbb; - text-align: left; - font-weight: bold; + color: white; + background-color: #bbb; + text-align: left; + font-weight: bold; } -table.bodyTable th, table.bodyTable td { - font-size: 1em; +table.bodyTable th,table.bodyTable td { + font-size: 1em; } table.bodyTable tr.a { - background-color: #ddd; + background-color: #ddd; } table.bodyTable tr.b { - background-color: #eee; + background-color: #eee; } .source { - border: 1px solid #999; - font-family: Courier, monospace; - padding: 12px; - margin: 1em 7px 1em 7px; + border: 1px solid #999; + font-family: Courier, monospace; + padding: 12px; + margin: 1em 7px 1em 7px; } .source pre { - margin: 0px; - padding: 0px; + margin: 0px; + padding: 0px; } .navSectionHead { - font-weight: bold; - font-size: x-small; + font-weight: bold; + font-size: x-small; } .section { - padding: 4px; + padding: 4px; } #footer { - padding: 3px 10px 3px 10px; - font-size: x-small; + padding: 3px 10px 3px 10px; + font-size: x-small; } dl { - padding: 4px 4px 4px 6px; - border: 1px solid #aaa; - background-color: #ffc; + padding: 4px 4px 4px 6px; + border: 1px solid #aaa; + background-color: #ffc; } + dt { - color: #900; + color: #900; } -#organizationLogo img, #projectLogo img, #projectLogo span{ - margin: 8px; + +#organizationLogo img,#projectLogo img,#projectLogo span { + margin: 8px; } #banner { - padding: 0px; - border-bottom: 1px solid #fff; + padding: 0px; + border-bottom: 1px solid #fff; } + #banner img { - border: none; + border: none; } #poweredBy { - text-align: center; + text-align: center; } #poweredBy img { - display:block; - margin: 20px 0 20px 17px; - border: none; - width: 90px; - height: 30px; + display: block; + margin: 20px 0 20px 17px; + border: none; + width: 90px; + height: 30px; } - -.errormark, .warningmark, .donemark, .infomark { - background: url(../images/icon_error_sml.gif) no-repeat; +.errormark,.warningmark,.donemark,.infomark { + background: url(../images/icon_error_sml.gif) no-repeat; } .warningmark { - background-image: url(../images/icon_warning_sml.gif); + background-image: url(../images/icon_warning_sml.gif); } .donemark { - background-image: url(../images/icon_success_sml.gif); + background-image: url(../images/icon_success_sml.gif); } .infomark { - background-image: url(../images/icon_info_sml.gif); + background-image: url(../images/icon_info_sml.gif); +} + +/* + + Logback documentation styles + +*/ +.author { + text-align: left; + font-weight: bold; +} + +.definition { + padding-left: 5px; + padding-right: 5px; + margin: 5px 50px 5px 50px; + text-align: justify; + background-color: #E6E64C; +} + +.deftitle { + font-weight: bold; +} + +.progWord{ + font-family: Courier, monospace; +} + +table.exampleTable { + width: 50%; + +} +table.exampleTable th { + color: white; + background-color: #bbb; + text-align: left; + font-weight: bold; +} + +.green { + color: green; +} +.blue { + color: blue; }

1 0

svn commit: r359 - logback/core/trunk/src/site/xdocTemplates
by noreply.seb＠qos.ch 26 Jul '06

26 Jul '06

Author: seb Date: Wed Jul 26 21:24:58 2006 New Revision: 359 Modified: logback/core/trunk/src/site/xdocTemplates/index.xml Log: correct url Modified: logback/core/trunk/src/site/xdocTemplates/index.xml ============================================================================== --- logback/core/trunk/src/site/xdocTemplates/index.xml (original) +++ logback/core/trunk/src/site/xdocTemplates/index.xml Wed Jul 26 21:24:58 2006 @@ -18,8 +18,8 @@ </p> <p> - The core module lays the groundwork for the <a href="classic/">Classic</a> and - <a href="access/">Access</a> modules. Logback core defines the concepts of + The core module lays the groundwork for the <a href="../classic/">Classic</a> and + <a href="../access/">Access</a> modules. Logback core defines the concepts of Context, Status and StatusManager, Appender, Layout and Filter. The logback Context acts as a store to logback components. It is the core of the logging library Components

1 0