[ http://issues.apache.org/jira/brows...VE-307?page=all ]

Stefan Zoerner updated DIREVE-307:
----------------------------------

Comment: was deleted

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