directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [jira] Updated: (DIRSERVER-1173) Delete operation with a PersistentSearch returns the deleted entry
Date Mon, 12 May 2008 15:10:21 GMT
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.
>
>

Mime
View raw message