Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <9074521.1195640083188.JavaMail.jira@brutus>
Date: Wed, 21 Nov 2007 02:14:43 -0800 (PST)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIRSERVER-1104) Mixing Attribute value types
 results in write failures
In-Reply-To: <4141152.1195618362988.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DIRSERVER-1104?page=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:: Y249QmFkIEXDqWvDoCxvdT1wZW9wbGUsbz1zZXZlblNlYXM=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.