Hi Alex!
Thank you for the fast fix. I rebuilded the server and the LDIF defect
as described in DIREVE-216 disappeared. Great.
Thank you as well for integrating my little test case. I will use your
modified (and more accurate, ctx.close() ...) class as a blueprint for
simular situations in the future.
Currently I test all examples of my book against Apache Directory
Server. I have to finish the book until mid September, therefore I must
concentrate on the book (and my main job, unfortuantly). It would be
more interesting for me to learn more about your server. Maybe it is
possible to share your slides of the ApacheCon with us after the conference?
Anyway, if I find any incorrectness during my tests this week I will let
you know. I do not hope so.
Test cases integrated in the project and its build are nice. But I think
it would also interesting to have a test suite which runs the complete
JNDI functionality against an arbitrary LDAP server (e.g. Apache
Directory Server) and has no dependency on ApacheDS. Maybe it is
possible to integrate this suite in the build later on like a black box
test ...
Greetings from Hamburg, Stefan
Alex Karasulu (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DIREVE-216?page=all ]
Alex Karasulu resolved DIREVE-216:
----------------------------------
Resolution: Fixed
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.
Adding new object classes to an entry removes the old ones
----------------------------------------------------------
Key: DIREVE-216
URL: http://issues.apache.org/jira/browse/DIREVE-216
Project: Directory Server
Type: Bug
Versions: 0.9.1
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
Reporter: Stefan Zoerner
Assignee: Alex Karasulu
Fix For: 0.9.2
Attachments: AddObjectClassesToEntryTest.java, LDAPModifyAddTest.java,
ldap.jar, patch_testCase_AddOpbjectClasses.txt
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
