You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-cvs@jakarta.apache.org by ce...@apache.org on 2002/02/17 22:52:24 UTC
cvs commit: jakarta-log4j/docs HISTORY TROUBLESHOOT.html
ceki 02/02/17 13:52:24
Modified: docs HISTORY TROUBLESHOOT.html
Log:
minor additions.
Revision Changes Path
1.83 +8 -0 jakarta-log4j/docs/HISTORY
Index: HISTORY
===================================================================
RCS file: /home/cvs/jakarta-log4j/docs/HISTORY,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -r1.82 -r1.83
--- HISTORY 11 Feb 2002 16:14:32 -0000 1.82
+++ HISTORY 17 Feb 2002 21:52:24 -0000 1.83
@@ -9,6 +9,14 @@
- Release of version 1.2
+ (beta3)
+
+ - Fixed the complaints the compiler issued when using the
+ Logger.setLevel() methd. [*]
+
+ - Incorporated the performance enhancements to ISO8601DateFormat and
+ AbsoluteTimeDateFormat classes submitted by Andrew Vajoczki.
+
(beta2)
- Source code written for log4j 1.1.3.jar will compile fine with
1.13 +97 -86 jakarta-log4j/docs/TROUBLESHOOT.html
Index: TROUBLESHOOT.html
===================================================================
RCS file: /home/cvs/jakarta-log4j/docs/TROUBLESHOOT.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- TROUBLESHOOT.html 11 Feb 2002 22:20:30 -0000 1.12
+++ TROUBLESHOOT.html 17 Feb 2002 21:52:24 -0000 1.13
@@ -33,7 +33,6 @@
</p>
</li>
- <li><p><a href=#levelCast>Compilation errors when using<code>setLevel(org.apache.log4j.Level)</code> from the Category class.</a></p></li>
<li><p><a href="#notfound">My EJB-Servlet-JSP says log4j class
not found or not defined.</a> </a></p>
@@ -68,90 +67,96 @@
achieved by attaching an appender to the root category.</p>
- <p><a name=duplicates><h3>Duplicates in log4j output.</h3>
+ <p><a name=duplicates></a><h3>Duplicates in log4j output.</h3></p>
-<p>The reason for observing duplicates in log4j output is either due
-to having added the same appender multiple times to the same category
-(typically root) or having added the same appender to different
-categories ignoring the fact that appenders are inherited
-cumulatively.</p>
-
-<p>log4j does not eliminate appender duplicates. In other words, if
-you add the same appender to a category <i>n</i> times, that appender
-will be invoked <i>n</i> times to append to its target. </p>
-
-<p>A slightly different cause is adding different appenders all
-sharing the same underlying output target to some category. In the
-most common occurrence of this phenomenon, the
-BasicConfigurator.configure() method is invoked multiple times. Each
-time it is invoked, this method adds an appender with a
-<code>System.out</code> target to the root category. </p>
-
-<p>One other common mistake is to forget that appenders are inherited
-cumulatively from the hierarchy. For example, if you add an appender,
-say <code>A</code>, to the root category, all other categories will
-inherit <code>A</code> as an appender. Thus, if you add <code>A</code>
-to a category, say <code>C</code>, then an enabled statement of
-category <code>C</code>, will print to <code>A</code> twice, once
-because <code>A</code> is in root and once because it is in
-<code>C</code>. </p>
-
-<p><a name=space></a><h3>Options are not parsed correctly.</h3>
-
-<p>The PropertyConfigurator relies on <code>java.util.Properties</code>
-class to read in the configuration file. This class preserves spaces
-in options. For example,</p>
+ <p>The reason for observing duplicates in log4j output is
+ either due to having added the same appender multiple times
+ to the same category (typically root) or having added the
+ same appender to different categories ignoring the fact that
+ appenders are inherited cumulatively.</p>
+
+ <p>log4j does not eliminate appender duplicates. In other
+ words, if you add the same appender to a category <i>n</i>
+ times, that appender will be invoked <i>n</i> times to
+ append to its target. </p>
+
+ <p>A slightly different cause is adding different appenders
+ all sharing the same underlying output target to some
+ category. In the most common occurrence of this phenomenon,
+ the BasicConfigurator.configure() method is invoked multiple
+ times. Each time it is invoked, this method adds an appender
+ with a <code>System.out</code> target to the root
+ category. </p>
+
+ <p>One other common mistake is to forget that appenders are
+ inherited cumulatively from the hierarchy. For example, if
+ you add an appender, say <code>A</code>, to the root
+ category, all other categories will inherit <code>A</code>
+ as an appender. Thus, if you add <code>A</code> to a
+ category, say <code>C</code>, then an enabled statement of
+ category <code>C</code>, will print to <code>A</code> twice,
+ once because <code>A</code> is in root and once because it
+ is in <code>C</code>. </p>
+
+ <p><a name=space></a><h3>Options are not parsed correctly.</h3>
+
+ <p>The PropertyConfigurator relies on
+ <code>java.util.Properties</code> class to read in the
+ configuration file. This class preserves spaces in
+ options. For example,</p>
<pre>
fruit=orange
</pre>
is returned as an option having the key <code>"fruit"</code> and the
-value <code>"orange "</code>.</p>
+ value <code>"orange "</code>.</p>
-<p>The spaces in the value, i.e. <code>"orange "</code>, are due to
-invisible spaces at the end of the example shown above. Thus, some of
-the options might not be interpreted correctly due to trailing
-spaces. </p>
-
-<p><a name=jit></a><h3>Caller location information is printed as a "?"
-character.</h3>
-
-Location information is extracted automatically by the PatternLayout
-conversion patterns %C, %F, %M and %L. However, some just-in-time
-(JIT) compilers make it impossible to extract location information. It
-is also possible that the compiler that generated the byte code may
-have omitted the LineNumber table as is done by -O option of javac
-and jikes. </p>
+ <p>The spaces in the value, i.e. <code>"orange "</code>, are due to
+ invisible spaces at the end of the example shown above. Thus, some of
+ the options might not be interpreted correctly due to trailing
+ spaces. </p>
+
+ <p><a name=jit></a><h3>Caller location information is printed as a "?"
+ character.</h3>
+
+ Location information is extracted automatically by the PatternLayout
+ conversion patterns %C, %F, %M and %L. However, some just-in-time
+ (JIT) compilers make it impossible to extract location information. It
+ is also possible that the compiler that generated the byte code may
+ have omitted the LineNumber table as is done by -O option of javac
+ and jikes. </p>
-<p>You can remedy this problem by disabling the JIT compiler and by
-compiling the code without the -O option.</p>
-
-<p><b>In wrappers or subclasses of Category </b>
+ <p>You can remedy this problem by disabling the JIT compiler and by
+ compiling the code without the -O option.</p>
+
+ <p><b>In wrappers or subclasses of Category </b>
-<p>Wrappers or subclasses of <code>Category</code> need supply their
-fully qualified class name to the <code>Category.log</code> method or
+ <p>Wrappers or subclasses of <code>Category</code> need supply their
+ fully qualified class name to the <code>Category.log</code> method or
to <code>Category.forcedLog</code> methods so that the caller location
information can be extracted correctly.</p>
-<p>This approach will work correctly in all cases except if the class
-invoking the extended category instance has the same prefix as the
-extended category class. For example, calling an instance of
-<code>com.foo.BarCategory</code> from the
-<code>com.foo.BarCategoryTest</code> class will not yield the correct
-caller information. To circumvent this "bug", either perform the tests
-from a class with a different name or add a dot to the fully qualified
-name of the extending class that you supply to
-<code>Category.log</code> to <code>Category.forcedLog</code>
-methods. For the <code>com.foo.BarCategory</code> example, supply the
-string <code>"com.foo.BarCategory."</code>.</p>
+ <p>This approach will work correctly in all cases except if
+ the class invoking the extended category instance has the
+ same prefix as the extended category class. For example,
+ calling an instance of <code>com.foo.BarCategory</code>
+ from the <code>com.foo.BarCategoryTest</code> class will
+ not yield the correct caller information. To circumvent
+ this "bug", either perform the tests from a class with a
+ different name or add a dot to the fully qualified name of
+ the extending class that you supply to
+ <code>Category.log</code> to
+ <code>Category.forcedLog</code> methods. For the
+ <code>com.foo.BarCategory</code> example, supply the
+ string <code>"com.foo.BarCategory."</code>.</p>
-<p><a name=cce><h3><code>ClassCastException</code> when instantiating
-a <code>Category</code> subclasses.</a></h3>
+ <p><a name=cce><h3><code>ClassCastException</code> when
+instantiating a <code>Category</code> subclasses.</a></h3>
-<p>This exception is thrown because log4j does not support
+ <p>This exception is thrown because log4j does not support
homonyms. For example, the following will systematically throw a
-<code>ClassCastException</code>
+<code>ClassCastException</code></p>
<pre>
Category c1 = Category.getInstance("bad");
@@ -162,23 +167,27 @@
<code>Category</code>. The problem occurs because the second
<code>getInstance</code> invocation will retrieve the category created
in the fist invocation. This instance is a <code>Category</code>
-object and cannot be cast to <code>MyCategory</code>.
- </p>
-<p>By default, the <code>PropertyConfigurator</code> will create and
-configure <code>org.apache.log4j.Category</code> objects. Thus, if you try to
-instantiate a category subclass for an already existing category, and
-try to cast it to the subclass type, you will systematically get a
-<code>ClassCastException</code>.</p>
-
-<p>To address this problem, the <code>PropertyConfigurator</code> admits
-the <code>log4j.categoryFactory</code> key. The value of this key will
-be used as the factory to invoke when instantiating Category objects.
+object and cannot be cast to <code>MyCategory</code>.</p>
+
+ <p>By default, the <code>PropertyConfigurator</code> will
+ create and configure
+ <code>org.apache.log4j.Category</code> objects. Thus, if
+ you try to instantiate a category subclass for an already
+ existing category, and try to cast it to the subclass
+ type, you will systematically get a
+ <code>ClassCastException</code>.</p>
+
+ <p>To address this problem, the
+ <code>PropertyConfigurator</code> admits the
+ <code>log4j.categoryFactory</code> key. The value of this
+ key will be used as the factory to invoke when
+ instantiating Category objects.
-<p>The <code>DOMConfigurator</code> has a finer grain method for
-setting the class of the category object to instantiate.
+ <p>The <code>DOMConfigurator</code> has a finer grain
+ method for setting the class of the category object to instantiate.
-<a name="#levelCast"><h3>Compilation errors when using <code>setLevel(org.apache.log4j.Level)</code> from the Category class.</h3>
+<!-- <a name="#levelCast"><h3>Compilation errors when using <code>setLevel(org.apache.log4j.Level)</code> from the Category class.</h3>
<p>If you try to call the setLevel method with one of the built in
levels, the java compiler with complain:
@@ -194,11 +203,13 @@
happy. As in <pre> logger.setLevel(<b>(Level)</b> Level.DEBUG);
</pre>
-<p>This cast is always safe because log4j 1.2 will never produce
+ <p>This cast is always safe because log4j 1.2 will never produce
anything but <code>Level</code> objects, never <code>Priority</code>
-objects. </p>
-
+objects. Surprisingly enough this cast was not necessary in log4j 1.2
+alpha. It is required in 1.2 beta and later to ensure runtime
+compatibility with log4j 1.1.3.</p>
+-->
<p><a name=notfound><h3>Log4j class not found/defined</h3>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>