Simon a diff would be easier to use to figure out what you changed. Can
you supply that?
Thanks,
Alex
[EMAIL PROTECTED] 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" <[email protected]>
cc:
From: "Trustin Lee" <[EMAIL PROTECTED]>
Subject: Re: Mitosis Advice/
On 12/22/06, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>*
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
begin:vcard
fn:Alex Karasulu
n:Karasulu;Alex
org:Apache Software Foundation;Apache Directory
adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA
email;internet:[EMAIL PROTECTED]
title:Member, V.P.
tel;work:(904) 791-2766
tel;fax:(904) 808-4789
tel;home:(904) 808-4789
tel;cell:(904) 315-4901
note;quoted-printable:AIM: alexokarasulu=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo!: alexkarasulu=0D=0A=
IRC: aok=0D=0A=
PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A=
x-mozilla-html:FALSE
url:http://people.apache.org/~akarasulu
version:2.1
end:vcard
