[ https://issues.apache.org/jira/brow...ge=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544402 ]=
=20

Emmanuel Lecharny commented on DIRSERVER-1104:
----------------------------------------------

I have added this byte in front of each value because I needed to know whic=
h kind of value it was : String or byte[]. It's mandatory unless you acc
ept=
to have classCast exceptions.

Now, from the server POV, values are supposed to be H/R or not. If they are=
H/R (and the schema nows about it), values are stored as Strings. If not, =
they are stored as byte[]. If a value is not H/R and you pass a String, 
we =
convert the String to a byte[] before storing it.

If you try to import a LDIF into the server, as it goes through the chain, =
it should be the same.

In your sample, the seealso field contains a base64 encoded DN :
cn=3DBad E=C3=83=C2=A9k=C3=83 ,ou=3Dpeople,o=3DsevenSeas

This is another problem which should be handled differently (seems to me th=
at the DN syntax checker is not strict enough ...)

No need to change all the server logic to fix such a problem. It will be ch=
anged anyway when we will use Value instead of byte[] or Strings.

We can move back the serializers to another place, close to JDBM, sure. It =
has been moved close to the place where those attributes where defined.

I would not do that right now as we will have a new sub-project (server-ent=
ry) where we will have all those classes.

> 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: Emmanuel Lecharny
>            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. =20
> First a characterization of the bug.  An entry (Attributes object) may be=
valid and still contain an Attribute which has both byte[] and String ar
ra=
y values.  Some may suggest that this is invalid since attributes are, acco=
rding to their syntax, either binary of human readable.  However this is no=
t the case.  The fact that an attributeType is human readable has no bearin=
g 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 att=
ribute.
> Here's an example entry which would cause such a failure:
>     dn: cn=3Dperson1,ou=3Dsystem
>     objectClass: organizationalPerson
>     cn: person1
>     sn: sn_person1
>     seealso: cn=3DGood One,ou=3Dpeople,o=3DsevenSeas
>     seealso::  Y249QmFkIEXDqWvDoCxvdT1wZW9wbGUsbz1zZXZl
blNlYXM=3D
> 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. =20

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[ Post a follow-up to this message ]