directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon.Tem...@saaconsultants.com
Subject Re: Mitosis Advice
Date Fri, 05 Jan 2007 09:56:20 GMT

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)
Mime
View raw message