[
https://issues.apache.org/jira/browse/DIRAPI-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747681#comment-13747681
]
Gerald Turner commented on DIRAPI-154:
--------------------------------------
I progressed a little further by disabling the throw on errors and changing
from loadAllEnabled() to loadAllEnabledRelaxed():
public void loadSchema( SchemaLoader loader ) throws LdapException
{
try
{
SchemaManager tmp = new DefaultSchemaManager( loader );
tmp.loadAllEnabledRelaxed();
if ( !tmp.getErrors().isEmpty() )
{
String msg = "there are errors while loading the schema";
LOG.error( msg + " {}", tmp.getErrors() );
// Ignore: throw new LdapException( msg );
}
...
Now the schema is loaded and the registries are full of schema objects, however
a new kind of error happens when retrieving attributes from searches:
10:03:11,226 ERROR
[org.apache.directory.api.ldap.model.entry.DefaultAttribute] (main) ERR_04131
The value is expected to be a String
...an attribute such as 'cn' is now stored as binary, toString:
cn: '0x4A 0x42 0x6F 0x73 0x73 0x41 0x64 0x6D 0x69 0x6E '
BTW, I created a fresh/empty OpenLDAP installation (using Debian packaging),
the messy duplicates and other brokeness (reported in my previous comment,
loadSchema.log attachment) is pretty much the same - seems that OpenLDAP is
distributed with dirty schemas. Perhaps keep the 'isApacheDs' and if false
then use relaxed schema loading?
> Implement "online" OpenLDAP schema parsing in DefaultSchemaLoader
> -----------------------------------------------------------------
>
> Key: DIRAPI-154
> URL: https://issues.apache.org/jira/browse/DIRAPI-154
> Project: Directory Client API
> Issue Type: Improvement
> Affects Versions: 1.0.0-M20
> Reporter: Gerald Turner
> Attachments: loadSchema.log, openldap-schema.ldif
>
>
> The constructor in DefaultSchemaLoader has the following comment:
> // TODO Handle schema loading on other LDAP servers
> For OpenLDAP this would require searching subtree under cn=schema,cn=config
> and handling attributes like:
> olcAttributeTypes: {1}( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last
> (family) name(s) for which the entity is known by' SUP name )
> olcObjectClasses: {4}( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP
> top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $
> seeAlso $ description ) )
> Note that there is also an 'olcObjectIdentifier' attribute type that seems to
> be used to create macros for interpolation in OID's used in other attributes:
> olcObjectIdentifier: OLcfg 1.3.6.1.4.1.4203.1.12.2
> olcObjectIdentifier: OLcfgAt OLcfg:3
> olcObjectIdentifier: OLcfgOvAt OLcfgAt:3
> olcObjectIdentifier: OMsyn 1.3.6.1.4.1.1466.115.121.1
> olcObjectIdentifier: OMsBoolean OMsyn:7
> olcAttributeTypes: ( OLcfgOvAt:10.4 NAME 'olcUniqueStrict' DESC 'Enforce
> uniqueness of null values' EQUALITY booleanMatch SYNTAX OMsBoolean
> SINGLE-VALUE )
> However this additional complexity seems to only be used for the
> internal/vendor-specific schema itself (not 'core', 'nis', etc.).
> Attached is LDIF output of from searching cn=schema,cn=config.
> Mailing List reference:
> https://mail-archives.apache.org/mod_mbox/directory-api/201308.mbox/%3CCABzFU-eOfmwiFpR1w0Fd-JhNFBVLO0NkHKa5w61ReFBEq%3DWkaw%40mail.gmail.com%3E
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
