You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Si...@saaconsultants.com on 2007/01/04 17:31:57 UTC
Re: Mitosis Advice
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" <de...@directory.apache.org>
cc:
From: "Trustin Lee" <tr...@gmail.com>
Subject: Re: Mitosis Advice
On 12/22/06, Simon.Temple@saaconsultants.com <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
Re: Mitosis Advice
Posted by Alex Karasulu <ak...@apache.org>.
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" <de...@directory.apache.org>
> cc:
> From: "Trustin Lee" <tr...@gmail.com>
> Subject: Re: Mitosis Advice/
>
> On 12/22/06, *Simon.Temple@saaconsultants.com
> <ma...@saaconsultants.com>*
> <Simon.Temple@saaconsultants.com
> <ma...@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