Package com.evolveum.midpoint.prism.match

Interface MatchingRule<T>

All Known Implementing Classes:

DefaultMatchingRule, DistinguishedNameMatchingRule, ExchangeEmailAddressesMatchingRule, PolyStringNormMatchingRule, PolyStringOrigMatchingRule, PolyStringStrictMatchingRule, StringIgnoreCaseMatchingRule, UuidMatchingRule, XmlMatchingRule

public interface MatchingRule<T>

Interface for generic matching rules. The responsibility of a matching rule is to decide if two objects of the same type match. This may seem a simple thing to do but the details may get quite complex. E.g. comparing string in case sensitive or insensitive manner, comparing PolyStrings, etc.

Author:

Radovan Semancik

Method Summary

Modifier and Type	Method	Description
QName	getName()	QName that identifies the rule.
boolean	match(T a, T b)	Matches two objects.
boolean	matchRegex(T a, String regex)	Matches value against given regex.
T	normalize(T original)	Returns a normalized version of the value.
boolean	supports(QName xsdType)	Returns true if the rule can be applied to the specified XSD type.

Method Detail

getName

QName getName()

QName that identifies the rule. This QName may be used to refer to this specific matching rule, it is an matching rule identifier.

supports

boolean supports(QName xsdType)

Returns true if the rule can be applied to the specified XSD type.

match

boolean match(T a,
              T b)
       throws SchemaException

Matches two objects.

Throws:

SchemaException

matchRegex

boolean matchRegex(T a,
                   String regex)
            throws SchemaException

Matches value against given regex.

Throws:

SchemaException

normalize

T normalize(T original)
     throws SchemaException

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.)

Throws:

SchemaException