[
https://issues.apache.org/jira/browse/DIRAPI-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613258#comment-16613258
]
Emmanuel Lecharny commented on DIRAPI-320:
------------------------------------------
Note that the {{cn=schema,cn=config}} backend is only visible when you use
{{slapd.d}}, and not {{slapd.conf}}.
That being said, many schema objects are hidden by {{OpenLDAP}}. It's a policy
that has been around for years (almost 2 decades...). The idea is that schema
objects that are not well defined in RFCs should not be exposed. This is a
problem when you want to design a schema aware client (see [this
thread|http://www.openldap.org/its/index.cgi/?findid=6435]).
So how should we deal with this ? Ideally speaking, what we need is a
{{OpenLDAPSchemaLoader}}, that deals with those issues :-) The biggest issue
here is that we use internal constructs ({{Normalizer}}, {{SyntaxChecker}} and
{{Comparator}}) that aren't defined in any LDAP RFC. IMO, they should be used
whatever the server you connect to, which is not the case. This [schema
picture|http://directory.apache.org/api/user-guide/4.1-schema.html] shows the
relation of those three elements with the other schema elements ({{LdapSyntax}}
and {{MatchingRule}}). The link is done using the {{OID}}, so it's easy to
retrieve the correct {{Comparator}} knowing the {{MatchingRule}}'s syntax. For
instance :
{noformat:title=telephoneNumberSubstringsMatch MacthingRule}
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX
1.3.6.1.4.1.1466.115.121.1.58 )
{noformat}
and
{noformat:title=Substring Assertion Syntax}
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
{noformat}
are implicitely linked. Their associated {{SyntaxChecker}} has the very same
OID:
{code:title=SubstringAssertionSyntaxChecker.java|borderStyle=solid}
public final class SubstringAssertionSyntaxChecker extends SyntaxChecker
{
/**
* A static instance of SubstringAssertionSyntaxChecker
*/
public static final SubstringAssertionSyntaxChecker INSTANCE =
new SubstringAssertionSyntaxChecker(
SchemaConstants.SUBSTRING_ASSERTION_SYNTAX );
...
{code}
where {{SchemaConstants.SUBSTRING_ASSERTION_SYNTAX}} is
{{SchemaConstants.SUBSTRING_ASSERTION_SYNTAX}} (There is no associated
{{Comparator}} and {{Normalizer}}, we use a noOp {{Normalizer}} and a standard
comparator).
That means we could load all the existing {{SyntaxCheckers}} beforehand, and
attach them to the newly created 'fake' {{LdapSyntax}} when they are hidden by
the server. Same thing for {{Comparators}} and {{Normalizers}}.
That would make the loaded schema working in all case.
I'll check how costly would be such an approach. Now, the problem will also
arise for AD, and any other LDAP server we would like to get teh schema from -
and the fact that so many LDAP servers simply don't implement the RFCs properly
is a real troublemaker ;-/ -
Interesting problem :-)
> ClassCastException on Objects.equals(Value,Value) for userPassword attribute
> ----------------------------------------------------------------------------
>
> Key: DIRAPI-320
> URL: https://issues.apache.org/jira/browse/DIRAPI-320
> Project: Directory Client API
> Issue Type: Bug
> Affects Versions: 2.0.0.AM2
> Reporter: Pavel Zlámal
> Priority: Minor
>
> When I use _JarLdifSchemaLoader_ it seems to load _userPassword_ attribute
> type with different Comparator than when I load it from LDAP connection
> (openLDAP in my case).
> Then If I call:
> {code:java}
> Objects.equals(val, attribute.get())
> {code}
> to check if value passed to my method is the first in the attribute, I get
> _ClassCastException_, since it tries to pass _String_ (normalized value) to
> the _ByteArrayComparator._
> When I use Schema only loaded from connection, then it works, since it uses
> _ComparableComparator._
> {code:java}
> java.lang.ClassCastException: java.lang.String cannot be cast to [B
> at
> org.apache.directory.api.ldap.model.schema.comparators.ByteArrayComparator.compare(ByteArrayComparator.java:32)
> at org.apache.directory.api.ldap.model.entry.Value.equals(Value.java:1389)
> at java.util.Objects.equals(Objects.java:59)
> {code}
> So there is probably bug in schema ldif included in JAR or in equals()
> implementation of Value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
