[
https://issues.apache.org/jira/browse/DIRSERVER-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu updated DIRSERVER-1173:
-------------------------------------
These problems still showing up after rewriting all this frontend code and the
event mechanism? FYI I like returning the deleted entry because it gives
clients something to work with if they need to respond to a delete attempt.
> Delete operation with a PersistentSearch returns the deleted entry
> ------------------------------------------------------------------
>
> Key: DIRSERVER-1173
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1173
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.2
> Reporter: Emmanuel Lecharny
> Fix For: 1.5.4
>
>
> While debugging a failure in PersistentSearch I found that we have an
> inconsistant behavior when deleting entries :
> testPsearchDelete :
> ctx.destroySubcontext( RDN ); // RDN = "cn=Tori Amos"
> ...
> assertNotNull( listener.result ); // Should be null, but is not
> assertEquals( RDN, listener.result.getName() ); // Contains the deleted
> entry...
> Another test :
> testPsearchAbandon :
> ctx.destroySubcontext( "cn=Jack Black" );
> ...
> // there seems to be a race condition here
> //assertNull( listener.result ); // Has been commented as otherwise, the
> test would fail
> ...
> Note the comment...
> While looking into the PersistentSearchListener code, here is what we have :
> public void objectRemoved( NamingEvent evt )
> {
> // send the entry back
> sendEntry( evt );
> }
> This sendEntry method simply return the deleted entry, and is supposed to set
> the PersistentSearchControl, so the test is incorrect. We should test that
> the Control contains the correct ChangeType
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
