[ http://issues.apache.org/jira/brows...235754
2 ]

Stefan Zoerner commented on DIREVE-307:
---------------------------------------

I do not understand this manual thing "One or more blank lines may be used t
o separate each DN/RDN pair". Note that you have to use the OpenLDAP client 
here to see the effect described in the issue, because others (Solaris9, IBM
 Tivoli DS to name two) won
't let you enter blank lines ... If I do the following:

$ ldapmodrdn -h <hostname> -p <port> -x -D <bindDN> -w <passwd> -r

and start to enter my parameters interactively, the client sends a modify DN
 request after each two lines:

(1) ou=A,dc=bundestag,dc=de
(2) ou=B => Request (works)
(3)
(4) ou=B,dc=bundestag,dc=de => Request

The second request leads to various errors, here two examples:

Sun Java System Directory Server 5.2:
Rename Result: Protocol error (2)
Additional info: null original dn

OpenLDAP 2.1
Rename Result: Server is unwilling to perform (53)
Additional info: cannot rename the root DSE

Therefore this tool does not seem to me to allow you to separate parameter p
airs by blank lines.

---

Our fault: We do not send the correct error here. The input with blank line 
leads to a request with req.getName() empty and later to a RuntimeExcpetion 
in class org.apache.ldap.server.protocol.support.ModifyDnHandler, as display
ed in stack trace provided
by Endi.

We should decide/find out which error to throw in that situation, and throw 
it. Currently, the client does not get an error at all, and therefore does n
ot take notice of the problem occurred.


> ldapmodrdn failed upon encountering blank space
> -----------------------------------------------
>
>          Key: DIREVE-307
>          URL: http://issues.apache.org/jira/browse/DIREVE-307
>      Project: Directory Server
>         Type: Bug
>   Components: protocol
>     Versions: 0.9.3
>     Reporter: Endi S. Dewata
>     Assignee: Alex Karasulu

>
> When specifying multiple entries for ldapmodrdn operation, according to the manual page ([url
]http://linuxcommand.org/man_pages/ldapmodrdn1.html[/url]) "one or more blank lines may be
 used to separate each DN/RDN pair." However, it seems that currently ApacheDS do[/v
bcol]
es not allow any blank lines in the ldapmodrdn input.[vbcol=seagreen]
> Note: I'm not sure if at least one blank line is actually required to sepa
rate the entires. To be safe, the blank line maybe can be made totally optio
nal.
> The following operation currently will succeed in renaming both entries. 
> ou=test,dc=apache,dc=org
> ou=test2
> ou=test2,dc=apache,dc=org
> ou=test
> The following command currently will fail on the second entry: 
> ou=test,dc=apache,dc=org
> ou=test2
> ou=test2,dc=apache,dc=org
> ou=test
> Here is the exception:
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
>         at java.util.ArrayList.RangeCheck(ArrayList.java:507)
>         at java.util.ArrayList.remove(ArrayList.java:392)
>         at org.apache.ldap.common.name.LdapName.remove(LdapName.java:605)
>         at org.apache.ldap.server.protocol.ModifyDnHandler.messageReceived
(ModifyDnHandler.java:79)
>         at org.apache.mina.protocol.handler.DemuxingProtocolHandler.messag
eReceived(DemuxingProtocolHandler.java:70)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain$2.messageR
eceived(AbstractProtocolFilterChain.java:149)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMe
 ssageReceived(AbstractProtocolFilterChai
n.java:365)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain.access$100
0(AbstractProtocolFilterChain.java:50)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.me
 ssageReceived(AbstractProtocolFilterChai
n.java:524)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain$1.messageR
eceived(AbstractProtocolFilterChain.java:99)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMe
 ssageReceived(AbstractProtocolFilterChai
n.java:365)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain.messageRec
eived(AbstractProtocolFilterChain.java:356)
>         at org.apache.mina.protocol.ProtocolSessionManagerFilterChain$1.me
 ssageReceived(ProtocolSessionManagerFilt
erChain.java:77)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMe
 ssageReceived(AbstractProtocolFilterChai
n.java:365)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain.access$100
0(AbstractProtocolFilterChain.java:50)
>         at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.me
 ssageReceived(AbstractProtocolFilterChai
n.java:524)
>         at org.apache.mina.protocol.filter.ProtocolThreadPoolFilter.proces
sEvent(ProtocolThreadPoolFilter.java:108)
>         at org.apache.mina.util.BaseThreadPool$Worker.processEvents(BaseTh
readPool.java:393)
>         at org.apache.mina.util.BaseThreadPool$Worker.run(BaseThreadPool.java:333)


--
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 ]