You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2006/05/02 00:29:20 UTC
Re: svn commit: r398696 - in
/jakarta/commons/proper/logging/trunk/xdocs: guide.xml tech.xml
troubleshooting.xml
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