Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <106844390.1233159719727.JavaMail.jira@brutus>
Date: Wed, 28 Jan 2009 08:21:59 -0800 (PST)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Updated: (DIRSERVER-1301) Colliding attributeType and
 objectClass names not supported, error messages unhelpful
In-Reply-To: <1813295940.1231335404307.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DIRSERVER-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRSERVER-1301:
-----------------------------------------

    Affects Version/s:     (was: 1.5.9)
                       1.5.4
        Fix Version/s: 2.0.0-RC1

Sadly, I must admit you are right :/ ... 

RFC 4512, 6.2 :
"...
Implementations MUST be prepared that the same short name might be
   used in a subschema to refer to the different kinds of schema
   elements.  That is, there might be an object class 'x-fubar' and an
   attribute type 'x-fubar' in a subschema.
..."

Fixing this will be complicated though, as all the server is based on the assertion that names can't collide.


> 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.4
>            Reporter: Aleksander Adamowski
>             Fix For: 2.0.0-RC1
>
>
> 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.