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 14:36:44 UTC
[jira] Created: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
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.
>
>
[jira] Updated: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Reopened: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
Posted by "Aleksander Adamowski (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
Posted by "Aleksander Adamowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661609#action_12661609 ]
Aleksander Adamowski commented on DIRSERVER-1301:
-------------------------------------------------
Also, since the RFC doesn't clarify this question, I think it would be reasonable to imitate the behaviour of the oldest and most widespread LDAP server implementation: Netscape Directory Server (currently Red Hat / Fedora Directory Server). And it supports attributetypes and objectclasses with same names.
> 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.
[jira] Resolved: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kiran Ayyagari resolved DIRSERVER-1301.
---------------------------------------
Resolution: Fixed
I have just verified this against the trunk and this issue no longer present (the schema subsystem was re written)
> 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.
[jira] Closed: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-1301.
----------------------------------------
> 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.
[jira] Resolved: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRSERVER-1301.
------------------------------------------
Resolution: Invalid
names must be unique. You can't use the same name for an ObjectClass and an AttributeType.
> 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.
[jira] Commented: (DIRSERVER-1301) Colliding attributeType and
objectClass names not supported, error messages unhelpful
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744443#action_12744443 ]
Emmanuel Lecharny commented on DIRSERVER-1301:
----------------------------------------------
We must review the OidRegistry in order to allow such name collisions. Basically, we always know which kind of SchemaObject we are dealing with, we then should pass it to the OidRegistry when registering or searching for some name.
> 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.