diff --git a/core/src/main/java/org/springframework/ldap/NamingException.java b/core/src/main/java/org/springframework/ldap/NamingException.java
index 058c2b81..b76b2e0a 100644
--- a/core/src/main/java/org/springframework/ldap/NamingException.java
+++ b/core/src/main/java/org/springframework/ldap/NamingException.java
@@ -128,7 +128,7 @@ public abstract class NamingException extends NestedRuntimeException {
      * associated with this exception, if the root cause was an instance of
      * {@link javax.naming.NamingException}.
      * 
-     * @return a composite name describing the the leading portion of the name
+     * @return a composite name describing the leading portion of the name
      *         that was resolved successfully if the root cause is an instance
      *         of javax.naming.NamingException, or <code>null</code> if the
      *         resolved name field has not been set
diff --git a/core/src/main/java/org/springframework/ldap/core/LdapTemplate.java b/core/src/main/java/org/springframework/ldap/core/LdapTemplate.java
index dd6bda04..521d8776 100644
--- a/core/src/main/java/org/springframework/ldap/core/LdapTemplate.java
+++ b/core/src/main/java/org/springframework/ldap/core/LdapTemplate.java
@@ -167,7 +167,7 @@ public class LdapTemplate implements LdapOperations, InitializingBean {
 	 * Specify whether <code>PartialResultException</code> should be ignored in
 	 * searches. AD servers typically have a problem with referrals. Normally a
 	 * referral should be followed automatically, but this does not seem to work
-	 * with AD servers. The problem manifests itself with a a
+	 * with AD servers. The problem manifests itself with a
 	 * <code>PartialResultException</code> being thrown when a referral is
 	 * encountered by the server. Setting this property to <code>true</code>
 	 * presents a workaround to this problem by causing
diff --git a/core/src/main/java/org/springframework/ldap/query/LdapQueryBuilder.java b/core/src/main/java/org/springframework/ldap/query/LdapQueryBuilder.java
index 1974cfdf..2b641182 100644
--- a/core/src/main/java/org/springframework/ldap/query/LdapQueryBuilder.java
+++ b/core/src/main/java/org/springframework/ldap/query/LdapQueryBuilder.java
@@ -251,7 +251,7 @@ public final class LdapQueryBuilder implements LdapQuery {
     @Override
     public Filter filter() {
         if(rootContainer == null) {
-            throw new IllegalStateException("No filter conditions have been specified specified");
+            throw new IllegalStateException("No filter conditions have been specified");
         }
         return rootContainer.filter();
     }
diff --git a/src/docs/asciidoc/index.adoc b/src/docs/asciidoc/index.adoc
index a27063fb..8f763717 100644
--- a/src/docs/asciidoc/index.adoc
+++ b/src/docs/asciidoc/index.adoc
@@ -792,8 +792,7 @@ We previously saw that updating by using `modifyAttributes` is the recommended a
 the task of calculating attribute modifications and constructing `ModificationItem` arrays accordingly.
 `DirContextAdapter` can do all of this for us, as follows:
 
-.Updating using using `DirContextAdapter`
-====
+.Updating using `DirContextAdapter`
 [[modify-modifyAttributes]]
 [source,java]
 [subs="verbatim,quotes"]
diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml
index 9dbcc919..baac2cda 100644
--- a/src/site/xdoc/index.xml
+++ b/src/site/xdoc/index.xml
@@ -15,7 +15,7 @@
 		creating a DirContext, looping through NamingEnumerations, handling
 		exceptions and cleaning up resources. This leaves the programmer to
 		handle the important stuff - where to find data (DNs and Filters) and
-		what do do with it (map to and from domain objects, bind, modify,
+		what to do with it (map to and from domain objects, bind, modify,
 		unbind, etc.), in the same way that JdbcTemplate relieves the
 		programmer of all but the actual SQL and how the data maps to the
 		domain model.</li>