I'm using InMemoryDirectoryServer for unit testing and an additional schema. After some digging a I found an issue with my schema and the Schema.merge(…).
The schema use the same name on the objectClass and attribute for a couple of objectClasses and now I have found that first loading the schema I can find both the objectClass and the attributeType but after merging my schema with the default schema before starting the server only the objectClass is left but the attributeType is lost.
When googling on this topic I found this apache bug that describes the problem very well. Maybe UnboundId have a similar problem?
You should absolutely be allowed to have an attribute type and an object class that have the same name. I've just run several tests and am unable to find any problems in the way that schema merging works. Could you provide a sample schema that demonstrates the problem?
Neil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-05-16
After inspecting Schema class in detail I could easily see that this should work and it turned out that I was not loosing the attributeTypes in the merge method.
What tricked me was that I were using the schema.getSchemaEntry().toLDIFString() to inspect the schemas that I were merging but that is not showing the actual content of the schema but what was initially parsed.
Next level of confusion was that all attributes that had the same name as an objectClass happend to be marked as SINGLE -VALUE directly followed by an ) without a space. That triggered an exception that was suppressed and the schema parsing just continued but without the badly formed attributeTypes.
I don't know the BNF for schema files and ldif is different but the schema I use is defined by a schema file and I did the conversion to ldif and left the attributeType definitions untouched. Since this is a schema used on other LDAP servers is this a difference in schema and ldif or is UnboundId more picky on the format compared to other LDAP servers?
Thanks for the quick response! It really is a great tool to be able to run this memory based ldap in my junit test.
/H
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The syntax for schema elements is defined in RFC 4512. For an attribute type, it's in section 4.1.2, and that indicates that there doesn't need to be a space before the final parenthesis. It may be that the LDAP SDK is too strict in this regard, and if so then I'll make it more lenient in compliance with the specification.
Neil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I investigated this problem and although I found that the LDAP SDK did handle optional spaces correctly in most cases, there was one corner case, with tokens like OBSOLETE, SINGLE-VALUE, and NO-USER-MODIFICATION that could cause a problem if they appeared at the end of the definition with no space between that token and the closing parenthesis. I've just committed a fix for that problem. Thanks for pointing this out.
Neil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using InMemoryDirectoryServer for unit testing and an additional schema. After some digging a I found an issue with my schema and the Schema.merge(…).
The schema use the same name on the objectClass and attribute for a couple of objectClasses and now I have found that first loading the schema I can find both the objectClass and the attributeType but after merging my schema with the default schema before starting the server only the objectClass is left but the attributeType is lost.
When googling on this topic I found this apache bug that describes the problem very well. Maybe UnboundId have a similar problem?
https://issues.apache.org/jira/browse/DIRSTUDIO-428
/H
You should absolutely be allowed to have an attribute type and an object class that have the same name. I've just run several tests and am unable to find any problems in the way that schema merging works. Could you provide a sample schema that demonstrates the problem?
Neil
After inspecting Schema class in detail I could easily see that this should work and it turned out that I was not loosing the attributeTypes in the merge method.
What tricked me was that I were using the schema.getSchemaEntry().toLDIFString() to inspect the schemas that I were merging but that is not showing the actual content of the schema but what was initially parsed.
Next level of confusion was that all attributes that had the same name as an objectClass happend to be marked as SINGLE -VALUE directly followed by an ) without a space. That triggered an exception that was suppressed and the schema parsing just continued but without the badly formed attributeTypes.
I don't know the BNF for schema files and ldif is different but the schema I use is defined by a schema file and I did the conversion to ldif and left the attributeType definitions untouched. Since this is a schema used on other LDAP servers is this a difference in schema and ldif or is UnboundId more picky on the format compared to other LDAP servers?
Thanks for the quick response! It really is a great tool to be able to run this memory based ldap in my junit test.
/H
The syntax for schema elements is defined in RFC 4512. For an attribute type, it's in section 4.1.2, and that indicates that there doesn't need to be a space before the final parenthesis. It may be that the LDAP SDK is too strict in this regard, and if so then I'll make it more lenient in compliance with the specification.
Neil
I investigated this problem and although I found that the LDAP SDK did handle optional spaces correctly in most cases, there was one corner case, with tokens like OBSOLETE, SINGLE-VALUE, and NO-USER-MODIFICATION that could cause a problem if they appeared at the end of the definition with no space between that token and the closing parenthesis. I've just committed a fix for that problem. Thanks for pointing this out.
Neil