From dev-return-39906-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Jan 3 08:53:45 2012 Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 94F4E956A for ; Tue, 3 Jan 2012 08:53:45 +0000 (UTC) Received: (qmail 24770 invoked by uid 500); 3 Jan 2012 08:53:43 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 24533 invoked by uid 500); 3 Jan 2012 08:53:20 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 24525 invoked by uid 99); 3 Jan 2012 08:53:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jan 2012 08:53:14 +0000 X-ASF-Spam-Status: No, hits=4.6 required=5.0 tests=HTML_MESSAGE,MANY_SPAN_IN_TEXT,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of pajbam@gmail.com designates 209.85.212.178 as permitted sender) Received: from [209.85.212.178] (HELO mail-wi0-f178.google.com) (209.85.212.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jan 2012 08:53:07 +0000 Received: by wibhi5 with SMTP id hi5so11666577wib.37 for ; Tue, 03 Jan 2012 00:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=n8osSzR4XeHUGgt4jUc1BtmddCjEChF4ixSDts/vQUM=; b=D/IWAL12Frb37rmmcIxRKKKgy6VX+afcQC7NkFECDtREMBZjEmK/pcwhW0WH5uLCLU UtKWeK8RjxV72AzLRNlVIerKlEcWr8ingcI32M1eifaexSVaCISzEltvnmDd2Di3LCu6 N0gFYgP1W47D+TWYQ7GNXjJv4qDPE6TH4dGCw= Received: by 10.180.90.40 with SMTP id bt8mr112587945wib.4.1325580765648; Tue, 03 Jan 2012 00:52:45 -0800 (PST) Received: from [10.0.1.7] (def92-4-82-225-58-213.fbx.proxad.net. [82.225.58.213]) by mx.google.com with ESMTPS id g12sm58118752wiw.10.2012.01.03.00.52.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 00:52:44 -0800 (PST) Sender: Pierre-Arnaud Marcelot From: Pierre-Arnaud Marcelot Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_98E56F46-54C4-45F1-A3F0-0049D369C724" Subject: Re: Server-integ tst faiure : a question Date: Tue, 3 Jan 2012 09:52:42 +0100 In-Reply-To: To: "Apache Directory Developers List" References: <4F024B11.80304@gmail.com> Message-Id: <6D79F1C7-5C1D-4D2A-9505-5B510F712AA5@marcelot.net> X-Mailer: Apple Mail (2.1251.1) --Apple-Mail=_98E56F46-54C4-45F1-A3F0-0049D369C724 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 3 janv. 2012, at 09:01, Pierre-Arnaud Marcelot wrote: >=20 > On 3 janv. 2012, at 08:49, Kiran Ayyagari wrote: >=20 >> On Tue, Jan 3, 2012 at 5:55 AM, Emmanuel Lecharny = wrote: >>> Hi, >>>=20 >>> I'm facing an interesting issue : >>> - we are trying to add a new entry >>> - this entry has a RDN which is a SingleValue AT (DisplayName) >>> - there already is a DisplayName Attribute present >>> - the RDN and the present value are different. >>>=20 >>> Here is the entry : >>> dn: displayName=3Dtest,ou=3Dsystem >>> objectClass: top >>> objectClass: person >>> objectClass: inetOrgPerson >>> objectClass: organizationalPerson >>> displayName: Michael >>> sn: Michael Jackson >>> cn: Jackson >>>=20 >>> (displayName is a SingleValue AT) >>>=20 >>> In trunks, the entry is added, and the existing Attribute is = removed, and >>> replaced by displayName: test >>>=20 >>> In Selcuk's branch, due to some modifications I've done recently in = the way >>> we normalize added entries, we get an exception. >>>=20 >>> Now, it leads a question : should we accept the entry, modifying it = on the >>> fly, or should we reject the addition ? >>>=20 >>> IMHO, I do think that accepting the entry as is would lead to a = violation of >>> the user's will : ie, the risk is that the user has made a mistake = when >>> describing the entry, and should be informed about this mistake, = instead of >>> 'reparing' the mistake. >>>=20 >>> wdyt ? >>>=20 >> +1, it should fail, OTOH I assume that this is already the case when >> added using Studio (haven't tried now, but I remember experiencing >> this situation) >=20 > +1 Quick followup. I did the test with the current Apache Directory Studio (trunk): - On Apache DS (trunk) the addition of the entry is successful. The value used in the DN is chosen and replaces the value in the entry. Here's the LDIF used: > dn: displayName=3Dtest,ou=3Dsystem > objectClass: top > objectClass: person > objectClass: inetOrgPerson > objectClass: organizationalPerson > displayName: Michael > sn: Michael Jackson > cn: Jackson And the output in Studio's Modification Logs view: > #!RESULT OK > #!CONNECTION ldap://localhost:10389 > #!DATE 2012-01-03T08:06:09.661 > dn: displayName=3Dtest,ou=3Dsystem > changetype: add > displayName: Michael > objectClass: top > objectClass: person > objectClass: inetOrgPerson > objectClass: organizationalPerson > sn: Michael Jackson > cn: Jackson - On OpenLDAP (2.4.24) the addition of the entry is not successful. Here's the LDIF used: > dn: c=3DTE,dc=3Dmy-domain,dc=3Dcom > objectClass: top > objectClass: country > c: FR And the output in Studio's Modification Logs view: > #!RESULT ERROR > #!CONNECTION ldap://10.211.55.4:10389 > #!DATE 2012-01-03T08:40:57.117 > #!ERROR [LDAP: error code 64 - value of single-valued naming attribute = 'c' conflicts with value present in entry] > dn: c=3DTE,dc=3Dmy-domain,dc=3Dcom > changetype: add > objectClass: top > objectClass: country > c: FR The result on OpenLDAP makes more sense I guess. > Regards, > Pierre-Arnaud >=20 >>> (FYI, the failing test is in server-integ, AddIT, >>> testAddEntryDifferentRDNSingleValuedInEntry()) >>>=20 >>> -- >>> Regards, >>> Cordialement, >>> Emmanuel L=E9charny >>> www.iktek.com >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Kiran Ayyagari >=20 --Apple-Mail=_98E56F46-54C4-45F1-A3F0-0049D369C724 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On 3 janv. 2012, at 08:49, Kiran Ayyagari = wrote:

On Tue, Jan 3, 2012 at 5:55 AM, = Emmanuel Lecharny <elecharny@gmail.com> = wrote:
Hi,

I'm facing an interesting issue = :
- we are trying to add a new = entry
- this entry has a RDN which is a SingleValue AT = (DisplayName)
- there already is a DisplayName = Attribute present
- the RDN and the present value = are different.

Here is the entry = :
dn: = displayName=3Dtest,ou=3Dsystem
objectClass: = top
objectClass: = person
objectClass: = inetOrgPerson
objectClass: = organizationalPerson
displayName: = Michael
sn: Michael = Jackson
cn: Jackson

(displayName is a SingleValue = AT)

In trunks, the entry is added, = and the existing Attribute is removed, = and
replaced by displayName: = test

In Selcuk's branch, due to some = modifications I've done recently in the = way
we normalize added entries, we get an = exception.

Now, it leads  a question : = should we accept the entry, modifying it on = the
fly, or should we reject the addition = ?

IMHO, I do think that accepting = the entry as is would lead to a violation = of
the user's will : ie, the risk is that the user has made a = mistake when
describing the entry, and should = be informed about this mistake, instead = of
'reparing' the = mistake.

wdyt = ?

+1, = it should fail, OTOH I assume that this is already the case = when
added using Studio = (haven't tried now, but I remember = experiencing
this = situation)

+1

Quick followup.

I did the test with the = current Apache Directory Studio (trunk):

- On = Apache DS (trunk) the addition of the entry is successful.
The = value used in the DN is chosen and replaces the value in the = entry.

Here's the LDIF used:
dn: = displayName=3Dtest,ou=3Dsystem
: top
objectClass: person
objectClass: = inetOrgPerson
objectClass: = organizationalPerson
: Michael
sn: = Michael Jackson
cn: = Jackson

And the = output in Studio's Modification Logs view:
#!RESULT OK
ldap://localhost:10389
#!DATE 2012-01-03T08:06:09.661
: = displayName=3Dtest,ou=3Dsystem
: add
displayName: Michael
: top
objectClass: person
objectClass: = inetOrgPerson
objectClass: = organizationalPerson
sn: = Michael Jackson
cn: = Jackson

- On OpenLDAP = (2.4.24) the addition of the entry is not = successful.

Here's the LDIF = used:
: = c=3DTE,dc=3Dmy-domain,dc=3Dcom
: top
objectClass: country
c: FR
#!RESULT ERROR
#!DATE 2012-01-03T08:40:57.117
#!ERROR [LDAP: error code 64 - value of = single-valued naming attribute 'c' conflicts with value present in = entry]
dn: = c=3DTE,dc=3Dmy-domain,dc=3Dcom
: add
objectClass: top
objectClass: country
c: FR

The result on OpenLDAP makes more = sense I guess.


Regards,
Pierre-Arnaud

(FYI, the failing test is in = server-integ, AddIT,
testAddEntryDifferentRDNSingleValuedInEntry())

--
Regards,
Cordialement,
Emmanuel = L=E9charny
www.iktek.com




-- =
Kiran = Ayyagari


= --Apple-Mail=_98E56F46-54C4-45F1-A3F0-0049D369C724--