On Dec 21, 2007 7:09 AM, <[EMAIL PROTECTED]> wrote: > Alex, > > I have rebuilt my stuff to run with a 1.5.2-SNAPSHOT and can confirm this > problem does not exist using the latest trunk. > > How do you wish me to proceed? >
Hey that's good news. I guess we can just ignore this and try to push for 1.5.2 to come out. You cool with working with the trunk? Alex > *19 December 2007 16:55 > To: "Apache Directory Developers List" <[email protected]> > cc: > From: "Alex Karasulu" <[EMAIL PROTECTED]> > Subject: Re: Possible defect in 1.5.1: error code 54 - failed on search > operation* > > Hey Simon, > > Thanks for finding this. And I looked in JIRA for something similar but I > could not find anything so you must have stepped on a new bug. > > Can you do a few more things for this issue so we can test and resolve it: > > > (1) See if the problem in the present trunk > (2) Report your findings in a JIRA > (3) Create a new test for core-integ with an @Ignore annotation for now. > (4) Attach this test and what data you need to include to your JIRA issue. > > > Thanks, > Alex > > On Dec 19, 2007 9:44 AM, <[EMAIL PROTECTED]> wrote: > > > Using LDAP Studio 0.8.0 I create a new child entry beneath: > > uid=admin,ou=system. I then restart DS. Following the restart, if I try to > > expand the node uid=admin,ou=system to show the child entry I created I get > > an error: > > > > LDAP: error code 54 - failed on search operation: Unexpected > > exception. > > > > I do not get this error prior to the restart. There are no errors in > > the server side log. (log4j.rootCategory=WARN) > > > > > > ** This only appears to be problem when I create the child entry using > > an objectClass I have defined in a custom schema which I load via an > > LDIF. > > > > i.e. It's not a problem if I stick to entries made up of objectClasses > > that are part of the 'Bootstrap Schema' > > > > To re-create this, simply used the LDIF I have embedded in this mail and > > create a child entry of class: ssoApplicationAssociation beneath > > uid=admin,ou=system (The LDIF was creating using LDAP Studio from the > > attached 'OpenLDAP Style' Schema.) > > > > Is this a defect, has a JIRA entry already been created for this? > > > > Many Thanks > > > > Simon Temple > > > > (Using: apacheds-server-1.5.1-setup.exe on Windows 2003 Server using > > jdk1.5.0_11) > > > > ---------------------------------- > > test.ldif---------------------------------- > > # test > > # Generated by LDAP Studio on 19 December 2007 12:41:08 > > > > dn: cn=test, ou=schema > > objectclass: metaSchema > > objectclass: top > > cn: test > > m-dependencies: system > > > > dn: ou=attributeTypes, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: attributetypes > > > > dn: m-oid=1.2.826.0.1.2221664.8.1.8, ou=attributeTypes, cn=test, > > ou=schema > > objectclass: metaAttributeType > > objectclass: metaTop > > objectclass: top > > m-oid: 1.2.826.0.1.2221664.8.1.8 > > m-name: aid > > m-name: applicationId > > m-description: Application identifier > > m-equality: caseIgnoreMatch > > m-substr: caseIgnoreSubstringsMatch > > m-syntax: 1.3.6.1.4.1.1466.115.121.1.15 > > > > dn: ou=comparators, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: comparators > > > > dn: ou=ditContentRules, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: ditcontentrules > > > > dn: ou=ditStructureRules, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: ditstructurerules > > > > dn: ou=matchingRules, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: matchingrules > > > > dn: ou=matchingRuleUse, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: matchingruleuse > > > > dn: ou=nameForms, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: nameforms > > > > dn: ou=normalizers, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: normalizers > > > > dn: ou=objectClasses, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: objectClasses > > > > dn: m-oid=1.2.826.0.1.2221664.8.2.4, ou=objectClasses, cn=test, > > ou=schema > > objectclass: metaObjectClass > > objectclass: metaTop > > objectclass: top > > m-oid: 1.2.826.0.1.2221664.8.2.4 > > m-name: ssoApplicationAssociation > > m-description: Single Sign On Application Association > > m-supObjectClass: top > > m-must: applicationId > > > > dn: ou=syntaxCheckers, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: syntaxcheckers > > > > dn: ou=syntaxes, cn=test, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: syntaxes > > ---------------------------------- > > test.schema---------------------------------- > > # test > > # Generated by LDAP Studio on 19 December 2007 12:21:37 > > > > attributetype ( 1.2.826.0.1.2221664.8.1.8 > > NAME ( 'aid' 'applicationId' ) > > DESC 'Application identifier' > > EQUALITY caseIgnoreMatch > > SUBSTR caseIgnoreSubstringsMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > > ) > > > > objectclass ( 1.2.826.0.1.2221664.8.2.4 > > NAME 'ssoApplicationAssociation' > > DESC 'Single Sign On Application Association' > > SUP top > > STRUCTURAL > > MUST applicationId > > ) > > > >
