From f9133c97e876ebe0ec69d5003f75074571c55225 Mon Sep 17 00:00:00 2001 From: "chuckb%netscape.com" Date: Tue, 29 Sep 1998 05:33:50 +0000 Subject: [PATCH] added readme for 9.28 git-svn-id: svn://10.0.0.236/trunk@11324 18797224-902f-48f8-a5cc-f745e15eee43 --- mozilla/directory/java-sdk/README | 61 +++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 mozilla/directory/java-sdk/README diff --git a/mozilla/directory/java-sdk/README b/mozilla/directory/java-sdk/README new file mode 100644 index 00000000000..51aa0a96421 --- /dev/null +++ b/mozilla/directory/java-sdk/README @@ -0,0 +1,61 @@ +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. +