On Dec 21, 2007 7:09 AM, <Simon.Temple@saaconsultants.com> 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" <dev@directory.apache.org>
cc:
From: "Alex Karasulu" <akarasulu@apache.org>
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, <Simon.Temple@saaconsultants.com> 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
 )