directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon.Tem...@saaconsultants.com
Subject Re: Possible defect in 1.5.1: error code 54 - failed on search operation
Date Fri, 21 Dec 2007 12:09:29 GMT
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?

- SimonT

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 
 )
Mime
View raw message