[ https://issues.apache.org/jira/browse/DIRAPI-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786106#comment-17786106 ]
Emmanuel Lécharny edited comment on DIRAPI-396 at 11/14/23 11:22 PM: --------------------------------------------------------------------- Hi! There is something you need to do *after* having loaded the _Mozilla_ schema: {code:java} schemaManager.loadDisabled( "mozilla" ); // Regenerate the references schemaManager.getRegistries().buildReferences(); ... {code} This is the part where all the missing MatchingRules (and other elements) are loaded from their OID. That should work. was (Author: elecharny): Hi! There is something you need to do *after* having loaded the _Mozilla_ schema: {code:java} schemaManager.loadDisabled( "mozilla" ); // Regenerate the references schemaManager.getRegistries().buildReferences(); ... {code} This is the part where all the missing MatchingRule are loaded from their OID. That should work. > Additional loading of a schema not complete > ------------------------------------------- > > Key: DIRAPI-396 > URL: https://issues.apache.org/jira/browse/DIRAPI-396 > Project: Directory Client API > Issue Type: Bug > Affects Versions: 2.1.5 > Reporter: Thomas Gaebler > Priority: Critical > > Hi community! > I have my own LDAP server implementation and use org.apache.directory.server > libraries in version 2.0.0.AM27 and the API in version 2.1.5. > The LDAP server is called by various mail clients, including Thunderbird. If > I start a simplified address book search in Thunderbird, I receive the > following filter in the SearchRequest: > {code:java} > (|(|(cn=*test*)(givenName=*test*)(sn=*test*)(xmozillanickname=*test*)(mail=*test*)(mozillaSecondEmail=*test*)(description=*test*)(o=*test*)(ou=*test*)(title=*test*)(workurl=*test*)(homeurl=*test*))(objectClass=referral))) > {code} > Not nice, but I have no influence on that. > The 'mozilla' schema is not loaded by default. So far I have loaded this at > server startup using the following code: > {code:java} > schemaManager.loadDisabled( "mozilla" ); {code} > This has worked well so far. With the update to the latest versions, however, > there is a problem. The received search query is now not parsed correctly. If > I display it in the LOG, it now says: > {code:java} > (|(|(cn=*test*)(givenName=*test*)(sn=*test*)(Undefined:mozillaNickname)(mail=*test*)(Undefined:mozillaSecondEmail)(description=*test*)(o=*test*)(ou=*test*)(title=*test*)(Undefined:mozillaWorkUrl)(Undefined:mozillaHomeUrl))(objectClass=referral)) > {code} > All mozilla attributes are now Undefined. The reason for this can be found > here: > {code:java} > org.apache.directory.server.core.api.normalization.FilterNormalizingVisitor.visitSubstringNode(SubstringNode) > { > AttributeType attributeType = > schemaManager.lookupAttributeTypeRegistry( node.getAttribute() ); > MatchingRule substringMR = attributeType.getSubstring(); > > if ( ( substringMR == null ) || ( substringMR.getNormalizer() == null > ) ) > { > // No normalizer for a Substring filter > return new UndefinedNode( node.getAttribute() ); > } > ... > }{code} > The MatchingRule (substringMR) for the mozilla Attributes is null. Only the > substringOid is set. If fixed this for some attributes, but of course, it's a > hack: > {code:java} > schemaManager.loadDisabled( "mozilla" ); > > Registries registries = schemaManager.getRegistries(); > MatchingRuleRegistry matchingRuleRegistry = > registries.getMatchingRuleRegistry(); > List<String> attributeNames = asList( "mozillaSecondEmail", > "mozillaNickname", "mozillaHomeUrl", "mozillaWorkUrl" ); > for ( var attributeName : attributeNames ) > { > AttributeType attribute = > schemaManager.lookupAttributeTypeRegistry( attributeName ); > > attribute.unlock(); > if ( isNull( attribute.getSubstring() ) && nonNull( > attribute.getSubstringOid() ) ) > { > MatchingRule matchingRule = matchingRuleRegistry.lookup( > attribute.getSubstringOid() ); > attribute.setSubstring( matchingRule ); > } > > if ( isNull( attribute.getEquality() ) && nonNull( > attribute.getEqualityOid() ) ) > { > MatchingRule matchingRule = matchingRuleRegistry.lookup( > attribute.getEqualityOid() ); > attribute.setEquality( matchingRule ); > } > > if ( isNull( attribute.getOrdering() ) && nonNull( > attribute.getOrderingOid() ) ) > { > MatchingRule matchingRule = matchingRuleRegistry.lookup( > attribute.getOrderingOid() ); > attribute.setOrdering( matchingRule ); > } > attribute.lock(); > } > {code} > If I have overlooked something in the implementation so far, I would be > grateful for a hint. But it looks like a bug. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org