Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 787 invoked from network); 7 Jan 2009 16:39:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Jan 2009 16:39:23 -0000 Received: (qmail 30172 invoked by uid 500); 7 Jan 2009 16:39:23 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 30124 invoked by uid 500); 7 Jan 2009 16:39:23 -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 30115 invoked by uid 99); 7 Jan 2009 16:39:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jan 2009 08:39:22 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates 74.125.46.29 as permitted sender) Received: from [74.125.46.29] (HELO yw-out-2324.google.com) (74.125.46.29) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jan 2009 16:39:12 +0000 Received: by yw-out-2324.google.com with SMTP id 9so2627168ywe.55 for ; Wed, 07 Jan 2009 08:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=uMrcsa7NgwkdOF3QaIxCbGXegvBh8IwU/YJNhIcmnPw=; b=ZIJ8UTp8P9iyR+vHeUIPCCQdhaqKAHwv0GurFCRSnN0HEgNBfeTFSZYk9RQLpWqtsP mxiINFpBo1iBzHX4lqCVnImiQ5pqI63YNpUVmY0HiNyWT5HaN+mojI/Uj0QttF3leB1k Uwco0Q7RjjSQLRUbTeLQBR7A1F7PYYb8kR20Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qRNhYYUKxobrC9dj89XhEWOLRdtCTxjiYJGlRReSvTi6Ru3eJk2dzz9LxniOq9KpC9 HM2mX4O6B62yjVBtW9poeDRGCg4Oog4PuocZyl8ShEKzzZOfNptzEJq54ftXDpitX6uh 5PrkOiHJdxm4efo+fiaaEfEOvd559oE9qkjmw= Received: by 10.142.134.17 with SMTP id h17mr9707005wfd.344.1231346330630; Wed, 07 Jan 2009 08:38:50 -0800 (PST) Received: by 10.142.203.13 with HTTP; Wed, 7 Jan 2009 08:38:50 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2009 17:38:50 +0100 From: "Emmanuel Lecharny" Reply-To: elecharny@iktek.com To: "Apache Directory Developers List" Subject: Re: [jira] Reopened: (DIRSERVER-1301) Colliding attributeType and objectClass names not supported, error messages unhelpful In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1813295940.1231335404307.JavaMail.jira@brutus> <1581878958.1231342364330.JavaMail.jira@brutus> X-Virus-Checked: Checked by ClamAV on apache.org I was close to send the exact same message : - names are just alias for unique OIDs, so it makes sense for them to be unique for a specific schema. - currently, ADS support only one schema - the error message is far from being informative. Alex's suggestion to close the JIRA and to create a new one for a better error message is fine. On Wed, Jan 7, 2009 at 5:33 PM, Alex Karasulu wrote: > Short names which are also known as aliases in LDAP schema entities like > attributeTypes, syntaxes, objectClasses, matchingRules, etc all exist wit= hin > a common namespace. If the LDAP RFC does not clarify you need to delve i= nto > the X.500 specifications. The LDAP specifications build on top of X.500 = so > they are not the only source of information about LDAP. > > Agreed regarding the error message. We could return something more > informative. In this case I would simply file another JIRA issue stating > that specifically so it get's filed properly with a consistent descriptio= n > and name: takes too much to realize that the issue has changed from the > conversation log. Perhaps closing this particular issue is a good idea. > > Thanks, > Alex > > On Wed, Jan 7, 2009 at 10:32 AM, Aleksander Adamowski (JIRA) > wrote: >> >> [ >> https://issues.apache.org/jira/browse/DIRSERVER-1301?page=3Dcom.atlassia= n.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Aleksander Adamowski reopened DIRSERVER-1301: >> --------------------------------------------- >> >> >> I'd like to reopen the issue since at the very least, the error message = in >> the thrown NamingException should give a hint about the uniqueness >> requirement. >> >> Also, in RFC 4512 I couldn't find requirements about lack of collisions >> between attribute type and object class names: >> >> http://tools.ietf.org/html/rfc4512#section-2.4 : >> >> "Each object class is identified by an object identifier (OID) and, >> optionally, one or more short names (descriptors)." >> >> http://tools.ietf.org/html/rfc4512#section-2.5.1 : >> >> "Each attribute type is identified by an object identifier (OID) and, >> optionally, one or more short names (descriptors)." >> >> Nothing implies here that the short names of object classes and attribut= e >> names share a common namespace. >> >> >> >> >> > Colliding attributeType and objectClass names not supported, error >> > messages unhelpful >> > >> > ----------------------------------------------------------------------= --------------- >> > >> > Key: DIRSERVER-1301 >> > URL: >> > https://issues.apache.org/jira/browse/DIRSERVER-1301 >> > Project: Directory ApacheDS >> > Issue Type: Bug >> > Affects Versions: 1.5.9 >> > Reporter: Aleksander Adamowski >> > >> > When trying to dynamically add an attributeType and an objectClass wit= h >> > the same name (case insensitively), one gets a NamingException with a >> > completely unhelpful error message. >> > e.g. Suppose we have the following schema LDIF and import it to >> > directory: >> > ########### >> > version: 1 >> > dn: cn=3Dschema >> > changetype: modify >> > add: attributeTypes >> > attributeTypes: ( 1.3.6.1.4.1.18060.0.4.3.2.1 >> > NAME 'ship' >> > DESC 'a reference to a ship' >> > EQUALITY distinguishedNameMatch >> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 >> > SINGLE-VALUE >> > ) >> > - >> > add: objectClasses >> > objectClasses: ( 1.3.6.1.4.1.18060.0.4.3.3.1 >> > NAME 'ship' >> > DESC 'An entry which represents a ship' >> > SUP top >> > STRUCTURAL >> > MUST cn >> > MAY ( description ) >> > ) >> > objectClasses: ( 1.3.6.1.4.1.18060.0.4.3.3.2 >> > NAME 'port' >> > DESC 'An entry which represents a port' >> > SUP top >> > STRUCTURAL >> > MUST cn >> > MAY ( description $ ship ) >> > ) >> > - >> > ########### >> > javax.naming.directory.NoSuchAttributeException: attributeType w/ OID >> > 1.3.6.1.4.1.18060.0.4.3.3.1 not registered! >> > at >> > org.apache.directory.server.schema.registries.DefaultAttributeTypeRegi= stry.lookup(DefaultAttributeTypeRegistry.java:198) >> > at >> > org.apache.directory.server.core.schema.ObjectClassImpl.getMayList(Obj= ectClassImpl.java:104) >> > at >> > org.apache.directory.server.utils.AttributesFactory.getAttributes(Attr= ibutesFactory.java:393) >> > at >> > org.apache.directory.server.utils.AttributesFactory.getAttributes(Attr= ibutesFactory.java:74) >> > at >> > org.apache.directory.server.core.schema.SchemaSubentryModifier.addSche= maObject(SchemaSubentryModifier.java:188) >> > at >> > org.apache.directory.server.core.schema.SchemaOperationControl.modifyA= ddOperation(SchemaOperationControl.java:885) >> > at >> > org.apache.directory.server.core.schema.SchemaOperationControl.modifyS= chemaSubentry(SchemaOperationControl.java:568) >> > at >> > org.apache.directory.server.core.schema.SchemaInterceptor.modify(Schem= aInterceptor.java:1493) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.operational.OperationalAttributeInter= ceptor.modify(OperationalAttributeInterceptor.java:198) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.changelog.ChangeLogInterceptor.modify= (ChangeLogInterceptor.java:221) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.exception.ExceptionInterceptor.modify= (ExceptionInterceptor.java:324) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.authz.DefaultAuthorizationInterceptor= .modify(DefaultAuthorizationInterceptor.java:272) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.authz.AciAuthorizationInterceptor.mod= ify(AciAuthorizationInterceptor.java:565) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.referral.ReferralInterceptor.modify(R= eferralInterceptor.java:403) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.authn.AuthenticationInterceptor.modif= y(AuthenticationInterceptor.java:336) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.= modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.normalization.NormalizationIntercepto= r.modify(NormalizationInterceptor.java:127) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain.modify(I= nterceptorChain.java:819) >> > at >> > org.apache.directory.server.core.DefaultOperationManager.modify(Defaul= tOperationManager.java:631) >> > at >> > org.apache.directory.server.core.DefaultCoreSession.modify(DefaultCore= Session.java:448) >> > at >> > org.apache.directory.server.core.integ.IntegrationUtils.injectEntries(= IntegrationUtils.java:109) >> > ... >> > It seems like when resolving the may list of objectClass "port", the O= ID >> > was resolved to the OID of attribute "ship", not objectclass "ship". >> > Two things to note here: >> > 1) Netscape/Red Hat/Fedora Directory server supports adding >> > objectClasses that have a name that's colliding with an attributeType'= s >> > name. >> > 2) Even if such behaviour violates an RFC (I'm not aware of such >> > limitations), the exception should point out that name collisions betw= een >> > objectclasses and attributenames aren't allowed. >> > I think that the OID registries should be separate for attributeTypes >> > and objectClasses. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> > > --=20 Regards, Cordialement, Emmanuel L=E9charny www.iktek.com