directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Somashish Gupta" <>
Subject RE: LDAP 0.9.3 . Modify attribute fails with exception
Date Wed, 18 Jan 2006 06:32:28 GMT

-----Original Message-----
From: Alex Karasulu [] 
Sent: Monday, January 16, 2006 7:49 AM
To: Apache Directory Developers List
Subject: Re: LDAP 0.9.3 . Modify attribute fails with exception

Emmanuel Lecharny wrote:

>>> Ok, seems to be related to the schema handling. I will try to 
>>> reproduce this on my server .
>> I don't think this is an an error.  He's using an undefined 
>> attribute: activeFlag.  Since 0.9 we have added some minimal schema 
>> checks.
> hmmm... What about the fact that the entry was correctly created with 
> this not existing attribute? Isn't it weird that the server accept a 
> creation but not a modification in this case?

Heh now that's a bug :-).

>> Guys, I don't think there is a need for a JIRA issue on this one.  If 
>> adding a the attributeType with a schema does not resolve this issue 
>> then yeah I think we should file an issue.

> For the very same reason I exposed in my previous comment, if you can 
> create an entry with a non existing attribute, 

Hmmm but did he though?  I don't have enough info to determine that.  I 
presumed the entry was valid before the modify op.  I may be mistaken.

I was able to perform the creation operation without any issue even though
it had "activeFlag" (not defined in schema). So the activeFlag came into
existence right at the creation stage. However I only got error when I tried
to perform modify operation on it. Today I also got an error when performing
search with one of the search parameters as activeFlag (Stefan had mentioned
this in another mail). Interestingly the search fails with NamingException
on the server, but JNDI call returning enumeration doesn't report it. So my
suggestion would be that we should trap this schema violation right at the
creation time only (current behavior of modify and search are OK I feel). If
everybody feels comfortable, then I can try to look into the code and will
try to fix and provide a patch for it. Also shouldn't this schema checking
be made configurable (with default value being checking the schema along
with a server configuration parameter to turn it off). The responsibility of
data structure mess up of course lies with the LDAP administrator and
application developer.

LDIF before modification

version: 1
dn: ou=adminDomain,o=eTouchWiki,ou=system
objectclass: organizationalUnit
activeFlag: A
autoActivationAllowed: No
city: ADMIN
codeFlag: 1
companyName: ADMIN
companyURL: ADMIN
country: ADMIN
dateCodeGenerated: Wednesday, December 31, 1969 4:00:00 PM PST
dateCreated: Sunday, January 15, 2006 2:51:28 AM PST
dateModified: Sunday, January 15, 2006 2:51:28 AM PST
domainKey: ADMIN
ou: adminDomain
postalCode: ADMIN
protected: Yes
selfRegAllowed: No
serviceType: 4
state: ADMIN
street: ADMIN
telephoneNumber: ADMIN
telexNumber: ADMIN

dn: cn=admin,ou=adminDomain,o=eTouchWiki,ou=system
objectclass: organizationalRole
cn: admin

dn: cn=system,cn=admin,ou=adminDomain,o=eTouchWiki,ou=system
objectclass: inetOrgPerson
activeFlag: A
cn: system
codeFlag: 1
dateCodeGenerated: Wednesday, December 31, 1969 4:00:00 PM PST
dateCreated: Sunday, January 15, 2006 2:51:28 AM PST
dateModified: Sunday, January 15, 2006 2:51:28 AM PST
givenName: Somashish
sn: Gupta
userPassword:: cGFzc3dvcmQ=

> but you can't modify it because you have a schema check, that's sound 
> to be something we want to reproduce and eventualy add to a regression 
> test. This is why I asked for a Jira filling. But if this is just a 
> configuration mistake, of course, jira is not the way to go.
> I apologize if I induced some "noise" in Jira.

No need to apologizse you've got a good point Emmanuel.  We just don't 
have enough info here I guess.  I'm just wondering if the activeFlag 
attribute was added in the modify operation after a valid entry was 
created (added). 

Somashish could you please post the contents (LDIF) of the entry before 


View raw message