Directory ApacheDS
  1. Directory ApacheDS
  2. DIRSERVER-1732

ERR_04131 The value is expected to be a String

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M6
    • Fix Version/s: 2.0.0-M8
    • Component/s: core
    • Labels:
      None
    • Environment:

      Description

      The server simply crashes, cannot start with the following errors.
      It doesn't mean exactly what value, and from where, which is "expected to be a String".
      It would be helpful to mention where, which value, and from what file it is failing.
      Probably it's a data corruption with one file or just a few files.

      INFO | jvm 1 | 2012/06/07 13:22:17 | [13:22:17] ERROR [org.apache.directory.shared.ldap.model.entry.DefaultAttribute] - ERR_04131 The value is expected to be a String
      INFO | jvm 1 | 2012/06/07 13:22:17 | [13:22:17] ERROR [org.apache.directory.server.wrapper.ApacheDsTanukiWrapper] - Failed to start the service.
      INFO | jvm 1 | 2012/06/07 13:22:17 | org.apache.directory.shared.ldap.model.exception.LdapInvalidAttributeValueException: ERR_04131 The value is expected to be a String
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.model.entry.DefaultAttribute.getString(DefaultAttribute.java:529)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemaloader.SchemaEntityFactory.setSchemaObjectProperties(SchemaEntityFactory.java:1072)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemaloader.SchemaEntityFactory.getAttributeType(SchemaEntityFactory.java:977)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemamanager.impl.DefaultSchemaManager.addAttributeTypes(DefaultSchemaManager.java:791)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemamanager.impl.DefaultSchemaManager.addSchemaObjects(DefaultSchemaManager.java:258)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemamanager.impl.DefaultSchemaManager.load(DefaultSchemaManager.java:744)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemamanager.impl.DefaultSchemaManager.loadDepsFirst(DefaultSchemaManager.java:1169)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemamanager.impl.DefaultSchemaManager.loadWithDeps(DefaultSchemaManager.java:1094)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.shared.ldap.schemamanager.impl.DefaultSchemaManager.loadAllEnabled(DefaultSchemaManager.java:984)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.server.ApacheDsService.initSchemaManager(ApacheDsService.java:229)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:164)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.start(ApacheDsTanukiWrapper.java:72)
      INFO | jvm 1 | 2012/06/07 13:22:17 | at org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)
      STATUS | wrapper | 2012/06/07 13:22:19 | <-- Wrapper Stopped

        Activity

        Hide
        Emmanuel Lecharny added a comment -

        Sorry for the long delay...

        Fixed with http://svn.apache.org/viewvc?rev=1393189&view=rev

        When an Human Readable Attribute contains a base 64 encoded value, then it is read as a binary value. It has to be transformed into a String value, something that was not done.

        Show
        Emmanuel Lecharny added a comment - Sorry for the long delay... Fixed with http://svn.apache.org/viewvc?rev=1393189&view=rev When an Human Readable Attribute contains a base 64 encoded value, then it is read as a binary value. It has to be transformed into a String value, something that was not done.
        Hide
        Emmanuel Lecharny added a comment -

        Ok, now we have a reproductible use case ! I'll try to investigate the issue this week-end.

        Many thanks for having chased the bug, and for your patience !

        Show
        Emmanuel Lecharny added a comment - Ok, now we have a reproductible use case ! I'll try to investigate the issue this week-end. Many thanks for having chased the bug, and for your patience !
        Hide
        Hendy Irawan added a comment -

        It's probably due to CR/LF.

        Desciption contains CR/LF, this will import into ApacheDS but then breaks it upon restart (always reproducible!)

        ceefour@annafi:~/git/soluvas-framework/ldap-schema$ grep -r description:: . -C3
        ./socialperson.ldif-objectclass: top
        ./socialperson.ldif-m-oid: 2.25.31030703689307962575270284666844839901.16
        ./socialperson.ldif-m-name: canonicalIdentifier
        ./socialperson.ldif:m-description:: Q2Fub25pY2FsIGlkZW50aWZpZXIsIGllLiB3aXRob3V0IHNwZWNpYWwgY2hhcmFj
        ./socialperson.ldif- dGVyIG9yIHNlcGFyYXRvcnMuCkZvciBleGFtcGxlIHRoZSBjYW5vbmljYWwgaWRlbnRpZmllciBvZiB
        ./socialperson.ldif- hcnVtLnB1c3BpdGEgaXMgYXJ1bXB1c3BpdGEu
        ./socialperson.ldif-m-equality: caseExactMatch

        Then I change so it won't use CR/LF:

        ceefour@annafi:~/git/soluvas-framework/ldap-schema$ grep -r description:: . -C3
        ceefour@annafi:~/git/soluvas-framework/ldap-schema$ grep -r canonicalIdentifier . -C3
        ./socialperson.ldif-objectclass: metaTop
        ./socialperson.ldif-objectclass: top
        ./socialperson.ldif-m-oid: 2.25.31030703689307962575270284666844839901.16
        ./socialperson.ldif:m-name: canonicalIdentifier
        ./socialperson.ldif-m-description: Canonical identifier, ie. without special character or separators
        ./socialperson.ldif- . For example the canonical identifier of arum.puspita is arumpuspita.
        ./socialperson.ldif-m-equality: caseExactMatch

        BTW you can find the complete sample for the schema that breaks ApacheDS here: https://github.com/soluvas/soluvas-framework/commit/a0cd04f5902a0356ea4911ea92bb55dd9a36351b

        Show
        Hendy Irawan added a comment - It's probably due to CR/LF. Desciption contains CR/LF, this will import into ApacheDS but then breaks it upon restart (always reproducible!) ceefour@annafi:~/git/soluvas-framework/ldap-schema$ grep -r description:: . -C3 ./socialperson.ldif-objectclass: top ./socialperson.ldif-m-oid: 2.25.31030703689307962575270284666844839901.16 ./socialperson.ldif-m-name: canonicalIdentifier ./socialperson.ldif:m-description:: Q2Fub25pY2FsIGlkZW50aWZpZXIsIGllLiB3aXRob3V0IHNwZWNpYWwgY2hhcmFj ./socialperson.ldif- dGVyIG9yIHNlcGFyYXRvcnMuCkZvciBleGFtcGxlIHRoZSBjYW5vbmljYWwgaWRlbnRpZmllciBvZiB ./socialperson.ldif- hcnVtLnB1c3BpdGEgaXMgYXJ1bXB1c3BpdGEu ./socialperson.ldif-m-equality: caseExactMatch Then I change so it won't use CR/LF: ceefour@annafi:~/git/soluvas-framework/ldap-schema$ grep -r description:: . -C3 ceefour@annafi:~/git/soluvas-framework/ldap-schema$ grep -r canonicalIdentifier . -C3 ./socialperson.ldif-objectclass: metaTop ./socialperson.ldif-objectclass: top ./socialperson.ldif-m-oid: 2.25.31030703689307962575270284666844839901.16 ./socialperson.ldif:m-name: canonicalIdentifier ./socialperson.ldif-m-description: Canonical identifier, ie. without special character or separators ./socialperson.ldif- . For example the canonical identifier of arum.puspita is arumpuspita. ./socialperson.ldif-m-equality: caseExactMatch BTW you can find the complete sample for the schema that breaks ApacheDS here: https://github.com/soluvas/soluvas-framework/commit/a0cd04f5902a0356ea4911ea92bb55dd9a36351b
        Hide
        Hendy Irawan added a comment -

        Yes, the Schema project is created with Apache Directory Studio 1.5.3, and also exported to LDIF by it.

        Show
        Hendy Irawan added a comment - Yes, the Schema project is created with Apache Directory Studio 1.5.3, and also exported to LDIF by it.
        Hide
        Kiran Ayyagari added a comment -

        On a different note, was this schema generated using Apache Directory Studio? I know Studio sometimes generates
        a Base64 encoded value in LDIF for a human readable attribute value

        Show
        Kiran Ayyagari added a comment - On a different note, was this schema generated using Apache Directory Studio? I know Studio sometimes generates a Base64 encoded value in LDIF for a human readable attribute value
        Hide
        Hendy Irawan added a comment -

        trigger the bug

        Show
        Hendy Irawan added a comment - trigger the bug
        Hide
        Hendy Irawan added a comment -

        The whole attributetype :

        ceefour@annafi:/var/lib/apacheds-2.0.0-M7/default$ git cat-file -p 7fd20c071d1b4f645c13d0a2efebcdfeda75e05b
        dn: m-oid=2.25.31030703689307962575270284666844839901.12, ou=attributeTypes, cn=
        socialperson, ou=schema
        m-length: 0
        m-oid: 2.25.31030703689307962575270284666844839901.12
        m-name: birthDate
        m-description:: QWNjb3VudCBvd25lcidzIGRhdGUgb2YgYmlydGguIA==
        m-equality: generalizedTimeMatch
        entryParentId: 1358
        m-ordering: generalizedTimeOrderingMatch
        m-singleValue: TRUE
        createTimestamp: 20120628102624Z
        m-syntax: 1.3.6.1.4.1.1466.115.121.1.24
        objectclass: metaTop
        objectclass: metaAttributeType
        objectclass: top
        entryUUID: 534852c7-0202-40b1-834a-41d96bf74d79
        creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
        entryCSN: 20120628102624.537000Z#000000#000#000000

        Show
        Hendy Irawan added a comment - The whole attributetype : ceefour@annafi:/var/lib/apacheds-2.0.0-M7/default$ git cat-file -p 7fd20c071d1b4f645c13d0a2efebcdfeda75e05b dn: m-oid=2.25.31030703689307962575270284666844839901.12, ou=attributeTypes, cn= socialperson, ou=schema m-length: 0 m-oid: 2.25.31030703689307962575270284666844839901.12 m-name: birthDate m-description:: QWNjb3VudCBvd25lcidzIGRhdGUgb2YgYmlydGguIA== m-equality: generalizedTimeMatch entryParentId: 1358 m-ordering: generalizedTimeOrderingMatch m-singleValue: TRUE createTimestamp: 20120628102624Z m-syntax: 1.3.6.1.4.1.1466.115.121.1.24 objectclass: metaTop objectclass: metaAttributeType objectclass: top entryUUID: 534852c7-0202-40b1-834a-41d96bf74d79 creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system entryCSN: 20120628102624.537000Z#000000#000#000000
        Hide
        Hendy Irawan added a comment -

        Probably due to ' (apostrophe) character in description.

        Show
        Hendy Irawan added a comment - Probably due to ' (apostrophe) character in description.
        Hide
        Emmanuel Lecharny added a comment -

        This is weird...

        The stored value is "Account owner's date of birth. ". There is absolutely no reason for this value to be base64 encoded... Moreover, I can't see how this can impact the server (it's just a description)

        Can you provide the full LDIF for this attributeType so that we can run a test ?

        Show
        Emmanuel Lecharny added a comment - This is weird... The stored value is "Account owner's date of birth. ". There is absolutely no reason for this value to be base64 encoded... Moreover, I can't see how this can impact the server (it's just a description) Can you provide the full LDIF for this attributeType so that we can run a test ?
        Hide
        Hendy Irawan added a comment -

        This is the culprit and workaround :

        diff --git a/default/partitions/schema/ou=schema/cn=socialperson/ou=attributetypes/m-oid=2.25.31030703689307962575270284666844839901.12.
        index ef5f5b3..7d92735 100644
        — a/default/partitions/schema/ou=schema/cn=socialperson/ou=attributetypes/m-oid=2.25.31030703689307962575270284666844839901.12.ldif
        +++ b/default/partitions/schema/ou=schema/cn=socialperson/ou=attributetypes/m-oid=2.25.31030703689307962575270284666844839901.12.ldif
        @@ -3,7 +3,6 @@ dn: m-oid=2.25.31030703689307962575270284666844839901.12, ou=attributeTypes, cn=
        m-length: 0
        m-oid: 2.25.31030703689307962575270284666844839901.12
        m-name: birthDate
        -m-description:: QWNjb3VudCBvd25lcidzIGRhdGUgb2YgYmlydGguIA==
        entryParentId: 1358
        m-singleValue: TRUE
        createTimestamp: 20120628102624Z

        It is the "m-description" field. For some reason it's not a normal string but an encoded one.

        Deleting the m-description line makes ApacheDS happy again

        Strange thing is that ApacheDS happily accepts it (the schema) during import and continue to operate normally. But crashes right after restart.

        Show
        Hendy Irawan added a comment - This is the culprit and workaround : diff --git a/default/partitions/schema/ou=schema/cn=socialperson/ou=attributetypes/m-oid=2.25.31030703689307962575270284666844839901.12. index ef5f5b3..7d92735 100644 — a/default/partitions/schema/ou=schema/cn=socialperson/ou=attributetypes/m-oid=2.25.31030703689307962575270284666844839901.12.ldif +++ b/default/partitions/schema/ou=schema/cn=socialperson/ou=attributetypes/m-oid=2.25.31030703689307962575270284666844839901.12.ldif @@ -3,7 +3,6 @@ dn: m-oid=2.25.31030703689307962575270284666844839901.12, ou=attributeTypes, cn= m-length: 0 m-oid: 2.25.31030703689307962575270284666844839901.12 m-name: birthDate -m-description:: QWNjb3VudCBvd25lcidzIGRhdGUgb2YgYmlydGguIA== entryParentId: 1358 m-singleValue: TRUE createTimestamp: 20120628102624Z It is the "m-description" field. For some reason it's not a normal string but an encoded one. Deleting the m-description line makes ApacheDS happy again Strange thing is that ApacheDS happily accepts it (the schema) during import and continue to operate normally. But crashes right after restart.
        Hide
        Rudi Wijaya added a comment -

        Data files that trigger this problem.

        Show
        Rudi Wijaya added a comment - Data files that trigger this problem.

          People

          • Assignee:
            Unassigned
            Reporter:
            Rudi Wijaya
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development