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
