thanks :)

- robert

On Mon, 2006-05-01 at 21:39 +0000, [EMAIL PROTECTED] 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>
>  [EMAIL PROTECTED]
> @@ -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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to