[
https://issues.apache.org/jira/browse/DIRSERVER-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544164
]
Alex Karasulu commented on DIRSERVER-1104:
------------------------------------------
I went in to fix this thinking it would be simple and ran into all these
problems:
(1) Why was the serialization structure of the partition changed? We are now
storing an extra byte at the beginning of a value to indicate that it is a
byte[] or a String.
The presumption that all values of an attribute are either a byte[] or a String
is incorrect so doing this is a problem unless we can convert the value to the
proper format correctly by considering the syntax of the value. This however
is not a simple matter. There may be no way this far into the persistence code
to determine the syntax associated with a value being persisted. This
alteration was a bad move IMHO and screws us a bit.
(2) Why has all this code been moved to ldap-shared when it deals specifically
with the serialization mechanism used by the JDBM partition implementation?
Too many things are being put into the ldap-shared module. It's a jumbled up
mess in there and it's only getting bigger. Only put things into shared if it
really can be reused. This very specific serialization mechanism may not be.
> Mixing Attribute value types results in write failures
> ------------------------------------------------------
>
> Key: DIRSERVER-1104
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1104
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
> Affects Versions: bigbang, 1.5.1
> Reporter: Alex Karasulu
> Assignee: Alex Karasulu
> Priority: Blocker
> Fix For: bigbang
>
> Attachments: error.log, offending.ldif
>
>
> This new bug is really serious and tricky. It has eluded us but comes out now
> thanks to a crazy size effect it has on Windows.
> First a characterization of the bug. An entry (Attributes object) may be
> valid and still contain an Attribute which has both byte[] and String array
> values. Some may suggest that this is invalid since attributes are,
> according to their syntax, either binary of human readable. However this is
> not the case. The fact that an attributeType is human readable has no
> bearing on how the user supplies the value. Human readable data can be
> provided as binary information so long as it still conforms to the syntax of
> the attribute.
> Here's an example entry which would cause such a failure:
> dn: cn=person1,ou=system
> objectClass: organizationalPerson
> cn: person1
> sn: sn_person1
> seealso: cn=Good One,ou=people,o=sevenSeas
> seealso:: Y249QmFkIEXDqWvDoCxvdT1wZW9wbGUsbz1zZXZlblNlYXM=
> This entry will cause the AttributeSerializerUtils.serialize() method to blow
> a ClassCastException. Note the log of the error can be found attached to
> this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
