|
Assigning this to Emmanuel who is already working on it.
This pb is due to a new String(xxx) done on the value.
We have to check the attribute's type to see if it's a binary attribute or a String, so we have to check the attribute agaisnt the Schema (RFC 2252 : 4.3.2. Syntax Object Identifiers) I expect a patch to be submitted soon. Attribute values are generally stored as String. This is a major problem for binary attributes, as we loose information (jpegPhoto for instance).
here is an exemple of code where this problem occurs : org.apache.ldap.common.berlib.asn1.decoder.compare.CompareAVARule { ... public void finish() { // pop the ByteBuffer the super method pushed ByteBuffer buf = ( ByteBuffer ) getDigester().pop() ; // peek at the CompareRequest underneath whose name we set CompareRequest req = ( CompareRequest ) getDigester().peek() ; byte[] octets = null ; if ( buf.limit() == buf.capacity() && buf.hasArray() ) { // use the backing store octets = buf.array() ; } else { // copy because we don't have accessible array or data < array octets = new byte[buf.remaining()] ; buf.get( octets ) ; } if ( req.getAttributeId() == null ) { req.setAttributeId( new String( octets ) ) ; } else { req.setAssertionValue( new String( octets ) ) ; } } The "new String(octets)" is destructing when applied to binary values. Figured I can assign this to you since you're working on it already.
I think we can close this but let's get some confirmation.
I have created a new test case in the testsuite to demonstrate that this problem does not occur anymore:
http://svn.apache.org/viewcvs.cgi?rev=330524&view=rev It creates (inetOrg)person entries with userPassword and jpegPhoto attributes, one method is exactly the one already attached here. Afterwards it reads the entries and checks whether the data has been modified by the server (as described in the issue here). If I use the current server.xml from here http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/main/server.xml the test is successful (it is not for 0.9.3, therefore the test is ok, I think). I was also able to use Softerra LDAP Administrator and attach my photo to an inetOrgPerson entry via its UI functionality. What a beautiful me, the image is not corrupted if I read it back. That didn't work in previous versions, as well. I still face problems if I do not use the server.xml described above, but start the server main without configuration (i.e. the default config from the jar is used). The test case above fails. I have to figure out, what the difference between the configurations is ... Anyway, Great work, Emmanuel + Alex! This was my favorite error for ages ... Alex had the following idea in an IRC:
Rather than doing definition of binary attributes via configuration we can at the startup of the server scan all the schema looking for binary attributes, then we can assemble this information. This would help people not to forget defining there attributes as binary in two places (schema + configuration). I finished up this enhancement on commit 330978. Now the server uses the schema to set the value for this binary attribute. It will also merge attributes if users provide this in the server.xml to force the treatment of non-binary attributes as binary.
Closing all issues created in 2005 and before which are marked resolved
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Therfore I created a testcase (attached). It opens a JNDI connection, adds a person entry with 64k random binary data for attribute jpegPhoto, reads it out again and compares the binary data byte by byte.
It fails with
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))
Testcase is attached and works for other directory solutions, e.g. Sun Java System Directory Server 5.2