Package com.evolveum.midpoint.prism.impl.match

Class DistinguishedNameMatchingRule

java.lang.Object
com.evolveum.midpoint.prism.impl.match.DistinguishedNameMatchingRule
All Implemented Interfaces:
MatchingRule<String>
public class DistinguishedNameMatchingRule extends Object implements MatchingRule<String>
Matching rule for LDAP distinguished name (DN).
Author:
Radovan Semancik

  • Constructor Details

    • DistinguishedNameMatchingRule

      public DistinguishedNameMatchingRule()

  • Method Details

    • getName

      public QName getName()
      Description copied from interface: MatchingRule
      QName that identifies the rule. This QName may be used to refer to this specific matching rule, it is an matching rule identifier.
      Specified by:
      getName in interface MatchingRule<String>

    • supports

      public boolean supports(QName xsdType)
      Description copied from interface: MatchingRule
      Returns true if the rule can be applied to the specified XSD type.
      Specified by:
      supports in interface MatchingRule<String>

    • match

      public boolean match(String a, String b) throws SchemaException
      Description copied from interface: MatchingRule
      Matches two objects.
      Specified by:
      match in interface MatchingRule<String>
      Throws:
      SchemaException

    • normalize

      public String normalize(String original) throws SchemaException
      Description copied from interface: MatchingRule
      Returns a normalized version of the value. For normalized version the following holds: if A matches B then normalize(A) == normalize(B) FIXME Currently, the implementation of PolyStringNormMatchingRule does not fulfill this contract. The main problem is that this method returns a value of the same type as it was called with. It may not be appropriate for holding the normalized value. In the case of PolyString norm, we should rather return String instead of PolyString. A similar case could be with comparing e.g. IP addresses where an array or a list of numbers would be appropriate as the normalized representation. (Note: In midPoint provisioning module, we rely on the method returning an object with the same type. But currently, all values used there should be of String type. When introducing other types of attributes, this question will need to be resolved.)
      Specified by:
      normalize in interface MatchingRule<String>
      Throws:
      SchemaException

    • matchRegex

      public boolean matchRegex(String a, String regex) throws SchemaException
      Description copied from interface: MatchingRule
      Matches value against given regex.
      Specified by:
      matchRegex in interface MatchingRule<String>
      Throws:
      SchemaException

    • toString

      public String toString()
      Overrides:
      toString in class Object