From dev-return-31228-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Mon Aug 31 01:26:45 2009 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 97923 invoked from network); 31 Aug 2009 01:26:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 31 Aug 2009 01:26:45 -0000 Received: (qmail 29363 invoked by uid 500); 31 Aug 2009 01:26:45 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 29263 invoked by uid 500); 31 Aug 2009 01:26:44 -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 29255 invoked by uid 99); 31 Aug 2009 01:26:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Aug 2009 01:26:44 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.211.171 as permitted sender) Received: from [209.85.211.171] (HELO mail-yw0-f171.google.com) (209.85.211.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Aug 2009 01:26:34 +0000 Received: by ywh1 with SMTP id 1so5541618ywh.9 for ; Sun, 30 Aug 2009 18:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=FOekgifFzAG4lcpN/767o0AAJGp8IykDb/7YKIXpBSc=; b=W1QmU+gPW+395Xyn+/xUrUHC7fSZTeP2zdYwR6c5cdbnHafkjvOi8QEzYftnzQPOmQ 9/DS5yodVIBbXTC85XidbjxfGVH3mXelZmQvk18NXiPIx/FXPHZ5ekxth8LDU355dqaS vJvqXY62CwI+kqnnPgTB5qodS1Y0KgGfQm9zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nNdyZzX4+h4zgEt5b5sYB7z2GxGMIsEWE74BqZT1Q4vPpDCoO8EYPj+gY5t/02fFhc y1QNeIl5bS5ismGcuQ5kNoA4Rx6n57ZO6igsLtlQw/QXtRCe2gCCeFOHlew56VCq9fII GcniX2+zGYQyccfhuNqcnBvvgevIBjGcojTMU= MIME-Version: 1.0 Received: by 10.101.61.6 with SMTP id o6mr4657256ank.111.1251681973661; Sun, 30 Aug 2009 18:26:13 -0700 (PDT) In-Reply-To: <4A9AF526.6040409@nextury.com> References: <4A9AF526.6040409@nextury.com> Date: Mon, 31 Aug 2009 04:26:13 +0300 Message-ID: Subject: Re: [Shared] [Schema API] SchemaObject byOid and byName lookup issues From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=001636ed667a6976b4047265ebb1 X-Virus-Checked: Checked by ClamAV on apache.org --001636ed667a6976b4047265ebb1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 31, 2009 at 12:54 AM, Emmanuel Lecharny wrote: > Alex Karasulu wrote: > >> I'm running into several bugs and workaround because a byName hash was >> never >> implemented in the new SchemaObject. I guess this functionality had to be >> taken out of the OidRegistry and placed into specific type registries to >> avoid name collisions. However I thought there would be a byName hash. >> >> Any reason why this was explicitly not created ? >> >> > We don't need it. The byOid( String ) method (implemented in > SchemaRegistries) retrieves the OID when a name or an oid is provided. You > can do : > > String oid = attributeTypeRegistry.byOid( "ou" ); > > or > > String oid = attributeTypeRegistry.byOid( "2.5.4.11" ); > > That should be enough for our need. > In theory yes but it did not work properly. I debugged a bit then just simplified the situation by creating the byName hash and everything worked just fine. So I did not ask any more questions. Too tired at this point to figure out why it did not work. I'm sure the problems may creep back up to figure out why. And that might catch other bugs. Personally having one method to use is best I agree. Why have more surface area to the API. It's more exposure. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org --001636ed667a6976b4047265ebb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2009 at 12:54 AM, Emmanuel Lecharny <<= a href=3D"mailto:elecharny@apache.org">elecharny@apache.org> = wrote:
Alex Karasulu wrote:
I'm running into several bugs and workaround because a byName hash was = never
implemented in the new SchemaObject. =A0I guess this functionality had to b= e
taken out of the OidRegistry and placed into specific type registries to avoid name collisions. =A0However I thought there would be a byName hash.
Any reason why this was explicitly not created ?
=A0
We don't need it. The byOid( String ) method (implemented in SchemaRegi= stries) retrieves the OID when a name or an oid is provided. You can do :
String oid =3D attributeTypeRegistry.byOid( "ou" );

or

String oid =3D attributeTypeRegistry.byOid( "2.5.4.11" );

That should be enough for our need.

In theory yes but it did not work properly.=A0 I debu= gged a bit then just simplified the situation by creating the byName hash and everything worked just fine.=A0 So I did not ask any more questions.=A0 Too tired at this point to figure out why it did not work.=A0 I'm sure the problems may creep back up to figure out why.=A0 And that might catch other bugs.
Personally having one method to use is best I agree.=A0 Why have more surfa= ce area to the API.=A0 It's more exposure.
=A0
--
Ale= x Karasulu
My Blog :: http= ://www.jroller.com/akarasulu/
Apache Directory Server :: http://d= irectory.apache.org
Apache MINA :: http://mina.apache.org

--001636ed667a6976b4047265ebb1--