I'd push this one out to 1.5.4 where we can revamp this mechanism totally when we switch to Cursors and be rid of the JNDIsms bogging this feature down.  Once we add more clarity without dealing with having to understand the JNDI behavoir required by the JNDI provider this gets really easy.

Alex

On Mon, May 12, 2008 at 5:51 AM, Emmanuel Lecharny (JIRA) <jira@apache.org> wrote:

    [ https://issues.apache.org/jira/browse/DIRSERVER-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRSERVER-1173:
-----------------------------------------

   Affects Version/s: 1.5.2
       Fix Version/s: 1.5.3

> 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.3
>
>
> 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.