From dev-return-11947-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Fri May 12 16:37:34 2006 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 7763 invoked from network); 12 May 2006 16:37:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 May 2006 16:37:34 -0000 Received: (qmail 23862 invoked by uid 500); 12 May 2006 16:37:33 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 23643 invoked by uid 500); 12 May 2006 16:37:32 -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 23625 invoked by uid 99); 12 May 2006 16:37:32 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 May 2006 09:37:32 -0700 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of elecharny@gmail.com designates 64.233.162.194 as permitted sender) Received: from [64.233.162.194] (HELO nz-out-0102.google.com) (64.233.162.194) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 May 2006 09:37:30 -0700 Received: by nz-out-0102.google.com with SMTP id 9so465100nzo for ; Fri, 12 May 2006 09:37:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Wjtag4bWz4Tj2xclB5rWirUTBeg6Acu8YxkRRUpHp41lPSEbMOV4IGGYfdIornIphcB1M03kbYE2cAclXtIpvmVTJV4Jwp/k6H6bM3MUJDUfiKmmO19JFJOm4cK1RLseHaxfJtMhyWdvz9M7JfRY2A7QvXNKVNM5aghbZMHEiRo= Received: by 10.64.243.19 with SMTP id q19mr1756808qbh; Fri, 12 May 2006 09:37:10 -0700 (PDT) Received: by 10.64.209.13 with HTTP; Fri, 12 May 2006 09:37:09 -0700 (PDT) Message-ID: Date: Fri, 12 May 2006 18:37:09 +0200 From: "Emmanuel Lecharny" Reply-To: elecharny@apache.org To: "Apache Directory Developers List" Subject: Re: Attributes and DN question In-Reply-To: <4464AFAF.4040007@bellsouth.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <5F1E77C2-8F2A-497C-903B-AE9FC4CA8C17@jaguNET.com> <6.0.0.22.0.20060511193730.03fda480@mail.qos.ch> <4463928A.40306@gmail.com> <4463C687.2090006@gmail.com> <4464A63A.3080503@bellsouth.net> <4464AFAF.4040007@bellsouth.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I've created it. It mixes ModificationItems and Entries, with a DN, so we cover all the cases. I can't commit the change (infra pb), but that's fine because I need to fix the pb with the previous LdifReader. btw, I'm not sure that allowing the server to injext a ldif file whenstarting is such a good idea... Let me elaborate a lil bit : what if your server is restarted? The ldif will be injected again. And that may not be the expected behavior. wdyt ? It could be better to have a tool to inject Ldif entries and changes into the server (like LdifDe). IMHO :) On 5/12/06, Alex Karasulu wrote: > Emmanuel Lecharny wrote: > > ok. So if the 'new' Ldif reader does not add this DN in the > > BasicAttributes, I guess that is the normal behavior. Now, about the > > previous code, this is a part of a test which load entries provided by > > the 'old' ldif reader, and I guess that it's the only way to get the > > DN. > > > > In this case, yes, this code makes perfect sense. > > > > Thanks Alex ! > > Np sorry about the confusion Emmanuel. I guess we should have a special > data structure for things read from an LDIF since it is not going to be > an attribute always. > > Alex > > > > > On 5/12/06, Alex Karasulu wrote: > >> Emmanuel Lecharny wrote: > >> > Hi all, > >> > > >> > I'm trying to figure out if code like : > >> > > >> > ... > >> > Attributes entry =3D ( Attributes ) i.next(); > >> > if ( entry.get( "dn" ) =3D=3D null ) > >> > { > >> > throw new ConfigurationException( "Test entries must > >> > have DN attributes" ); > >> > } > >> > ... > >> > > >> > makes sense or not. > >> > > >> > In my mind, Attributes should not containes "dn", because "dn" is > >> > already stored elswhere. Am I wrong ? wdyt ? > >> > >> Depends on what created the "entry". The old LDIF parser will return > >> the dn as an attribute which needs to be removed. This is the ONLY > >> Place where DN is an attribute in the entry. > >> > >> Alex > >> > > > > > > --=20 Cordialement, Emmanuel L=E9charny