You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by de...@apache.org on 2006/05/01 23:39:38 UTC
svn commit: r398696 - in /jakarta/commons/proper/logging/trunk/xdocs:
guide.xml tech.xml troubleshooting.xml
Author: dennisl
Date: Mon May 1 14:39:36 2006
New Revision: 398696
URL: http://svn.apache.org/viewcvs?rev=398696&view=rev
Log:
Correct spelling.
Modified:
jakarta/commons/proper/logging/trunk/xdocs/guide.xml
jakarta/commons/proper/logging/trunk/xdocs/tech.xml
jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml
Modified: jakarta/commons/proper/logging/trunk/xdocs/guide.xml
URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/guide.xml?rev=398696&r1=398695&r2=398696&view=diff
==============================================================================
--- jakarta/commons/proper/logging/trunk/xdocs/guide.xml (original)
+++ jakarta/commons/proper/logging/trunk/xdocs/guide.xml Mon May 1 14:39:36 2006
@@ -344,7 +344,7 @@
</subsection>
<subsection name="Serialization Issues">
<p>Prior to release 1.0.4, none of the standard Log implementations were
- Serializable. If you are using such a release and have a Serializable classe
+ Serializable. If you are using such a release and have a Serializable class
with a member that is of type Log then it is necessary to declare
that member to be transient and to ensure that the value is restored on
deserialization. The recommended approach is to define a custom
Modified: jakarta/commons/proper/logging/trunk/xdocs/tech.xml
URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/tech.xml?rev=398696&r1=398695&r2=398696&view=diff
==============================================================================
--- jakarta/commons/proper/logging/trunk/xdocs/tech.xml (original)
+++ jakarta/commons/proper/logging/trunk/xdocs/tech.xml Mon May 1 14:39:36 2006
@@ -173,12 +173,12 @@
This guide is aimed at describing the technologies that JCL developers and expert users
(and users who need to become experts)
should be familiar with. The aim is to give an understanding whilst being precise but brief.
- Details which are not relevent for JCL have been suppressed.
+ Details which are not relevant for JCL have been suppressed.
References have been included.
</p>
<p>
- These topics are a little difficult and it's easy for even experience developers to make
- mistakea. We need you to help us get it right! Please submit corrections, comments, additional references
+ These topics are a little difficult and it's easy for even experienced developers to make
+ mistakes. We need you to help us get it right! Please submit corrections, comments, additional references
and requests for clarification
by either:
</p>
@@ -356,7 +356,7 @@
<a href='http://java.sun.com/docs/books/vmspec/'>VMSpec</a> <em>The Java Virtual Machine Specification, Second Edition</em>
</li>
<li>
- <a href='http://java.sun.com/docs/books/jls/'>LangSpec</a> <em>The Java Language Specification Second Edition</em>
+ <a href='http://java.sun.com/docs/books/jls/'>LangSpec</a> <em>The Java Language Specification, Second Edition</em>
</li>
</ul>
</subsection>
@@ -387,7 +387,7 @@
<p>
<strong>Note:</strong> the term child-first (though commonly used) is misleading.
A better term (and one which may be encountered on the mailing list) is parent-last.
- This more accurately describes the actual process of classloader performed
+ This more accurately describes the actual process of classloading performed
by such a classloader.
</p>
<p>
@@ -448,14 +448,14 @@
<code>Thread.setContextClassLoader</code></a> emphasizes the setting of the
context classloader as an aspect of thread creation. However, in many
applications the context classloader is not fixed at thread creation but
- rather is changed throughout the life of thread as thread execution moves
+ rather is changed throughout the life of a thread as thread execution moves
from one context to another. This usage of the context classloader is
particularly important in container applications.
</p>
<p>
For example, in a hypothetical servlet container, a pool of threads
is created to handle HTTP requests. When created these threads have their
- context classloader set to a classloader that loads container classes.
+ context classloader set to a classloader that loads container classes.
After the thread is assigned to handle a request, container code parses
the request and then determines which of the deployed web applications
should handle it. Only when the container is about to call code associated
Modified: jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml
URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml?rev=398696&r1=398695&r2=398696&view=diff
==============================================================================
--- jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml (original)
+++ jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml Mon May 1 14:39:36 2006
@@ -37,8 +37,8 @@
<p>
Diagnostics is a feature introduced in JCL 1.1 as an aid to debugging problems
with JCL configurations. When diagnostics are switched on, messages are logged
-to a stream (specified by the user) by the two main class involved in discovery
-JCL (<code>LogFactory</code> and <code>LogFactoryImpl</code>).
+to a stream (specified by the user) by the two main classes involved in discovery
+in JCL (<code>LogFactory</code> and <code>LogFactoryImpl</code>).
</p>
<p>
Diagnostics are intended to be used in conjunction with the source. The source
@@ -74,7 +74,7 @@
The <em>system identity hash code</em> is found by calling <code>System.identityHashCode()</code>
which should uniquely identify a particular instance. The classname is usually the fully qualified
class name though in a few cases, <code>org.apache.commons.logging.impl.LogFactoryImpl</code> may be
-shorten to <code>LogFactoryImpl</code> to increase ease of reading. For example:
+shortened to <code>LogFactoryImpl</code> to increase ease of reading. For example:
</p>
<code><pre>
sun.misc.Launcher$AppClassLoader@20120943
@@ -176,11 +176,11 @@
for each diagnostic message logged by this process.
</p>
<p>
-The implementation used can vary per Thread context classloader (TCCL). If this the first time
+The implementation used can vary per Thread context classloader (TCCL). If this is the first time
that a Log has been requested for a particular TCCL a new instance will be created.
</p>
<p>
-Information of particular interest is logged at this stage. Details of the TCCL are logging
+Information of particular interest is logged at this stage. Details of the TCCL are logged
allowing the <a href='#OIDs'>OID</a> later to be cross-referenced to the <code>toString</code> value
and the <a href='#ClassLoader%20Hierarchy%20Tree'>classloader tree</a>. For example, the
following log snippet details the TCCL (lines split):
@@ -282,7 +282,7 @@
the two <code>LogFactory</code> Class instances are not equal and so the cast must fail.
</p>
<p>
-The policy adopted by JCL in this situation is to re-throw this exception. Addition information
+The policy adopted by JCL in this situation is to re-throw this exception. Additional information
is included in the message to help diagnosis. The reasoning behind this choice is that a
particular <code>LogFactory</code> implementation has been actively specified and this
choice should not be ignored. This policy has unfortunate consequences when running in
@@ -316,7 +316,7 @@
the most modern release
</li>
<li>
- Replace the commons-logging jar in the application with the commons-logging-adapter jar.
+ Replace the commons-logging jar in the application with the commons-logging-adapters jar.
This will ensure that application classloader will delegate to it's parent when loading
<code>LogFactory</code>.
</li>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: svn commit: r398696 - in
/jakarta/commons/proper/logging/trunk/xdocs: guide.xml tech.xml
troubleshooting.xml
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
thanks :)
- robert
On Mon, 2006-05-01 at 21:39 +0000, dennisl@apache.org wrote:
> Author: dennisl
> Date: Mon May 1 14:39:36 2006
> New Revision: 398696
>
> URL: http://svn.apache.org/viewcvs?rev=398696&view=rev
> Log:
> Correct spelling.
>
> Modified:
> jakarta/commons/proper/logging/trunk/xdocs/guide.xml
> jakarta/commons/proper/logging/trunk/xdocs/tech.xml
> jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml
>
> Modified: jakarta/commons/proper/logging/trunk/xdocs/guide.xml
> URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/guide.xml?rev=398696&r1=398695&r2=398696&view=diff
> ==============================================================================
> --- jakarta/commons/proper/logging/trunk/xdocs/guide.xml (original)
> +++ jakarta/commons/proper/logging/trunk/xdocs/guide.xml Mon May 1 14:39:36 2006
> @@ -344,7 +344,7 @@
> </subsection>
> <subsection name="Serialization Issues">
> <p>Prior to release 1.0.4, none of the standard Log implementations were
> - Serializable. If you are using such a release and have a Serializable classe
> + Serializable. If you are using such a release and have a Serializable class
> with a member that is of type Log then it is necessary to declare
> that member to be transient and to ensure that the value is restored on
> deserialization. The recommended approach is to define a custom
>
> Modified: jakarta/commons/proper/logging/trunk/xdocs/tech.xml
> URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/tech.xml?rev=398696&r1=398695&r2=398696&view=diff
> ==============================================================================
> --- jakarta/commons/proper/logging/trunk/xdocs/tech.xml (original)
> +++ jakarta/commons/proper/logging/trunk/xdocs/tech.xml Mon May 1 14:39:36 2006
> @@ -173,12 +173,12 @@
> This guide is aimed at describing the technologies that JCL developers and expert users
> (and users who need to become experts)
> should be familiar with. The aim is to give an understanding whilst being precise but brief.
> - Details which are not relevent for JCL have been suppressed.
> + Details which are not relevant for JCL have been suppressed.
> References have been included.
> </p>
> <p>
> - These topics are a little difficult and it's easy for even experience developers to make
> - mistakea. We need you to help us get it right! Please submit corrections, comments, additional references
> + These topics are a little difficult and it's easy for even experienced developers to make
> + mistakes. We need you to help us get it right! Please submit corrections, comments, additional references
> and requests for clarification
> by either:
> </p>
> @@ -356,7 +356,7 @@
> <a href='http://java.sun.com/docs/books/vmspec/'>VMSpec</a> <em>The Java Virtual Machine Specification, Second Edition</em>
> </li>
> <li>
> - <a href='http://java.sun.com/docs/books/jls/'>LangSpec</a> <em>The Java Language Specification Second Edition</em>
> + <a href='http://java.sun.com/docs/books/jls/'>LangSpec</a> <em>The Java Language Specification, Second Edition</em>
> </li>
> </ul>
> </subsection>
> @@ -387,7 +387,7 @@
> <p>
> <strong>Note:</strong> the term child-first (though commonly used) is misleading.
> A better term (and one which may be encountered on the mailing list) is parent-last.
> - This more accurately describes the actual process of classloader performed
> + This more accurately describes the actual process of classloading performed
> by such a classloader.
> </p>
> <p>
> @@ -448,14 +448,14 @@
> <code>Thread.setContextClassLoader</code></a> emphasizes the setting of the
> context classloader as an aspect of thread creation. However, in many
> applications the context classloader is not fixed at thread creation but
> - rather is changed throughout the life of thread as thread execution moves
> + rather is changed throughout the life of a thread as thread execution moves
> from one context to another. This usage of the context classloader is
> particularly important in container applications.
> </p>
> <p>
> For example, in a hypothetical servlet container, a pool of threads
> is created to handle HTTP requests. When created these threads have their
> - context classloader set to a classloader that loads container classes.
> + context classloader set to a classloader that loads container classes.
> After the thread is assigned to handle a request, container code parses
> the request and then determines which of the deployed web applications
> should handle it. Only when the container is about to call code associated
>
> Modified: jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml
> URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml?rev=398696&r1=398695&r2=398696&view=diff
> ==============================================================================
> --- jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml (original)
> +++ jakarta/commons/proper/logging/trunk/xdocs/troubleshooting.xml Mon May 1 14:39:36 2006
> @@ -37,8 +37,8 @@
> <p>
> Diagnostics is a feature introduced in JCL 1.1 as an aid to debugging problems
> with JCL configurations. When diagnostics are switched on, messages are logged
> -to a stream (specified by the user) by the two main class involved in discovery
> -JCL (<code>LogFactory</code> and <code>LogFactoryImpl</code>).
> +to a stream (specified by the user) by the two main classes involved in discovery
> +in JCL (<code>LogFactory</code> and <code>LogFactoryImpl</code>).
> </p>
> <p>
> Diagnostics are intended to be used in conjunction with the source. The source
> @@ -74,7 +74,7 @@
> The <em>system identity hash code</em> is found by calling <code>System.identityHashCode()</code>
> which should uniquely identify a particular instance. The classname is usually the fully qualified
> class name though in a few cases, <code>org.apache.commons.logging.impl.LogFactoryImpl</code> may be
> -shorten to <code>LogFactoryImpl</code> to increase ease of reading. For example:
> +shortened to <code>LogFactoryImpl</code> to increase ease of reading. For example:
> </p>
> <code><pre>
> sun.misc.Launcher$AppClassLoader@20120943
> @@ -176,11 +176,11 @@
> for each diagnostic message logged by this process.
> </p>
> <p>
> -The implementation used can vary per Thread context classloader (TCCL). If this the first time
> +The implementation used can vary per Thread context classloader (TCCL). If this is the first time
> that a Log has been requested for a particular TCCL a new instance will be created.
> </p>
> <p>
> -Information of particular interest is logged at this stage. Details of the TCCL are logging
> +Information of particular interest is logged at this stage. Details of the TCCL are logged
> allowing the <a href='#OIDs'>OID</a> later to be cross-referenced to the <code>toString</code> value
> and the <a href='#ClassLoader%20Hierarchy%20Tree'>classloader tree</a>. For example, the
> following log snippet details the TCCL (lines split):
> @@ -282,7 +282,7 @@
> the two <code>LogFactory</code> Class instances are not equal and so the cast must fail.
> </p>
> <p>
> -The policy adopted by JCL in this situation is to re-throw this exception. Addition information
> +The policy adopted by JCL in this situation is to re-throw this exception. Additional information
> is included in the message to help diagnosis. The reasoning behind this choice is that a
> particular <code>LogFactory</code> implementation has been actively specified and this
> choice should not be ignored. This policy has unfortunate consequences when running in
> @@ -316,7 +316,7 @@
> the most modern release
> </li>
> <li>
> - Replace the commons-logging jar in the application with the commons-logging-adapter jar.
> + Replace the commons-logging jar in the application with the commons-logging-adapters jar.
> This will ensure that application classloader will delegate to it's parent when loading
> <code>LogFactory</code>.
> </li>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org