Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-M12
    • Fix Version/s: 1.0.0-M29
    • Labels:
      None
    • Environment:
      Linux

      Description

      $ cat t.ldif
      dn: cn=DeviceTypes,cn=SDT,cn=prod_81,o=myconfiguration
      cn: DeviceTypes
      javaClassName: java.lang.String
      myconfigstringvalue: P:Phone (except BlackBerry)
      myconfigstringvalue:: WjpCbGFja0JlcnJ5w4LCrg==
      myconfigstringvalue: 3:Internet only device
      objectClass: top
      objectClass: javaobject
      objectClass: myconfigstringvaluedobject
      

      Code:

      LdifReader lr = new LdifReader(fileName);
      while (lr.hasNext()) {
          LdifEntry e = lr.next();
          System.out.println(e.toString());
      }
      

      The attribute "myconfigstringvalue:: WjpCbGFja0JlcnJ5w4LCrg==" missed.

        Activity

        Hide
        allen.zhao@telus.com Allen Zhao added a comment - - edited

        Here is what I found. Not sure this is the design or bug.

        If the the later attribute value has incompatible type, it will be ignored.

        org.apache.directory.shared.ldap.model.entry.DefaultAttribute
        Line: 1140
        if ( !isHR )
        {
        Line: 1167
        // We can't add Binary values into a String Attribute
        LOG.info( I18n.err( I18n.ERR_04451 ) );

        So the following entry pass the test.But all myconfigstringvalue base64 encoded.
        dn: cn=DeviceTypes,cn=SDT,cn=prod_81,o=myconfiguration
        cn: DeviceTypes
        javaClassName: java.lang.String
        myconfigstringvalue:: WjpCbGFja0JlcnJ5w4LCrg==
        myconfigstringvalue: P:Phone (except BlackBerry)
        myconfigstringvalue: 3:Internet only device
        objectClass: top
        objectClass: javaobject
        objectClass: myconfigstringvaluedobject

        Show
        allen.zhao@telus.com Allen Zhao added a comment - - edited Here is what I found. Not sure this is the design or bug. If the the later attribute value has incompatible type, it will be ignored. org.apache.directory.shared.ldap.model.entry.DefaultAttribute Line: 1140 if ( !isHR ) { Line: 1167 // We can't add Binary values into a String Attribute LOG.info( I18n.err( I18n.ERR_04451 ) ); So the following entry pass the test.But all myconfigstringvalue base64 encoded. dn: cn=DeviceTypes,cn=SDT,cn=prod_81,o=myconfiguration cn: DeviceTypes javaClassName: java.lang.String myconfigstringvalue:: WjpCbGFja0JlcnJ5w4LCrg== myconfigstringvalue: P:Phone (except BlackBerry) myconfigstringvalue: 3:Internet only device objectClass: top objectClass: javaobject objectClass: myconfigstringvaluedobject
        Hide
        elecharny Emmanuel Lecharny added a comment -

        The problem is that the value is considered as binary as soon as there is a '::' after the AttributeType. Now, when you have many values, teh first one which is parsed will give a type to the ATtribteType : either String or Binary. Now, if th AT is declared as String, any Binary value will simply be discarded...

        We certainly should try to convert the byte[] to a String instead of discarding the value... But what if we encounter a binary value and then some Strings ? Should we consider the whole AttributeType as a String ?

        Not simple...

        The best would be to have a SchemaAware LDIFReader, which gets the AT type directly from the Schema. We could perfectly whip such a feature.

        Thanks for the interesting report !

        Show
        elecharny Emmanuel Lecharny added a comment - The problem is that the value is considered as binary as soon as there is a '::' after the AttributeType. Now, when you have many values, teh first one which is parsed will give a type to the ATtribteType : either String or Binary. Now, if th AT is declared as String, any Binary value will simply be discarded... We certainly should try to convert the byte[] to a String instead of discarding the value... But what if we encounter a binary value and then some Strings ? Should we consider the whole AttributeType as a String ? Not simple... The best would be to have a SchemaAware LDIFReader, which gets the AT type directly from the Schema. We could perfectly whip such a feature. Thanks for the interesting report !
        Hide
        allen.zhao@telus.com Allen Zhao added a comment -

        I understand the scenario. I tested other LDAP api, seems they could handle this situation. I noticed that, internally, they convert the whole attribute to binary (if any value is binary), but when "print out", e.g. toString() or String getValue() in both entry and attribute, it try to convert the value to string if the value is HR. Not sure this is doable in your code.

        BTW: I am very interesting the SchemaAware LDIFReader. But I could not find it in your API doc. If you have it, please let me know.

        Thanks a lot,

        Show
        allen.zhao@telus.com Allen Zhao added a comment - I understand the scenario. I tested other LDAP api, seems they could handle this situation. I noticed that, internally, they convert the whole attribute to binary (if any value is binary), but when "print out", e.g. toString() or String getValue() in both entry and attribute, it try to convert the value to string if the value is HR. Not sure this is doable in your code. BTW: I am very interesting the SchemaAware LDIFReader. But I could not find it in your API doc. If you have it, please let me know. Thanks a lot,
        Hide
        allen.zhao@telus.com Allen Zhao added a comment -

        I understand the scenario. I tested some other LDAP apis, seems they could handle this scenario. I noticed that, internally, they convert the whole attribute to binary (if any value is binary), but when "print out", e.g. toString() or String getValue() at both entry and attribute level, it try to convert the value to string if the value is HR. Not sure this is doable in your code.

        BTW: I am very interesting the SchemaAware LDIFReader. But I could not find it in your API doc. If you have it, please let me know.

        Thanks a lot,

        Allen

        Show
        allen.zhao@telus.com Allen Zhao added a comment - I understand the scenario. I tested some other LDAP apis, seems they could handle this scenario. I noticed that, internally, they convert the whole attribute to binary (if any value is binary), but when "print out", e.g. toString() or String getValue() at both entry and attribute level, it try to convert the value to string if the value is HR. Not sure this is doable in your code. BTW: I am very interesting the SchemaAware LDIFReader. But I could not find it in your API doc. If you have it, please let me know. Thanks a lot, Allen
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Fixed with http://svn.apache.org/r1665426

        We now set the HR flag accordingly to the first seen value, and convert the bytes too.

        Show
        elecharny Emmanuel Lecharny added a comment - Fixed with http://svn.apache.org/r1665426 We now set the HR flag accordingly to the first seen value, and convert the bytes too.

          People

          • Assignee:
            Unassigned
            Reporter:
            allen.zhao@telus.com Allen Zhao
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development