svn commit: r1776658 - /directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext

[sm...@apache.org]

Author: smckinney
Date: Fri Dec 30 23:18:24 2016
New Revision: 1776658

URL: http://svn.apache.org/viewvc?rev=1776658&view=rev
Log:
more

Modified:
    directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext

Modified: directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext?rev=1776658&r1=1776657&r2=1776658&view=diff
==============================================================================
--- directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext (original)
+++ directory/site/trunk/content/api/user-guide/1.1-java-and-ldap.mdtext Fri Dec 30 23:18:24 2016
@@ -23,13 +23,13 @@ Notice: Licensed to the Apache Software
     under the License.
 
 # 1.1 - Java and LDAP
-Most developers will, at some point, face the tricky task to communicate with a **LDAP** server. **LDAP** seems to be a very simple technology, but when you get deep into it, you realize that many aspects are not well known, and not easy to deal with.
+Most developers will at some point need to learn how to communicate with an **LDAP** server. It should be a very simple technology to use but isn't because many aspects are not well known.
 
-Java is one of the most commonly used languages used in the enterprise. Some even call it the new **Cobol**!
+Java is one of the most commonly used languages in the enterprise. Some call it the new **Cobol**!
 
-Those two facts make it necessary to be able to communicate with a **LDAP** server using **Java**. This is where a convenient **API** is useful, which is why we decided to provide this **API**.
+These facts mean it's necessary to communicate over **LDAP** using **Java**. This is why a convenient **API** is necessary, so we created this **API** to fill the necessary gaps.
 
-Of course, there are alternatives, like **JNDI**. We believe that the others don't help users cope with **LDAP**'s inherent complexities. **JNDI**'s semantics are very different than what's required for proper **LDAP** usage. For example:
+There are alternatives, like **JNDI**. But the alternatives aren't effective helping users cope with **LDAP**'s inherent complexities. **JNDI**'s semantics are very different from what's required for proper **LDAP** usage. For example:
 
 * **Bind** : used in **LDAP** to authenticate a user but creates an entry in **JNDI**
 * **Unbind** : closes the **LDAP** session in **LDAP** but deletes an entry in **JNDI**
@@ -39,7 +39,7 @@ Of course, there are alternatives, like
 * **Name** in **JNDI** can't do a valid comparison in **JNDI**
 * **NamingEnumeration** must be explcitly closed in **JNDI**, and don't close automatically upon disconnect, which causes resource leakage to occur.
 
-Some of those problems are also true for the existing **LDAP API**.
+Some of these same problems exist for the other **LDAP API**s.  Other alternatives are no longer supported and/or lack a permissive license.
 
 All in all, writing applications to perform basic **LDAP** operations in **Java** is a painful task for most developers.