| Emmanuel Lecharny (JIRA) 2007-11-21, 7:11 am |
|
[ 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 accept=
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 arra=
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.
|