directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [jira] Reopened: (DIRSERVER-1301) Colliding attributeType and objectClass names not supported, error messages unhelpful
Date Wed, 07 Jan 2009 16:38:50 GMT
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 <akarasulu@gmail.com> 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)
> <jira@apache.org> 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

Mime
View raw message