Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of aok123@bellsouth.net designates
 205.152.59.66 as permitted sender)
Message-ID: <43CBC367.8000700@bellsouth.net>
Date: Mon, 16 Jan 2006 11:01:43 -0500
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: LDAP 0.9.3 . Modify attribute fails with exception
References: 
 <OF3ECD723F.FD9AE805-ONC12570F8.002FC972-C12570F8.0030B2B9@de.ibm.com>
In-Reply-To: 
 <OF3ECD723F.FD9AE805-ONC12570F8.002FC972-C12570F8.0030B2B9@de.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Zoerner wrote:

>>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?
>
>Emmanuel is right. We have definitely a problem here, but in the add op,
>not in the modify op (as Alex explained, the behavior of the latter is
>correct).
>  
>
+1 : I overlooked the add disfunction.

>E.g. the following entry can be created (note that no attribute "voice"
>exists in the schema.
>
>dn: cn=Kate Bush,dc=example,dc=com
>cn: Kate Bush
>objectclass: top
>objectclass: person
>sn: Bush
>voice: unbelievable
>  
>
This is not good.  Especially since this is way easy to check for.  Do 
we already have a JIRA for it?  Also we might want to just turn off all 
checks too like when servers have schema checking totally disabled.

>The following operation does neither throw an error nor an exception on
>server side
>
>$ ldapadd -p 10389 -D uid=admin,ou=system -w ***** -f addKate.ldif
>adding new entry cn=Kate Bush,dc=example,dc=com
>
>But searching Kate causes exceptions on the server (not visible to the
>client) like
>
>javax.naming.NamingException: OID for name 'voice' was not found within the
>OID
>registry
>        at
>org.apache.ldap.server.schema.GlobalOidRegistry.getOid(GlobalOidRegistry.java:176)
>        at
>org.apache.ldap.server.schema.GlobalAttributeTypeRegistry.lookup(GlobalAttributeTypeRegistry.java:124)
>        at
>org.apache.ldap.server.partition.impl.btree.BTreeSearchResultEnumeration.next(BTreeSearchResultEnumeration.java:181)
>        at
>org.apache.ldap.server.enumeration.SearchResultFilteringEnumeration.prefetch(SearchResultFilteringEnumeration.java:299)
>        at
>org.apache.ldap.server.enumeration.SearchResultFilteringEnumeration.<init>(SearchResultFilteringEnumeration.java:110)
>        at
>org.apache.ldap.server.collective.CollectiveAttributeService.search(CollectiveAttributeService.java:279)
>        at
>org.apache.ldap.server.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:1178)
>        at
>org.apache.ldap.server.operational.OperationalAttributeService.search(OperationalAttributeService.java:255)
>
>and it is not possible to change the entry afterwards (like Somashish
>described in his original issue).
>
>Seems to me that our schema checks are not consistent.
>  
>
Agreed :(.  We need eventually to rewrite this whole subsystem.  It's 
really in shambles.

Alex