Fix duplicate typos in docs and exception message

core/src/main/java/org/springframework/ldap/NamingException.java

@@ -128,7 +128,7 @@ public Name getRemainingName() {
      * 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

core/src/main/java/org/springframework/ldap/core/LdapTemplate.java

@@ -167,7 +167,7 @@ public void setIgnoreNameNotFoundException(boolean ignore) {
 	 * 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

core/src/main/java/org/springframework/ldap/query/LdapQueryBuilder.java

@@ -244,7 +244,7 @@ public String[] attributes() {
     @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();
     }

src/docs/asciidoc/index.adoc

@@ -721,7 +721,7 @@ We previously saw that updating using `modifyAttributes` is the recommended appr
 the task of calculating attribute modifications and constructing `ModificationItem` arrays accordingly.
 `DirContextAdapter` can do all of this for us:
 
-.Updating using using DirContextAdapter
+.Updating using DirContextAdapter
 [[modify-modifyAttributes]]
 [source,java]
 [subs="verbatim,quotes"]
@@ -966,7 +966,7 @@ public class PersonRepoImpl implements PersonRepo {
 In several cases the Distinguished Name (DN) of an object is constructed using properties of the object.
 E.g. in the above example, the country, company and full name of the `Person` are used in the DN, which means that updating any of these properties will actually require moving the entry in the LDAP tree using the `rename()` operation in addition to updating the `Attribute` values.
 Since this is highly implementation specific this is something you'll need to keep track of yourself - either by disallowing the user to change these properties or performing the `rename()` operation in your `update()` method if needed.
-Note that using <<odm>>, the the library can automatically handle this for you if you annotate your domain classes appropriately.
+Note that using <<odm>>, the library can automatically handle this for you if you annotate your domain classes appropriately.
 
 ====
 

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>