directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: Possible defect in 1.5.1: error code 54 - failed on search operation
Date Fri, 21 Dec 2007 16:08:42 GMT
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
> >  )
> >
>
>

Mime
View raw message