Adding new object classes to an entry removes the old ones

• Key: DIRSERVER-335
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Alex Karasulu
• Reporter: Stefan Zoerner

Environment

Server: ApacheDS 0.9.1 on Windows XP
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)

Client: Windows XP
Command line tool ldapadd (from IBM Tivoli Directory Server)
or Softerra LDAP Administrator 3.2

Description

If additional objectclasses are added to an existing entry by a client, the old ones are lost.
 e.g. applying the following LDIF to ApacheDS

--8<--

# create an entry for a person
#
dn: cn=Tori Amos,ou=system
changetype: add
objectclass: top
objectclass: person
cn: Tori Amos
sn: Amos
description: an American singer-songwriter

# add objectclasses and uid
#
dn: cn=Tori Amos,ou=system
changetype: modify
add: objectclass
objectclass: organizationalPerson
objectclass: inetOrgPerson
-
add: uid
uid: tamos
-

-->8--

leaves an entry behind with only two (instead of all for objectclasses):

$ ldapadd -p 10389 -D uid=admin,ou=system -w *** -f addAndModifyObjectClasses.ldif
adding new entry cn=Tori Amos,ou=system

modifying entry cn=Tori Amos,ou=system

$ ldapsearch -p 10389 -b "ou=system" "(cn=Tori Amos)"
cn=Tori Amos,ou=system
sn=Amos
objectclass=inetOrgPerson
objectclass=organizationalPerson
cn=Tori Amos
uid=tamos
description=an American singer-songwriter

---

Expected result would be:

cn=Tori Amos,ou=system
sn=Amos
objectclass=top
objectclass=person
objectclass=inetOrgPerson
objectclass=organizationalPerson
cn=Tori Amos
uid=tamos
description=an American singer-songwriter

Comments

[Alex Karasulu]

Committed on revision 231186 here:

http://svn.apache.org/viewcvs.cgi?rev=231186&view=rev

Problem is gone now in 0.9.2-SNAPSHOT.

I still see the same problem when using Novell/OpenLDAP client library. I have attached a small class with a main method and a copy of the library for testing purposes.

This is using apacheds-main-0.9.2-SNAPSHOT.jar of 09-Aug-2005 12:41 (MD5sum = c9142905fe1f1aaa38ce29088a45fc09).

Test program and JLDAP library.

Even using the LDIF file included in the report above still triggers the bug.

Using a newer JAR (from Aug 10) fixed my testcase. However, using the LDIF file above, the "objectclass: top" attribute got lost.

[Stefan Zoerner]

I added a new method to the test cases (class org.apache.ldap.server.jndi.ModifyContextTest) which checks my problem. With Alex changes it disappeard. But I am not sure how characteristic the methods in ModifyContextTest really are. Do they also check the partition implementation?

The test succeeds now. But as Ugo described above the top object class still vanishes if someone tries (I observed the same problem). Therfore, the test case is not good enough ...

Looks there's definitely a bigger problem now. Multivalued attributes specified when creating a new entry are not supported! Only the last value in the list is stored.

[Stefan Zoerner]

This is getting tricky. In order to resolve the confusion I created a JUnit Testcase which uses JNDI to connect to the Directory Server via LDAP and demonstrates the error situation. This is probably easier to use/integrate than the LDIF and the JLDAP tests above.

With the current version of apacheds-main-0.9.2-SNAPSHOT.jar, two of the three tests fail. Especially the situation, Ugo described above (top missing after modification), is shown.

I checked the test case with another LDAP implementation (Sun) -- all three tests ran as expected.

In order to run the tests, a valid jndi.properties is needed.
My configuration was:
---
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url=ldap://localhost:10389/ou=system
java.naming.security.principal=uid=admin,ou=system
java.naming.security.credentials=*****
java.naming.security.authentication=simple
---
I hope this helps.

[Alex Karasulu]

Let's reopen this even though the problem has morphed into something else. Personally I think it has exposed other issues. Also note this is all starting to reveal itself do to fixes I made to the semantic behavoir of the LockableAttributesImpl.put(Attribute) method which was incorrectly not replacing the entry. I think we now are seeing places where this was used incorrrectly to make up for the lack of correct operation. We just need to keep fixing things as they arise.

[Alex Karasulu]

Ok I think I've nipped this one in the bud once and for all. I committed some changes to the apache ber provider which incorrectly used the LockableAttributesImpl.put methods to add objectClass attrbitute values on add operations. I have committed your test case stefan in revision 231287 here:

http://svn.apache.org/viewcvs.cgi?rev=231287&view=rev

Let me know how this latest fix works out. If the issue morphs into something else we can open a separate JIRA issue. This issue is way too loaded :). Thanks guys for all your help both you Stefan and Ugo for finding and contributing the test cases.

[Stefan Zoerner]

This bug has been fixed two weeks ago. I successfully retested the case in the current version, hence I close the issue.