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 <[email protected]> wrote: > Short names which are also known as aliases in LDAP schema entities like > attributeTypes, syntaxes, objectClasses, matchingRules, etc all exist within > a common namespace. If the LDAP RFC does not clarify you need to delve into > 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 description > 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) > <[email protected]> wrote: >> >> [ >> https://issues.apache.org/jira/browse/DIRSERVER-1301?page=com.atlassian.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 attribute >> 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 with >> > 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=schema >> > 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.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:198) >> > at >> > org.apache.directory.server.core.schema.ObjectClassImpl.getMayList(ObjectClassImpl.java:104) >> > at >> > org.apache.directory.server.utils.AttributesFactory.getAttributes(AttributesFactory.java:393) >> > at >> > org.apache.directory.server.utils.AttributesFactory.getAttributes(AttributesFactory.java:74) >> > at >> > org.apache.directory.server.core.schema.SchemaSubentryModifier.addSchemaObject(SchemaSubentryModifier.java:188) >> > at >> > org.apache.directory.server.core.schema.SchemaOperationControl.modifyAddOperation(SchemaOperationControl.java:885) >> > at >> > org.apache.directory.server.core.schema.SchemaOperationControl.modifySchemaSubentry(SchemaOperationControl.java:568) >> > at >> > org.apache.directory.server.core.schema.SchemaInterceptor.modify(SchemaInterceptor.java:1493) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.operational.OperationalAttributeInterceptor.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.modify(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(ReferralInterceptor.java:403) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.authn.AuthenticationInterceptor.modify(AuthenticationInterceptor.java:336) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.modify(InterceptorChain.java:1214) >> > at >> > org.apache.directory.server.core.normalization.NormalizationInterceptor.modify(NormalizationInterceptor.java:127) >> > at >> > org.apache.directory.server.core.interceptor.InterceptorChain.modify(InterceptorChain.java:819) >> > at >> > org.apache.directory.server.core.DefaultOperationManager.modify(DefaultOperationManager.java:631) >> > at >> > org.apache.directory.server.core.DefaultCoreSession.modify(DefaultCoreSession.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 OID >> > 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 between >> > 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. >> > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
