directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: Mitosis Advice
Date Sat, 06 Jan 2007 02:27:37 GMT
Thanks for the patch, though it would be best if you can post a JIRA issue
and attach it there.  Of course, you don't need to do that if you've
signed CLA.  :)

Thanks again,
Trustin

On 1/5/07, Simon.Temple@saaconsultants.com <Simon.Temple@saaconsultants.com>
wrote:
>
>
> Hi Alex
>
> I attached the patch.
>
> Simon
>
> 04 January 2007 20:19
> To: Apache Directory Developers List <dev@directory.apache.org>
> cc:
> From: Alex Karasulu <akarasulu@apache.org>
> Subject: Re: Mitosis Advice
>
>
> Simon a diff would be easier to use to figure out what you changed.  Can
> you supply that?
>
> Thanks,
> Alex
>
>
> Simon.Temple@saaconsultants.com wrote:
> > Trustin
> >
> > I think I found and fixed the bug... but would like your comments before
> > I proceed :-)
> >
> > I found that if a directory entry had child entries that had previously
> > been removed and marked as deleted by the replication inteceptor, then
> > it could not be deleted:
> >     From JXplorer: "Javax.naming.ContextNotEmptyException: [LDAP: error
> > code 66 - failed to delete entry]"
> >
> > This is because the nextInteceptor.list() method does not return an
> > attribute array (I guess for optimisation?) and therfore the
> > DELETED_ENTRIES_FILTER never filtered the 'marked as deleted' entries...
> > hence the ContextNotEmptyException.
> >
> > I made the following change to the list() method.  It appears to work
> > but I am uncertain about and side effects and/or efficiency.
> >
> > I'd appreciate any comments.
> >
> >
> > My list() in ReplicationService:
> >
> >     public NamingEnumeration list( NextInterceptor nextInterceptor,
> >         LdapDN baseName ) throws NamingException
> >     {
> >         if ( log.isDebugEnabled(  ) )
> >         {
> >             log.debug( "list(" + baseName + ")" );
> >         }
> >
> >         // NamingEnumeration e = nextInterceptor.list( baseName );
> >         // SPT 4/1/7 -
> >         // The list method does not return attributes required by the
> > Constants.DELETED_ENTRIES_FILTER
> >         //     So use search instead...
> >         DirContext ctx = ( DirContext ) InvocationStack.getInstance(
> > ).peek(  )
> >                                                        .getCaller(  );
> >         NamingEnumeration e = nextInterceptor.search( baseName,
> >                 ctx.getEnvironment(  ),
> >                 new PresenceNode( Constants.OBJECT_CLASS_OID ),
> >                 new SearchControls(  ) );
> >
> >         return new SearchResultFilteringEnumeration( e, new
> > SearchControls(  ),
> >             InvocationStack.getInstance(  ).peek(  ),
> >             Constants.DELETED_ENTRIES_FILTER );
> >     }
> > Regards
> >
> > SimonT
> >
> > /22 December 2006 16:16
> > To: "Apache Directory Developers List" <dev@directory.apache.org>
> > cc:
> > From: "Trustin Lee" <trustin@gmail.com>
> > Subject: Re: Mitosis Advice/
> >
> > On 12/22/06, *Simon.Temple@saaconsultants.com
> > <mailto:Simon.Temple@saaconsultants.com>*
> > <Simon.Temple@saaconsultants.com
> > <mailto:Simon.Temple@saaconsultants.com>> wrote:
> >
> >     I have a couple of issues using Mitosis and wondered if anyone can
> help?
> >
> >     1.  Data that is loaded into DS via an LDIF file at startup does not
> >     get replicated... why?
> >
> >
> > It is because LDIF import at stratup bypasses all interceptors AFAIK.
> >
> >
> >     2.  Data loaded via an LDIF file at startup cannot be deleted as (I
> >     think!) it can't be identified by the replication inteceptor and
> >     hence throws an exception or false method return?
> >      From JXplorer: "Javax.naming.ContextNotEmptyException: [LDAP: error
> >     code 66 - failed to delete entry]"
> >
> >
> > It seems like it's a bug.  Please think Mitosis as a new born baby; it
> > has a lot of problems for now, and we will fix them.  For now, I am
> > focusing writing documentation for Mitosis so everyone can get
> > involved.  Please stay tuned if you are interested in contribution.
> >
> >
> >
> >     Is this a problem with the order in which I register the
> >     inteceptors?  Is the LDIF import implemented using an inteceptor or
> >     does it bypass part of the usual add/remove/modify and that's why
> >     replication is bypassed?
> >
> >
> > It is just because all interceptors are bypassed rather than because
> > such a complex problem.  The reason was because of the authorization
> > interceptor that prevents statup load of the LDIF file when it's first
> > statup happens with non-superuser credential.
> >
> > HTH,
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP key fingerprints:
> > * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> > * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
>
> (See attached file: akarasulu.vcf)
> (Attachments removed)
> (See attached file: listfix-simont.patch)
>
>


-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Mime
View raw message