Ok, np.

The best would probably be to start back from the revision you used when you left in december, and consider what I have done since as a best effort, but not sufficient.

What is important is to see how we can keep the txn at the right place (ie in the opManager), *if* it's the best place.

Frankly, I have *no* problem reverting what I have done. It already had the advantage for me to get a bit of understanding on what you have done, even if it wasn't not good enough to stabilize the code.

So atm, what I would suggest is that we revert, you can then continue without having conflicts, get the branch working with mvn (running in eclipse is not enough), and when you are done, we can consider mergng back in trunk.

Sounds like a plan for you ?

PS : at some point, we *really* need to share what you have done to be sure we can fix a bug without destroying the original work.

Thanks !


On Mon, Feb 27, 2012 at 7:29 PM, Selcuk AYA <ayaselcuk@gmail.com> wrote:
I fixed quite a bit of issues and got the tests to work at least in
eclipse(not checked with mvn yet). I was going to commit but saw some
changes did an svn up and the files ended up in conflict.Also I saw
some changes to search layer trying to fix some stuff which actuyally
wont fix anything. If possible please roll back all your latest check
in. Just a status update of what works and what doesnt work will be
enough at this point and I will ask for further help if i need coding
help.

On Mon, Feb 27, 2012 at 8:31 AM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
> Hi Selcuk,
>
> so I had time this morning to get back to the branch, and focus on the error
> I have. Here is a sumary of the pb.
>
> First, I have @ignored a few failing tests :
> - in PasswordPolicy, because the failure has nothing to do with the txns
> - then for the PagedSearch tests, because I haven't -yet- restored the way
> it was deling with txns in your initial branch
>
> Otherwise, the rest of tests are passing with flying colors, except one test
> in ldap-client-test module :
> ClientSearchRequestTest.testSeaechPersonSubstring() is failing.
>
> What happens is that we get back may entries which don't fit the
> "(objectclass=*ers*)" filter (12 entries, instead of 3).
>
> Here are the returned entries :
>
> Entry
>    dn: cn=Administrators,ou=groups,ou=system
>    objectClass: top
>    objectClass: groupOfUniqueNames
>    createTimestamp: 20120227140034Z
>    uniqueMember: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>    entryUUID: 027f4818-79a7-4974-a363-148f9f37ff6b
>    cn: Administrators
>    entryCSN: 20120227140034.983000Z#000000#000#000000
>    entryParentId: ae9ab7f6-5afb-4345-b801-2424714ffd84
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry
>    dn: ou=configuration,ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    createTimestamp: 20120227140034Z
>    ou: configuration
>    entryUUID: 2ddf826e-14c5-441f-9907-7d54524fbde7
>    entryCSN: 20120227140034.994000Z#000000#000#000000
>    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry (OK)
>    dn: uid=admin,ou=system
>    objectClass: top
>    objectClass: person
>    objectClass: organizationalPerson
>    objectClass: inetOrgPerson
>    objectClass: tlsKeyInfo
>    uid: admin
>    privateKeyFormat: PKCS#8
>    createTimestamp: 20120227140034Z
>    sn: administrator
>    entryUUID: 399e0da3-beae-4bc5-8d33-5d113607c07f
>    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>    publicKey: 0\0
>    displayName: Directory Superuser
>    userCertificate: 0? ?0? 0   5? ? 0
>
> Entry
>    dn: ou=users,ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    createTimestamp: 20120227140034Z
>    ou: users
>    entryUUID: 548c6635-d95b-45af-899f-3585d9af774c
>    entryCSN: 20120227140034.965000Z#000000#000#000000
>    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry
>    dn: ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    objectClass: extensibleObject
>    createTimestamp: 20120227140034Z
>    ou: system
>    entryUUID: 69acb598-559f-4ca9-8aa4-bd63096cd100
>    entryCSN: 20120227140034.551000Z#000000#000#000000
>    entryParentId: 00000000-0000-0000-0000-000000000000
>    creatorsName: uid=admin,ou=system
>
> Entry
>    dn: prefNodeName=sysPrefRoot,ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    objectClass: extensibleObject
>    createTimestamp: 20120227140035Z
>    entryUUID: 6f0e6dc3-2fe3-4616-bab9-33ac7dc8e0dd
>    prefNodeName: sysPrefRoot
>    entryCSN: 20120227140035.044000Z#000000#000#000000
>    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry
>    dn: ou=partitions,ou=configuration,ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    createTimestamp: 20120227140035Z
>    ou: partitions
>    entryUUID: 868ee0ae-5b31-4646-a8b9-b2896aab8efe
>    entryCSN: 20120227140035.010000Z#000000#000#000000
>    entryParentId: 2ddf826e-14c5-441f-9907-7d54524fbde7
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry
>    dn: ou=services,ou=configuration,ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    createTimestamp: 20120227140035Z
>    ou: services
>    entryUUID: 9f06c097-6a21-4fbe-94b2-830d7d1967fe
>    entryCSN: 20120227140035.023000Z#000000#000#000000
>    entryParentId: 2ddf826e-14c5-441f-9907-7d54524fbde7
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry (OK)
>    dn: cn=elecharny,ou=users,ou=system
>    objectclass: person
>    objectclass: top
>    createTimestamp: 20120227140035Z
>    sn: Emmanuel Lécharny
>    entryUUID: a8fa279b-cefe-4747-aa5c-952899cb041a
>    cn: elecharny
>    entryCSN: 20120227140035.268000Z#000000#000#000000
>    entryParentId: 548c6635-d95b-45af-899f-3585d9af774c
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry
>    dn: ou=groups,ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    createTimestamp: 20120227140034Z
>    ou: groups
>    entryUUID: ae9ab7f6-5afb-4345-b801-2424714ffd84
>    entryCSN: 20120227140034.974000Z#000000#000#000000
>    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry (OK)
>    dn: cn=user1,ou=users,ou=system
>    objectclass: person
>    objectclass: top
>    createTimestamp: 20120227140035Z
>    sn: user1 sn
>    entryUUID: be3072a9-fc95-4782-bac0-e2a0f3cf0e21
>    cn: user1
>    entryCSN: 20120227140035.214000Z#000000#000#000000
>    entryParentId: 548c6635-d95b-45af-899f-3585d9af774c
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> Entry
>    dn: ou=interceptors,ou=configuration,ou=system
>    objectClass: top
>    objectClass: organizationalUnit
>    createTimestamp: 20120227140035Z
>    ou: interceptors
>    entryUUID: f4dfd59b-f03e-4b8b-932c-8a6bdf603c46
>    entryCSN: 20120227140035.034000Z#000000#000#000000
>    entryParentId: 2ddf826e-14c5-441f-9907-7d54524fbde7
>    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
>
> While debugging the code, it seems that at some point, we try to fetch the
> entry using the ObjectClass index, but sadly, it returns the wrong UUID so
> we fetch an entry which has not the right ObjectClass.
>
> It's difficult to tell why the index does not refer to correct entries, as
> the test is adding the entries at the beginning, and generates some new UUID
> each time you run it, so it makes the debugging very painful.
>
> However, debugging ClientSearchRequestTest.testSeaechPersonSubstring() can
> lead to see where the error come from.
>
> Feel free to contact me for more insights, I'll be working late tonite.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com