Hi Alex!
I added a patch.txt to the (already resolved) DIREVE-215 at JIRA
http://issues.apache.org/jira/browse/DIREVE-215
which repeats your changes on the other handlers and corrects wrong
message ("failed to add" in case of change operationts).
The cahnges are more or less trivial, but with them there is a
consistent behaviour for clients in case of an error.
Greetings,
Stefan
Alex Karasulu (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DIREVE-215?page=all ]
Alex Karasulu resolved DIREVE-215:
----------------------------------
Resolution: Fixed
If you look at the diff for committed revision 230698 you'll see that I modified your changes a bit. I still send the stack trace back but only when logging is in full debug mode. I really need to work on the logging in these modules and reviewing the messages they return. Perhaps you can lend a hand so we can do this together. You interested?
Here's the diff of my commits:
xhttp://svn.apache.org/viewcvs.cgi?rev=230698&view=rev
BTW I will build and upload the new jars for this and apacheds built with it.
Wrong error messages for some operations
----------------------------------------
Key: DIREVE-215
URL: http://issues.apache.org/jira/browse/DIREVE-215
Project: Directory Server
Type: Bug
Components: protocol
Versions: 0.9.1
Reporter: Stefan Zoerner
Assignee: Alex Karasulu
Priority: Minor
Fix For: 0.9.2
Attachments: DeleteHandler.java
If a client tries to remove an entry, and the deletion fails because the entry
is not a leaf (error code 66), the LDAP message is wrong.
Status code and Exception type within the server are correct (as detected by the
corresponding test case). But the message text itself contains the words "failed to
add entry". This information is sent to the client, which may display it, e.g.
* JNDI includes it during creation of appropriate Exception
(com.sun.jndi.ldap.LdapCtx.mapErrorCode(66, "failed to add entry ...").
* Command line tools like ldapmodify display it on the console.
Example: If the following LDIF is applied to ApacheDS
---
# create entry
dn: ou=noLeaf,ou=system
changetype: add
ou: noLeaf
objectclass: top
objectclass: organizationalUnit
# create entry below the first
dn: ou=leaf,ou=noLeaf,ou=system
changetype: add
ou: leaf
objectclass: top
objectclass: organizationalUnit
# delete subtree
dn: ou=noLeaf,ou=system
changetype: delete
---
it goes
$ ldapmodify -h magritte -p 10389 -D uid=admin,ou=system -w **** -f
deleteSubtree.ldif
adding new entry ou=noLeaf,ou=system
adding new entry ou=leaf,ou=noLeaf,ou=system
deleting entry ou=noLeaf,ou=system
ldap_delete: Operation not allowed on nonleaf
ldap_delete: additional info: failed to add entry ou=noLeaf,ou=system:
... (very long Stack trace deleted) ...
$
I modified the error message within class org.apache.ldap.server.protocol.DeleteHandler to
"failed to delete entry ..." (attached), although I would prefer a more detailed message
(like "Not Allowed On Non-leaf", as Sun Directory does). But this is not possible at that
general place without an ugly switch or so.
The same "defect" (probably a cut/copy/paste of error message from AddHandler)
is present in CompareHandler, ModifyDnHandler, and ModifyHandler.
I would also suggest not to send the complete stack trace back to the client. I
have removed it in the attached version of the DeleteHandler and had a better
command line experience with ApacheDS (the stack traces should go in a server
log only from my point of view). This applies to other handlers (e.g. Add) as
well.
