Hi all!

I have a problem with binary data within directory entries. If I import an inetOrgPerson with jpegPhoto into the Apache DS (LDIF format, binary data is Base64), the image data is damaged in the entry (at least when it is read out). I tried different tools (import with LDAP Administrator from Softerra, native ldapadd from Solaris 9, ...) the result was always the same. Wenn I import the same file in another Directory Server (e.g. OpenLDAP), it works fine.

I decided to check it with a little TestCase that uses JNDI to write some random binary data to the directory, read it back and check whether everything is ok.
My test looked like this:

package simple;

import java.util.Random;

import javax.naming.NamingException;
import javax.naming.directory.Attribute;
import javax.naming.directory.Attributes;
import javax.naming.directory.BasicAttribute;
import javax.naming.directory.BasicAttributes;
import javax.naming.directory.DirContext;
import javax.naming.directory.InitialDirContext;

import junit.framework.TestCase;

public class BinaryTest extends TestCase {

    public static String TORI_DN = "cn=Tori Amos";

    DirContext ctx;

    protected void setUp() throws Exception {
        ctx = new InitialDirContext();
    }

    public void testToriWithFunData() throws NamingException {

        // Create attributes for test entry
        Attribute ocls = new BasicAttribute("objectclass");
        ocls.add("top");
        ocls.add("person");
        ocls.add("organizationalPerson");
        ocls.add("inetOrgPerson");
        Attributes attrs = new BasicAttributes();
        attrs.put(ocls);
        attrs.put("sn", "Amos");
        attrs.put("cn", "Tori Amos");
       
        // Random data for jpegPhoto, 64k
        byte[] sourceData = new byte[64 * 1024];
        Random r = new Random(0);
        for (int i = 0; i < sourceData.length; i++) {
            sourceData[i] = (byte) r.nextInt();
        }
        attrs.put("jpegPhoto", sourceData);
       
        // Create entry
        ctx.bind(TORI_DN, null, attrs);

        // Read same entry and compare data bytewise
        Attributes readAttrs = ctx.getAttributes(TORI_DN);
        Attribute image = readAttrs.get("jpegPhoto");
        byte[] imageBytes = (byte[]) image.get();        
        for (int i = 0; i < imageBytes.length; i++) {
            assertEquals("Byte number " + i, sourceData[i], imageBytes[i]);
        }
    }

    protected void tearDown() throws Exception {
        // Try to delete Entry
        ctx.destroySubcontext(TORI_DN);
    }

}

My jndi.properties looked like this:

java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory

# Apache@magritte
java.naming.provider.url=ldap://magritte:10389/ou=system
java.naming.security.principal=uid=admin,ou=system
java.naming.security.credentials=******
java.naming.security.authentication=simple

I'm not sure whether this is comparable to my original LDIF-Problem. But at least the test fails with Apache DS 0.9.1:

junit.framework.AssertionFailedError: Byte number 47 expected:<-112> but was:<63>
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.failNotEquals(Assert.java:282)
        at junit.framework.Assert.assertEquals(Assert.java:64)
        at junit.framework.Assert.assertEquals(Assert.java:162)
        at simple.BinaryTest.testToriWithFunData(BinaryTest.java(Compiled Code))

The same test works with Sun Java System Directory Server 5.2, for example (I checked other LDAP servers as well). It also works if I only write zeros in the array ...
I do not know whether it is stored wrong in the directory, Or if the read operation fails. This would be an interesting thing to check out, I guess ...

Any suggestions? Configuration error? I used the default server.xml from svn and ApacheDS 0.9.1 on a Windows XP workstation (JDK 1.5.0_3), Client was Softerra@WindowsXP and ldapadd@Solaris9/SPARC.

Should I open a bug at JIRA? I volunteer for further investigation on this (I'm quit interested in images within my entries ;-). But I need some clues where to look (until now I only touched the surface of your directory server).

Greetings from Hamburg,
    Stefan