-----Original Message----- From: Alex Karasulu [mailto:[EMAIL PROTECTED] 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 mail: [EMAIL PROTECTED] 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 modification? Alex
