gecko-dev/directory/java-sdk

README for september 28


  On September 28, a new source drop was assembled. The LDAPConnection
version is now 3.05. Compared to the original 3.0 source drop, this
addresses the following problems:

  On disconnect (or on finalizing an LDAPConnection object, which
implicitly calls the finalizer), a reference to the underlying socket
was kept, so that the socket was not closed. As a consequence, an
application which repeatedly did connect and disconnect would
experience a resource leak. On UNIX systems, the java VM might
eventually crash because of insufficient file descriptors. On Windows,
it might eventually crash because of memory exhaustion.

  Referrals were not correctly followed on add operations.

  Support has now been added for referrals on authentication. There is
a new overloaded authenticate method in LDAPConnection which takes an
LDAPSearchConstraints as a parameter.

 There was no check for an empty or null host String on connect. Now,
LDAPConnection.connect() throws an LDAPException for these two cases.

  Automatic reconnect when the server was restarted did not work. This
is now handled transparently on the next operation. Also,
LDAPConnection.isConnected() did not always return a correct response.

  A bad referral (one that points to a non-existent or inaccessible
server or entry) would cause any following valid results from a search
to be discarded.

  For asynchronous searches (batchSize == 1), it was possible that
search results would arrive from the server and be buffered by the SDK
faster than they could be processed by the application (using
LDAPSearchResults.next() or LDAPSearchResults.nextElement()). The
buffered results might use up more memory than was available in the
java VM, causing it to crash. Now, there is a limit of 100 on the
number of buffered entries per asynchronous search. The number can be
changed with LDAPSearchConstraints.setMaxBacklog(int backlog). If
there are no synchronous searches on a physical connection, and any
asynchronous searches have full backlog buffers, the listener thread
sleeps until search results are processed by the client.

  Persistent search response controls could be overwritten before a
client could process them. Now they are queued and served up one at a
time to the client.

  LDAPSearchResults().getCount() always returned the number of results
processed by the client, rather than the number of results available
to be processed by the client.

  LDAPSearchResults.sort() would throw a ClassCastException if the
LDAPSearchResults object contained exceptions (LDAPException and
LDAPReferralException) in addition to any LDAPEntry objects.

----

  There is also a new directory "tools" containing source for the
command-line tools LDAPSearch, LDAPModify, and LDAPDelete.