commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From t.@apache.org
Subject svn commit: r1432710 - in /commons/proper/logging/trunk/src/site/xdoc: guide.xml tech.xml troubleshooting.xml
Date Sun, 13 Jan 2013 19:22:06 GMT
Author: tn
Date: Sun Jan 13 19:22:05 2013
New Revision: 1432710

URL: http://svn.apache.org/viewvc?rev=1432710&view=rev
Log:
Fix a few typos in the user/tech guides.

Modified:
    commons/proper/logging/trunk/src/site/xdoc/guide.xml
    commons/proper/logging/trunk/src/site/xdoc/tech.xml
    commons/proper/logging/trunk/src/site/xdoc/troubleshooting.xml

Modified: commons/proper/logging/trunk/src/site/xdoc/guide.xml
URL: http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/site/xdoc/guide.xml?rev=1432710&r1=1432709&r2=1432710&view=diff
==============================================================================
--- commons/proper/logging/trunk/src/site/xdoc/guide.xml (original)
+++ commons/proper/logging/trunk/src/site/xdoc/guide.xml Sun Jan 13 19:22:05 2013
@@ -386,7 +386,7 @@ In addition to the logging methods, the 
     <subsection name="commons-logging.jar">
       <p>
 The <code>commons-logging.jar</code> file includes the JCL API, the default 
-<code>LogFactory</code> implemenation and thin-wrapper <code>Log</code>

+<code>LogFactory</code> implementation and thin-wrapper <code>Log</code>

 implementations for
 <a href="http://logging.apache.org/log4j/docs/index.html">Log4J</a>,
 <a href="http://avalon.apache.org/logkit/index.html">Avalon LogKit</a>,
@@ -550,7 +550,7 @@ API's for utility functions and tools sh
 if they are caught at all by internal code.
 <br/>
 For higher level frameworks and middleware components,
-these exceptions should be caught immediatly prior to crossing
+these exceptions should be caught immediately prior to crossing
 the API/SPI interface back to user code-space,
 logged with full stack trace at <b>info</b> level,
 and rethrown.
@@ -685,7 +685,7 @@ prior to 1.3 the code defaults to a stan
             </p>
             <p>
 If a custom LogFactory implementation is used, however, then a
-<code>WeakHashtable</code> alone can be insufficent to allow garbage collection
+<code>WeakHashtable</code> alone can be insufficient to allow garbage collection
 of a classloader without a call to <code>release</code>.  If the abstract class
 <code>LogFactory</code> is loaded by a parent classloader and a concrete
 subclass implementation of <code>LogFactory</code> is loaded by a child

Modified: commons/proper/logging/trunk/src/site/xdoc/tech.xml
URL: http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/site/xdoc/tech.xml?rev=1432710&r1=1432709&r2=1432710&view=diff
==============================================================================
--- commons/proper/logging/trunk/src/site/xdoc/tech.xml (original)
+++ commons/proper/logging/trunk/src/site/xdoc/tech.xml Sun Jan 13 19:22:05 2013
@@ -200,11 +200,11 @@ limitations under the License.
       <p>
   This is intended to present a guide to the process by which Java bytecode uses bytecode
in other classes
   from the perspective of the language and virtual machine specifications. The focus will
be on deciding
-  which bytecode will be used (rather than the mechanics of the usage). It focusses on facts
and terminology.
+  which bytecode will be used (rather than the mechanics of the usage). It focuses on facts
and terminology.
       </p>
       <p>
   The process is recursive: it is therefore difficult to pick a starting point.
-  Sun's documentation starts from the persective of the startup of a new application.
+  Sun's documentation starts from the perspective of the startup of a new application.
   This guide starts from the perspective of an executing application.
       </p>
       <p>
@@ -304,7 +304,7 @@ limitations under the License.
       <p>
         <em>
   In practical development terms: The System classloader returned by <code>Classloader.getSystemClassLoader()</code>
-  will be either the bootstrap classloader or a direct descendent of the bootstrap classloader.
+  will be either the bootstrap classloader or a direct descendant of the bootstrap classloader.
   Only when debugging issues concerning the system classloader should there be any need to
consider the detailed
   differences between the bootstrap classloader and the system classloader.
         </em>
@@ -322,7 +322,7 @@ limitations under the License.
       </p>
       <p>
         <em>
-  In practical development terms: two classes with the same symbolic name can only be used
interchangably
+  In practical development terms: two classes with the same symbolic name can only be used
interchangeably
   if they are defined by the same classloader. A classic symptom indicative of a classloader
issue is that
   two classes with the same fully qualified name are found to be incompatible during a method
call.
   This may happen when a member is expecting an interface which is (seemingly) implemented
by a class
@@ -340,7 +340,7 @@ limitations under the License.
       </p>
       <p>
         <em>
-  In practial development terms: This is very important to bear in mind when trying to solve
classloader issues.
+  In practical development terms: This is very important to bear in mind when trying to solve
classloader issues.
   A classic misunderstanding is this: suppose class A defined by classloader C has a symbolic
reference to
   class B and further that when C initiates loading of B, this is delegated to classloader
D which defines B.
   Class B can now only resolve symbols that can be loaded by D, rather than all those which
can be loaded by C.
@@ -515,9 +515,9 @@ limitations under the License.
 <source>
 This specification requires that J2EE containers provide a per thread
 context class loader for the use of system or library classes in
-dynamicly loading classes provided by the application.  The EJB
+dynamically loading classes provided by the application.  The EJB
 specification requires that all EJB client containers provide a per
-thread context class loader for dynamicly loading system value classes.
+thread context class loader for dynamically loading system value classes.
 The per thread context class loader is accessed using the Thread method
 getContextClassLoader.
 
@@ -527,7 +527,7 @@ loader, an extension class loader, and s
 loader.  The top level application class loader delegates to the lower
 class loaders as needed.  Classes loaded by lower class loaders, such as
 portable EJB system value classes, need to be able to discover the top
-level application class loader used to dynamicly load application
+level application class loader used to dynamically load application
 classes.
 
 We require that containers provide a per thread context class loader
@@ -633,7 +633,7 @@ href='http://publib.boulder.ibm.com/info
       <p>
   Performance dictates that symbolic references to the logging systems are present in the
implementation
   classes (again, reflection would simply be too slow). So, for an implementation to be able
to function,
-  it is neccessary for the logging system to be loadable by the classloader that defines
the implementing class.
+  it is necessary for the logging system to be loadable by the classloader that defines the
implementing class.
       </p>
       </subsection>
 

Modified: commons/proper/logging/trunk/src/site/xdoc/troubleshooting.xml
URL: http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/site/xdoc/troubleshooting.xml?rev=1432710&r1=1432709&r2=1432710&view=diff
==============================================================================
--- commons/proper/logging/trunk/src/site/xdoc/troubleshooting.xml (original)
+++ commons/proper/logging/trunk/src/site/xdoc/troubleshooting.xml Sun Jan 13 19:22:05 2013
@@ -437,7 +437,7 @@ implementation.
  can only see their matching concrete logging library if that library is
  available in the same classpath. Bundling the full commons-logging jarfile
  (with adapters) into the system classpath therefore means that logging
- libraries (eg log4j) within WEB-INF/lib are not accessable.
+ libraries (eg log4j) within WEB-INF/lib are not accessible.
    </p>
    <p>
  Note that the behaviour described here only applies if the standard Tomcat



Mime
View raw message