Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 23878 invoked from network); 12 Jul 2006 09:26:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Jul 2006 09:26:31 -0000 Received: (qmail 80366 invoked by uid 500); 12 Jul 2006 09:26:31 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 80138 invoked by uid 500); 12 Jul 2006 09:26:30 -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 80127 invoked by uid 99); 12 Jul 2006 09:26:30 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 02:26:30 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of elecharny@gmail.com designates 64.233.184.226 as permitted sender) Received: from [64.233.184.226] (HELO wr-out-0506.google.com) (64.233.184.226) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 02:26:29 -0700 Received: by wr-out-0506.google.com with SMTP id 69so69776wra for ; Wed, 12 Jul 2006 02:26:08 -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:references; b=UprVi6ku5d5E87Kd7kWr5b9nZbcbmgtVHuUbtHqJJ4Tdh9rn4EzV4Bjz39mQOJTrN2g0Vd8wItAploYhvNs3BICLpNLk3tZX9jhKgGV7e320gUfBVlXvV2JgJGuSjzc2APOGlWacsreuua9l5Th8qjHjrFHcEwTuo879Cq6a+oo= Received: by 10.82.109.19 with SMTP id h19mr38879buc; Wed, 12 Jul 2006 02:26:08 -0700 (PDT) Received: by 10.78.131.6 with HTTP; Wed, 12 Jul 2006 02:26:08 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2006 11:26:08 +0200 From: "Emmanuel Lecharny" Reply-To: elecharny@apache.org To: "Apache Directory Developers List" Subject: Re: ApacheDS trunk: JDK1.4/unit test/normalisation issues In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_63833_5154672.1152696368218" References: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_63833_5154672.1152696368218 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yeah, this was a bug that was fixed last week in optimization-trunk. I thin= k there is a JIRA for this one. Sorry, I'm on my day job, so I can't really help atm... On 7/12/06, Norbet Reilly wrote: > > I have used the one-liner above to restore the original (upName) DNs > for the moment, and it seemed as if my partition was populated with > all the desired data from the LDIF file. > > My problem is now that JXplorer has trouble connecting to the started > server, because while doing queries at start-up some LdapDN values are > ending up associated with the "namingContexts" attribute inside a > org.apache.directory.shared.ldap.codec.search.SearchResultEntry, where > this class is expecting only String and binary values. The system > partition value was a string, but other partition values were LdapDNs. > I think the problem is in > DefaultDirectoryPartitionNexus.addContextPartition() where LdapDNs are > added as follows: > > 430 Attribute namingContexts =3D rootDSE.get( NAMINGCTXS_ATTR ); > 431 namingContexts.add( partition.getUpSuffix() ); > > instead of > > Attribute namingContexts =3D rootDSE.get( NAMINGCTXS_ATTR ); > namingContexts.add( partition.getUpSuffix().toString() ); > > The same issue impacts > DefaultDirectoryPartitionNexus.removeContextPartition(). > > Making this change allowed me to connect with JXplorer, but I still > can't view the ApacheDS schema in the schema panel so I need to work > out what's happening there. > --=20 Cordialement, Emmanuel L=E9charny ------=_Part_63833_5154672.1152696368218 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yeah, this was a bug that was fixed last week in optimization-trunk. I thin= k there is a JIRA for this one.

Sorry, I'm on my day job, so I can't= really help atm...

On 7/12/06, Norbet Reilly <nrhope@gmail.com<= /a>> wrote:
I have used the one-liner above to restore the original (upName) DNs
for= the moment, and it seemed as if my partition was populated with
all the= desired data from the LDIF file.

My problem is now that JXplorer ha= s trouble connecting to the started
server, because while doing queries at start-up some LdapDN values are<= br>ending up associated with the "namingContexts" attribute insid= e a
org.apache.directory.shared.ldap.codec.search.SearchResultEntry, whe= re
this class is expecting only String and binary values. The system
pa= rtition value was a string, but other partition values were LdapDNs.
I t= hink the problem is in
DefaultDirectoryPartitionNexus.addContextPartitio= n () where LdapDNs are
added as follows:

430   Attribute = namingContexts =3D rootDSE.get( NAMINGCTXS_ATTR );
431   namin= gContexts.add( partition.getUpSuffix() );

instead of

 &n= bsp;      Attribute namingContexts =3D=20 rootDSE.get( NAMINGCTXS_ATTR );
      &nbs= p; namingContexts.add( partition.getUpSuffix().toString() );

Th= e same issue impacts DefaultDirectoryPartitionNexus.removeContextPartition(= ).

Making this change allowed me to connect with JXplorer, but I sti= ll
can't view the ApacheDS schema in the schema panel so I need to workout what's happening there.


--
Cordialement,
Emmanuel L=E9charny ------=_Part_63833_5154672.1152696368218--