thanks Emmanuel. I put my fixes on top of your changes which were there last week(when I started working on the code again). Only reverting to that point is good enough. Once I can verify the tests and check in the code, I will give a status update.
thanks Selcuk On Mon, Feb 27, 2012 at 10:50 AM, Emmanuel Lecharny <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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
