Issue #57 has been updated by Jonathan Clarke.
J?r?me Schell wrote: > Ok, I think I've got it ;) > > The corruption appears in the method compareAttribute of the BeanComparator > class: > [...] > > The use of "new String((byte[]) o)" seems to kill the binary attributes. Aha. I remember this - it was a fix for issue #45... which needed to read userPassword (which is binary syntax) as a String. I guess we need some kind of parameter to specify how to treat each attribute - ie "this is real binary, use byte[]" or "this should be a String, do new String(the attribute value)". Comments ? I have the feeling that bug #55 may be related to this as well... ---------------------------------------- Bug #57: db2ldap : Binary attribute seems to be corrupted http://tools.lsc-project.org/issues/show/57 Author: J?r?me Schell Status: New Priority: Normal Assigned to: Category: Core Target version: I am in the process of syncing a MySQL database with an openldap directory. In the MySQL table, there is a blob containing a JPEG picture of the person. The SQL field is mapped directly to the jpegPhoto LDAP attribute like that: <pre> <result property="jpegPhoto" column="photo"/> </pre> The synchronization process is working fine except that the JPEG in the LDAP directory seems to be invalid. An export of the field is not a valid JPEG file and no LDAP browser displays the picture correctly. It seems that binary attributes should be handled differently than others. See that "forum post":http://www.velocityreviews.com/forums/t139104-ldap-character-encoding.html for information about this. The parameter "java.naming.ldap.attributes.binary" should contain a list of LDAP attributes to be handled as binary. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://tools.lsc-project.org/my/account -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lsc-project.org/pipermail/lsc-dev/attachments/20090604/0b5d2607/attachment.htm>
