directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Mitosis Advice
Date Thu, 04 Jan 2007 20:19:16 GMT
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


Mime
View raw message