[ http://issues.apache.org/jira/brows...231793
1 ]

Alex Karasulu commented on DIREVE-215:
--------------------------------------

Thanks a bunch Stefan but next time please submit a diff instead of the file
 itself.  These are easier to review and apply but hey this is better than m
ost .

I agree about the stack trace however that was for debuging purposes.  I wil
l use the log level to not show this on the client as well as print the stac
k trace out to the server log file. It's pretty helpful to get the trace on 
the client side when you're
working on separate machines.  However for production this should not be the
 case.  Again using nlog4j should help us out considerably in terms of contr
olling this behavoir.


> 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 e
ntry 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 wo
rds "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.j
ndi.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 delete
Subtree.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.DeleteHa
ndler to "failed to delete entry ..." (attached), although I would prefer a more det
ailed message (like "Not Allowed On Non-leaf", as Sun Directory does). But this is n
ot
possible at that general place without an ugly switch or so.
> The same "defect" (probably a cut/copy/paste of error message from AddHand
ler) is present in CompareHandler, ModifyDnHandler, and ModifyHandler.
> I would also suggest not to send the complete stack trace back to the client. I ha
ve 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.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]