You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Aleksander Adamowski (JIRA)" <ji...@apache.org> on 2009/01/07 16:32:44 UTC
[jira] Reopened: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
[ 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.
Re: [jira] Reopened: (DIRSERVER-1301) Colliding attributeType and objectClass names not supported, error messages unhelpful
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 <ak...@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)
> <ji...@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
Re: [jira] Reopened: (DIRSERVER-1301) Colliding attributeType and objectClass names not supported, error messages unhelpful
Posted by Alex Karasulu <ak...@gmail.com>.
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.
>
>