Package com.unboundid.ldap.sdk.schema
Class SchemaValidator
- java.lang.Object
-
- com.unboundid.ldap.sdk.schema.SchemaValidator
-
@Mutable @ThreadSafety(level=NOT_THREADSAFE) public final class SchemaValidator extends java.lang.Object
This class provides a mechanism form validating definitions in an LDAP schema. Schema elements are expected to be read from one or more LDIF files containing subschema subentries as described in RFC 4512 section 4.2, with elements defined using the syntaxes described in section 4.1 of the same specification.
This schema validator can perform the following checks:- It ensures that each schema element can be parsed.
- It ensures that element names and OIDs are properly formed, optionally allowing for more lax validation that some servers may permit.
- It ensures that each schema element does not reference any undefined schema elements.
- It can verify that each element is only defined once.
- It can optionally determine whether definitions may use functionality that some servers do not support.
- It can verify that schema entries are valid in accordance with the schema it contains.
- It can optionally ensure that schema files are named using an expected pattern.
- It can optionally validate extensions used in schema elements.
-
-
Constructor Summary
Constructors Constructor Description SchemaValidator()
Creates a new schema validator with the default settings.
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description boolean
allowAttributeTypesWithoutEqualityMatchingRule()
Indicates whether to allow attribute type definitions to be missing an equality matching definition, by neither directly specifying the matching rule name or OID nor referencing a superior attribute type from which the matching rule will be inherited.boolean
allowAttributeTypesWithoutSyntax()
Indicates whether to allow attribute type definitions to be missing an attribute syntax definition, by neither directly specifying the attribute syntax OID nor referencing a superior attribute type from which the syntax will be inherited.boolean
allowCollectiveAttributes()
Indicates whether to allow collective attribute type definitions.boolean
allowElementsWithoutNames()
Indicates whether to allow schema elements that do not contain names but may only be identified by an OID (or by the rule ID in the case of DIT structure rules).boolean
allowEmptyDescription()
Indicates whether to allow schema elements to have empty descriptions.boolean
allowInvalidObjectClassInheritance()
Indicates whether to allow object classes with an invalid inheritance relationship.boolean
allowMultipleEntriesPerFile()
Indicates whether a schema file is allowed to contain multiple entries.boolean
allowMultipleSuperiorObjectClasses()
Indicates whether to allow object classes with multiple superior classes.boolean
allowNamesWithInitialDigit()
Indicates whether to allow schema element names that start with a digit.boolean
allowNamesWithInitialHyphen()
Indicates whether to allow schema element names that start with a hyphen.boolean
allowNamesWithUnderscore()
Indicates whether to allow schema element names that contain the underscore character.boolean
allowNonNumericOIDsNotUsingName()
Indicates whether schema elements will be permitted to include non-numeric object identifiers that are of a form other than one of the element names followed by "-oid".boolean
allowNonNumericOIDsUsingName()
Indicates whether schema elements will be permitted to include non-numeric object identifiers that are comprised of the name for that element with "-oid" appended to it.boolean
allowObsoleteElements()
Indicates whether to allow schema elements declared with the OBSOLETE modifier.boolean
allowRedefiningElements()
Indicates whether the same schema element may be defined multiple times.boolean
allowSchemaFilesInSubDirectories()
Indicates whether to examine files in subdirectories when provided with a schema path that is a directory.boolean
allowStructuralObjectClassWithoutSuperior()
Indicates whether to allow structural object classes that do not declare a superior class.void
configureLDAPSDKDefaultAttributeSyntaxes()
Configures the schema validator to use a default set of attribute syntaxes that are known to the LDAP SDK.void
configureLDAPSDKDefaultMatchingRules()
Configures the schema validator to use a default set of matching rules that that are known to the LDAP SDK.boolean
ensureSchemaEntryIsValid()
Indicates whether to validate each entry containing the schema definitions using the schema that has been parsed thus far.java.util.Set<SchemaElementType>
getAllowedSchemaElementTypes()
Retrieves an unmodifiable set of the schema element types that may be defined in schema files.java.util.Set<SchemaElementType>
getAllowReferencesToUndefinedElementTypes()
Retrieves the types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator (e.g., by having been previously defined in the schema files).java.util.List<AttributeSyntaxDefinition>
getAttributeSyntaxes()
Retrieves a list of the attribute syntaxes that will be used in the course of validating attribute type definitions.java.util.List<MatchingRuleDefinition>
getMatchingRuleDefinitions()
Retrieves a list of the matching rules that will be used in the course of of validating attribute type definitions.java.util.regex.Pattern
getSchemaFileNamePattern()
Retrieves the pattern that schema file names are expected to match.boolean
ignoreSchemaFilesNotMatchingFileNamePattern()
Indicates whether to ignore any files in a schema directory that do not match the value pattern (if one is defined).void
setAllowAttributeTypesWithoutEqualityMatchingRule(boolean allowAttributeTypesWithoutEqualityMatchingRule)
Indicates whether to allow attribute type definitions to be missing an equality matching definition, by neither directly specifying the matching rule name or OID nor referencing a superior attribute type from which the matching rule will be inherited.void
setAllowAttributeTypesWithoutSyntax(boolean allowAttributeTypesWithoutSyntax)
Specifies whether to allow attribute type definitions to be missing an attribute syntax definition, by neither directly specifying the attribute syntax OID nor referencing a superior attribute type from which the syntax will be inherited.void
setAllowCollectiveAttributes(boolean allowCollectiveAttributes)
Specifies whether to allow collective attribute type definitions.void
setAllowedSchemaElementTypes(SchemaElementType... allowedSchemaElementTypes)
Specifies the set of schema element types that may be defined in schema files.void
setAllowedSchemaElementTypes(java.util.Collection<SchemaElementType> allowedSchemaElementTypes)
Specifies the set of schema element types that may be defined in schema files.void
setAllowElementsWithoutNames(boolean allowElementsWithoutNames)
Specifies whether to allow schema elements that do not contain names but may only be identified by an OID (or by the rule ID in the case of DIT structure rules).void
setAllowEmptyDescription(boolean allowEmptyDescription)
Specifies whether to allow schema elements to have empty descriptions.void
setAllowInvalidObjectClassInheritance(boolean allowInvalidObjectClassInheritance)
Specifies whether to allow object classes with an invalid inheritance relationship.void
setAllowMultipleEntriesPerFile(boolean allowMultipleEntriesPerFile)
Specifies whether a schema file is allowed to contain multiple entries.void
setAllowMultipleSuperiorObjectClasses(boolean allowMultipleSuperiorObjectClasses)
Specifies whether to allow object classes with multiple superior classes.void
setAllowNamesWithInitialDigit(boolean allowNamesWithInitialDigit)
Specifies whether to allow schema element names that start with a digit.void
setAllowNamesWithInitialHyphen(boolean allowNamesWithInitialHyphen)
Specifies whether to allow schema element names that start with a hyphen.void
setAllowNamesWithUnderscore(boolean allowNamesWithUnderscore)
Indicates whether to allow schema element names that contain the underscore character.void
setAllowObsoleteElements(boolean allowObsoleteElements)
Specifies whether to allow schema elements declared with the OBSOLETE modifier.void
setAllowRedefiningElements(boolean allowRedefiningElements)
Specifies whether the same schema element may be defined multiple times.void
setAllowReferencesToUndefinedElementTypes(SchemaElementType... undefinedElementTypes)
Specifies the types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator (e.g., by having been previously defined in the schema files).void
setAllowReferencesToUndefinedElementTypes(java.util.Collection<SchemaElementType> undefinedElementTypes)
Specifies the types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator (e.g., by having been previously defined in the schema files).void
setAllowSchemaFilesInSubDirectories(boolean allowSchemaFilesInSubDirectories)
Specifies whether to examine files in subdirectories when provided with a schema path that is a directory.void
setAllowStructuralObjectClassWithoutSuperior(boolean allowStructuralObjectClassWithoutSuperior)
Specifies whether to allow structural object classes that do not declare a superior class.void
setAttributeSyntaxes(java.util.Collection<AttributeSyntaxDefinition> attributeSyntaxes)
Specifies a set of attribute syntaxes that will be used in the course of validating attribute type definitions.void
setEnsureSchemaEntryIsValid(boolean ensureSchemaEntryIsValid)
Specifies whether to validate each entry containing the schema definitions using the schema that has been parsed thus far.void
setMatchingRules(java.util.Collection<MatchingRuleDefinition> matchingRules)
Specifies a set of matching rules that will be used in the course of validating attribute type definitions.void
setOIDValidation(boolean allowNonNumericOIDsUsingName, boolean allowNonNumericOIDsNotUsingName, boolean useStrictOIDValidation)
Specifies the behavior to use when validating object identifiers.void
setSchemaFileNamePattern(java.util.regex.Pattern schemaFileNamePattern, boolean ignoreSchemaFilesNotMatchingFileNamePattern)
Specifies a pattern that may be used to indicate which files should be examined if a provided path is a directory rather than a file.boolean
useStrictOIDValidation()
Indicates whether to use strict validation for numeric object identifiers.Schema
validateSchema(java.io.File schemaPath, Schema existingSchema, java.util.List<java.lang.String> errorMessages)
Validates the schema definitions in the file or set of files at the given path.
-
-
-
Constructor Detail
-
SchemaValidator
public SchemaValidator()
Creates a new schema validator with the default settings.
-
-
Method Detail
-
getSchemaFileNamePattern
@Nullable public java.util.regex.Pattern getSchemaFileNamePattern()
Retrieves the pattern that schema file names are expected to match. By default, no schema file name pattern is defined, so there are no restrictions on the name that a schema file may have.- Returns:
- The pattern that schema file names are expected to match, or
null
if no schema file name pattern is defined.
-
ignoreSchemaFilesNotMatchingFileNamePattern
public boolean ignoreSchemaFilesNotMatchingFileNamePattern()
Indicates whether to ignore any files in a schema directory that do not match the value pattern (if one is defined). By default, if a file name pattern is defined, then any files whose names do not match that pattern will be ignored.- Returns:
true
if files not matching the defined value pattern should be ignored, orfalse
if they should not be ignored but a warning should be generated.
-
setSchemaFileNamePattern
public void setSchemaFileNamePattern(@Nullable java.util.regex.Pattern schemaFileNamePattern, boolean ignoreSchemaFilesNotMatchingFileNamePattern)
Specifies a pattern that may be used to indicate which files should be examined if a provided path is a directory rather than a file.- Parameters:
schemaFileNamePattern
- A regular expression that may be used to specify the pattern that schema file names are expected to match. This may benull
if no pattern is defined and any identified files will be processed.ignoreSchemaFilesNotMatchingFileNamePattern
- Specifies whether to ignore any files in a schema directory that do not match the value pattern (if one is defined). This will only have an effect when attempting to parse schema definitions from a path that references a directory rather than a file. If this istrue
then any files that do not match the pattern (if it is non-null
will be skipped. If this isfalse
, then all files will be parsed even if they do not match the value pattern, but a warning will be added to the message list for each file that does not match the pattern. If the path provided to thevalidateSchema(java.io.File, com.unboundid.ldap.sdk.schema.Schema, java.util.List<java.lang.String>)
method refers to a file rather than a directory, then the file will always be processed, but a warning message will be added to the given list if the name does not match the given pattern.
-
allowMultipleEntriesPerFile
public boolean allowMultipleEntriesPerFile()
Indicates whether a schema file is allowed to contain multiple entries. By default, each schema file is expected to have exactly one entry.- Returns:
true
if a schema file may have multiple entries and all entries contained in that file should be processed, orfalse
if a schema file should only have a single entry and additional entries will be ignored and an error message reported.
-
setAllowMultipleEntriesPerFile
public void setAllowMultipleEntriesPerFile(boolean allowMultipleEntriesPerFile)
Specifies whether a schema file is allowed to contain multiple entries.- Parameters:
allowMultipleEntriesPerFile
- Indicates whether a schema file is allowed to contain multiple entries. If this istrue
, then all entries in each file will be examined. If this isfalse
, then only the first entry in each file will be examined and an error message will be reported for each file that contains multiple entries. In either case, an error will be reported for each schema file that does not contain any entries or that contains a malformed entry.
-
allowSchemaFilesInSubDirectories
public boolean allowSchemaFilesInSubDirectories()
Indicates whether to examine files in subdirectories when provided with a schema path that is a directory. By default, subdirectories will not be examined and an error will be reported for each subdirectory that is encountered.- Returns:
true
to examine files in subdirectories when provided with a schema path that is a directory, orfalse
if only files directly contained in the provided directory will be examined and an error will be reported if the schema directory contains subdirectories.
-
setAllowSchemaFilesInSubDirectories
public void setAllowSchemaFilesInSubDirectories(boolean allowSchemaFilesInSubDirectories)
Specifies whether to examine files in subdirectories when provided with a schema path that is a directory. This setting will be ignored if thevalidateSchema(java.io.File, com.unboundid.ldap.sdk.schema.Schema, java.util.List<java.lang.String>)
method is called with a schema path that is a file rather than a directory.- Parameters:
allowSchemaFilesInSubDirectories
- Indicates whether to examine files in subdirectories when provided with a schema path that is a directory. If this istrue
, then files in subdirectories will be examined, to any depth, with files in the directory processed first (in lexicographic order by name) and then subdirectories will be processed (also in lexicographic order by name). if this isfalse
, then only files contained directly in the specified schema directory will be examined and an error will be reported for each subdirectory that is encountered.
-
ensureSchemaEntryIsValid
public boolean ensureSchemaEntryIsValid()
Indicates whether to validate each entry containing the schema definitions using the schema that has been parsed thus far. By default, each entry will be validated to ensure that its contents conform to the schema that has been parsed from that file and all previous files.- Returns:
true
if entries containing schema definitions should be validated according to the schema, orfalse
if schema entries will not themselves be validated against the schema.
-
setEnsureSchemaEntryIsValid
public void setEnsureSchemaEntryIsValid(boolean ensureSchemaEntryIsValid)
Specifies whether to validate each entry containing the schema definitions using the schema that has been parsed thus far.- Parameters:
ensureSchemaEntryIsValid
- Indicates whether to validate each entry containing the schema definitions using the schema that has been parsed thus far. If this istrue
, then each entry will be validated to ensure that it conforms to the schema definitions read from that file and any previuos files that have already been processed and any errors identified will be reported If this isfalse
, then schema entries will not be validated.
-
getAllowedSchemaElementTypes
@NotNull public java.util.Set<SchemaElementType> getAllowedSchemaElementTypes()
Retrieves an unmodifiable set of the schema element types that may be defined in schema files. By default, all types of schema elements may be defined.- Returns:
- An unmodifiable set set of the schema element types that may be defined in schema files.
-
setAllowedSchemaElementTypes
public void setAllowedSchemaElementTypes(@NotNull SchemaElementType... allowedSchemaElementTypes)
Specifies the set of schema element types that may be defined in schema files.- Parameters:
allowedSchemaElementTypes
- The set of schema element types that may be defined in schema files. It must not benull
or empty.
-
setAllowedSchemaElementTypes
public void setAllowedSchemaElementTypes(@NotNull java.util.Collection<SchemaElementType> allowedSchemaElementTypes)
Specifies the set of schema element types that may be defined in schema files.- Parameters:
allowedSchemaElementTypes
- The set of schema element types that may be defined in schema files. It must not benull
or empty.
-
getAllowReferencesToUndefinedElementTypes
@NotNull public java.util.Set<SchemaElementType> getAllowReferencesToUndefinedElementTypes()
Retrieves the types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator (e.g., by having been previously defined in the schema files). By default, no types of undefined elements may be referenced.- Returns:
- The types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator,
-
setAllowReferencesToUndefinedElementTypes
public void setAllowReferencesToUndefinedElementTypes(@Nullable SchemaElementType... undefinedElementTypes)
Specifies the types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator (e.g., by having been previously defined in the schema files).- Parameters:
undefinedElementTypes
- The types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator. It may benull
or empty if no undefined schema elements will be permitted.
-
setAllowReferencesToUndefinedElementTypes
public void setAllowReferencesToUndefinedElementTypes(@Nullable java.util.Collection<SchemaElementType> undefinedElementTypes)
Specifies the types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator (e.g., by having been previously defined in the schema files).- Parameters:
undefinedElementTypes
- The types of schema elements that can be referenced by other elements without the referenced types being known to the schema validator. It may benull
or empty if no undefined schema elements will be permitted.
-
allowRedefiningElements
public boolean allowRedefiningElements()
Indicates whether the same schema element may be defined multiple times. By default, each schema element may be defined only once.- Returns:
true
if the same schema element may be defined multiple times, in which case subsequent definitions will override previous definitions, orfalse
if an error will be reported if the same element is encountered multiple times.
-
setAllowRedefiningElements
public void setAllowRedefiningElements(boolean allowRedefiningElements)
Specifies whether the same schema element may be defined multiple times.- Parameters:
allowRedefiningElements
- Indicates whether the same schema element may be defined multiple times. If this istrue
, then a schema element may be defined multiple times, with the most recent definition ultimately being used, as long as the redefined definition keeps the same OID and names of the former definition (although the redefined element may add additional names), but other details may be changed. If this isfalse
, then any attempt to define the same element multiple times will be reported as an error.
-
allowElementsWithoutNames
public boolean allowElementsWithoutNames()
Indicates whether to allow schema elements that do not contain names but may only be identified by an OID (or by the rule ID in the case of DIT structure rules). Note that this does not apply to attribute syntaxes, which cannot have names and may only be referenced by OID. LDAP does allow schema elements without names, but such elements are not as user-friendly and it may not be desirable to have such definitions. By default, the schema validator will allow elements without names.- Returns:
true
if the schema validator will elements without names, orfalse
if an error will be reported for each schema element (other than attribute syntaxes) without a name.
-
setAllowElementsWithoutNames
public void setAllowElementsWithoutNames(boolean allowElementsWithoutNames)
Specifies whether to allow schema elements that do not contain names but may only be identified by an OID (or by the rule ID in the case of DIT structure rules). Note that this does not apply to attribute syntaxes, which cannot have names and may only be referenced by OID. LDAP does allow schema elements without names, but such elements are not as user-friendly and it may not be desirable to have such definitions.- Parameters:
allowElementsWithoutNames
- Indicates whether to allow schema elements that do not contain names. If this istrue
, then elements without names will be allowed. If this isfalse
, then an error will be reported for each element (other than attribute syntaxes) that does not have a name.
-
allowNonNumericOIDsUsingName
public boolean allowNonNumericOIDsUsingName()
Indicates whether schema elements will be permitted to include non-numeric object identifiers that are comprised of the name for that element with "-oid" appended to it. For example, if an attribute is named "my-attr", then "my-attr-oid" may be allowed as an alternative to a numeric OID. While the official specification requires valid numeric OIDs, some servers are more relaxed about this requirement and allow OIDs to use the alternate form referenced above. By default, valid numeric OIDs will be required.- Returns:
true
if non-numeric OIDs will be allowed if they are comprised of the schema element name followed by "-oid", orfalse
if not.
-
allowNonNumericOIDsNotUsingName
public boolean allowNonNumericOIDsNotUsingName()
Indicates whether schema elements will be permitted to include non-numeric object identifiers that are of a form other than one of the element names followed by "-oid". By default, valid numeric OIDs will be required.- Returns:
true
if non-numeric OIDs will be allowed if they are not comprised of the schema element name followed by "-oid", orfalse
if not.
-
useStrictOIDValidation
public boolean useStrictOIDValidation()
Indicates whether to use strict validation for numeric object identifiers. If strict validation is to be used, then each OID must contain at least two components, the first component must be zero, one or, two, and the second component may only be greater than 39 if the first component is two. By default, strict validation will be performed for numeric OIDs.- Returns:
true
if strict validation will be performed for numeric OIDs, orfalse
if more relaxed validation will be used that only requires them to be comprised of a non-empty string comprised only of digits and periods that does not start or end with a period and does not contain consecutive periods.
-
setOIDValidation
public void setOIDValidation(boolean allowNonNumericOIDsUsingName, boolean allowNonNumericOIDsNotUsingName, boolean useStrictOIDValidation)
Specifies the behavior to use when validating object identifiers.- Parameters:
allowNonNumericOIDsUsingName
- Indicates whether to allow non-numeric OIDs if they are comprised of the name for the schema element followed by "-oid". If this istrue
, then non-numeric OIDs will be allowed if they use that form. If this isfalse
, then an error will be reported for schema elements with a non-numeric OID in that form.allowNonNumericOIDsNotUsingName
- Indicates whether to allow non-numeric OIDs if they are not comprised of the name for the schema element followed by "-oid". If this istrue
, then non-numeric OIDs will be allowed if they use that form. If this isfalse
, then an error will be reported for schema elements with a non-numeric OID that does not use the element name.useStrictOIDValidation
- Indicates whether to use strict validation for numeric object identifiers. If this isfalse
, then numeric OIDs will be required to be comprised entirely of digits and periods, must not start or end with a period, and must not contain consecutive periods. If this istrue
, then numeric OIDs must also consist of at least two components, the first component must be zero, one or two, and the second component may only be greater than 39 if the first component is two.
-
allowNamesWithInitialDigit
public boolean allowNamesWithInitialDigit()
Indicates whether to allow schema element names that start with a digit. LDAP specifications require that the first character of a schema element name be a letter, but some servers allow names that start with digits. By default, schema element names will not be allowed to start with a digit.- Returns:
true
if schema element names will be permitted to start with digits, orfalse
if an error will be reported for names that start with a digit.
-
setAllowNamesWithInitialDigit
public void setAllowNamesWithInitialDigit(boolean allowNamesWithInitialDigit)
Specifies whether to allow schema element names that start with a digit. LDAP specifications require that the first character of a schema element name be a letter, but some servers allow names that start with digits.- Parameters:
allowNamesWithInitialDigit
- Indicates whether to allow schema element names that start with a digit. If this istrue
, then names will be permitted to start with a digit. If this isfalse
, then an error will be reported for each name that starts with a digit.
-
allowNamesWithInitialHyphen
public boolean allowNamesWithInitialHyphen()
Indicates whether to allow schema element names that start with a hyphen. LDAP specifications require that the first character of a schema element name be a letter, but some servers allow names that start with hyphens. By default, schema element names will not be allowed to start with a hyphen.- Returns:
true
if schema element names will be permitted to start with hyphens, orfalse
if an error will be reported for names that start with a hyphen.
-
setAllowNamesWithInitialHyphen
public void setAllowNamesWithInitialHyphen(boolean allowNamesWithInitialHyphen)
Specifies whether to allow schema element names that start with a hyphen. LDAP specifications require that the first character of a schema element name be a letter, but some servers allow names that start with hyphens.- Parameters:
allowNamesWithInitialHyphen
- Indicates whether to allow schema element names that start with a hyphen. If this istrue
, then names will be permitted to start with a hyphen. If this isfalse
, then an error will be reported for each name that starts with a hyphen.
-
allowNamesWithUnderscore
public boolean allowNamesWithUnderscore()
Indicates whether to allow schema element names that contain the underscore character. LDAP specifications do not permit underscores in schema element names, but some servers do allow it. By default, schema element names will not be allowed to contain an underscore.- Returns:
true
if schema element names will be permitted to contain underscores, orfalse
if an error will be reported for names that contain an underscore.
-
setAllowNamesWithUnderscore
public void setAllowNamesWithUnderscore(boolean allowNamesWithUnderscore)
Indicates whether to allow schema element names that contain the underscore character. LDAP specifications do not permit underscores in schema element names, but some servers do allow it.- Parameters:
allowNamesWithUnderscore
- Indicates whether to allow schema element names that contain the underscore character. If this istrue
, then names will be permitted to contain underscores. If this isfalse
, then an error will be reported for each name that contains an underscore.
-
allowEmptyDescription
public boolean allowEmptyDescription()
Indicates whether to allow schema elements to have empty descriptions. LDAP specifications forbid empty quoted strings in schema definitions, but some servers allow it. By default, empty descriptions will not be allowed, and an error will be reported for every schema element that has an empty description.- Returns:
true
if empty descriptions will be allowed, orfalse
if errors will be reported for schema elements with empty descriptions.
-
setAllowEmptyDescription
public void setAllowEmptyDescription(boolean allowEmptyDescription)
Specifies whether to allow schema elements to have empty descriptions. LDAP specifications forbid empty quoted strings in schema definitions, but some servers allow it.- Parameters:
allowEmptyDescription
- Indicates whether to allow schema elements to have empty descriptions. If this istrue
, then schema elements will be permitted to have empty descriptions. If it isfalse
, then an error will be reported for each schema element with an empty description.
-
getAttributeSyntaxes
@NotNull public java.util.List<AttributeSyntaxDefinition> getAttributeSyntaxes()
Retrieves a list of the attribute syntaxes that will be used in the course of validating attribute type definitions. By default, the schema validator will be preconfigured with a default set of standard attribute syntaxes (as set by theconfigureLDAPSDKDefaultAttributeSyntaxes()
method), in addition to any attribute type definitions contained in schema entries.- Returns:
- A list of the attribute syntaxes that will be used in the course of validating attribute type definitions, or an empty list if the list of available syntaxes will be defined in the schema files.
-
setAttributeSyntaxes
public void setAttributeSyntaxes(@Nullable java.util.Collection<AttributeSyntaxDefinition> attributeSyntaxes)
Specifies a set of attribute syntaxes that will be used in the course of validating attribute type definitions.- Parameters:
attributeSyntaxes
- The set of attribute syntaxes that will be used in the course of validating attribute type definitions. It may benull
or empty if only syntaxes defined in the schema files will be used.
-
configureLDAPSDKDefaultAttributeSyntaxes
public void configureLDAPSDKDefaultAttributeSyntaxes()
Configures the schema validator to use a default set of attribute syntaxes that are known to the LDAP SDK. Any other syntaxes that may have been defined will be cleared.
-
allowAttributeTypesWithoutSyntax
public boolean allowAttributeTypesWithoutSyntax()
Indicates whether to allow attribute type definitions to be missing an attribute syntax definition, by neither directly specifying the attribute syntax OID nor referencing a superior attribute type from which the syntax will be inherited. The LDAP specification requires that each attribute type specify its syntax or inherit it from a superior type, but some directory servers will assume a default syntax (e.g., Directory String) for attribute types that do not specify it and are not configured with a superior type. By default, any attribute type that does not specify a syntax and cannot inherit it from a superior type will be flagged as an error.- Returns:
true
if attribute type definitions will be permitted to omit both an attribute syntax and a superior type, orfalse
if an error will be reported for each such attribute type.
-
setAllowAttributeTypesWithoutSyntax
public void setAllowAttributeTypesWithoutSyntax(boolean allowAttributeTypesWithoutSyntax)
Specifies whether to allow attribute type definitions to be missing an attribute syntax definition, by neither directly specifying the attribute syntax OID nor referencing a superior attribute type from which the syntax will be inherited. The LDAP specification requires that each attribute type specify its syntax or inherit it from a superior type, but some directory servers will assume a default syntax (e.g., Directory String) for attribute types that do not specify it and are not configured with a superior type.- Parameters:
allowAttributeTypesWithoutSyntax
- Indicates whether to allow attribute type definitions to be missing an attribute syntax definition, by neither directly specifying the attribute syntax OID nor referencing a superior attribute type from which the syntax will be inherited. If this istrue
, then attribute types that do not specify either a syntax OID or a superior type will be permitted. If this isfalse
, then an error will be reported for each such attribute type.
-
getMatchingRuleDefinitions
@NotNull public java.util.List<MatchingRuleDefinition> getMatchingRuleDefinitions()
Retrieves a list of the matching rules that will be used in the course of of validating attribute type definitions. By default, the schema validator will be preconfigured with a default set of standard matching rules (as set by theconfigureLDAPSDKDefaultMatchingRules()
method), in addition to any matching rule definitions contained in schema entries.- Returns:
- A list of the matching rules that will be used in the course of validating attribute type definitions, or an empty list if the list of matching rules will be defined in the schema files.
-
setMatchingRules
public void setMatchingRules(@Nullable java.util.Collection<MatchingRuleDefinition> matchingRules)
Specifies a set of matching rules that will be used in the course of validating attribute type definitions.- Parameters:
matchingRules
- The set of attribute syntaxes that will be used in the course of validating attribute type definitions. It may benull
or empty if only syntaxes defined in the schema files will be used.
-
configureLDAPSDKDefaultMatchingRules
public void configureLDAPSDKDefaultMatchingRules()
Configures the schema validator to use a default set of matching rules that that are known to the LDAP SDK. Any other syntaxes that may have been defined will be cleared.
-
allowAttributeTypesWithoutEqualityMatchingRule
public boolean allowAttributeTypesWithoutEqualityMatchingRule()
Indicates whether to allow attribute type definitions to be missing an equality matching definition, by neither directly specifying the matching rule name or OID nor referencing a superior attribute type from which the matching rule will be inherited. It is technically legal to have an attribute type definition that does not include an equality matching rule and does not inherit an equality matching rule from a superior type, this may not be desirable, as the server should fall back to byte-for-byte matching (although some servers may assume a default matching rule based on the syntax). By default, attribute types that do not specify an equality matching rule will be permitted.- Returns:
true
if attribute type definitions will be permitted to omit both an attribute syntax and a superior type, orfalse
if an error will be reported for each such attribute type.
-
setAllowAttributeTypesWithoutEqualityMatchingRule
public void setAllowAttributeTypesWithoutEqualityMatchingRule(boolean allowAttributeTypesWithoutEqualityMatchingRule)
Indicates whether to allow attribute type definitions to be missing an equality matching definition, by neither directly specifying the matching rule name or OID nor referencing a superior attribute type from which the matching rule will be inherited. It is technically legal to have an attribute type definition that does not include an equality matching rule and does not inherit an equality matching rule from a superior type, this may not be desirable, as the server should fall back to byte-for-byte matching (although some servers may assume a default matching rule based on the syntax).- Parameters:
allowAttributeTypesWithoutEqualityMatchingRule
- Specifies whether to allow attribute type definitions to be missing an equality matching definition, by neither directly specifying the matching rule name or OID nor referencing a superior attribute type from which the matching rule will be inherited. If this istrue
, then attribute types that do not specify either an equality matching rule or a superior type will be permitted. If this isfalse
, then an error will be reported for each such attribute type.
-
allowMultipleSuperiorObjectClasses
public boolean allowMultipleSuperiorObjectClasses()
Indicates whether to allow object classes with multiple superior classes. This is allowed by LDAP specifications, but some servers do not support it. By default, object classes with multiple superior classes will be permitted.- Returns:
true
if object classes will be allowed to have multiple superior classes, orfalse
if an error will be reported for each object class with multiple superiors.
-
setAllowMultipleSuperiorObjectClasses
public void setAllowMultipleSuperiorObjectClasses(boolean allowMultipleSuperiorObjectClasses)
Specifies whether to allow object classes with multiple superior classes. This is allowed by LDAP specifications, but some servers do not support it.- Parameters:
allowMultipleSuperiorObjectClasses
- Indicates whether to allow object classes with multiple superior classes. If this istrue
, then object classes with multiple superiors will be allowed. If this isfalse
, then an error will be reported for each object class with more than one superior class.
-
allowStructuralObjectClassWithoutSuperior
public boolean allowStructuralObjectClassWithoutSuperior()
Indicates whether to allow structural object classes that do not declare a superior class. Technically, structural object classes must inherit from structural or abstract classes, although some servers may assume a default superior class of "top" for a structural class that does not declare any superiors. By default, an error will be reported for each structural object class that does not explicitly declare any superior class.- Returns:
true
if object classes that do not declare their superiors will be permitted, rofalse
if an error will be reported for each structural class that does not declare any superiors.
-
setAllowStructuralObjectClassWithoutSuperior
public void setAllowStructuralObjectClassWithoutSuperior(boolean allowStructuralObjectClassWithoutSuperior)
Specifies whether to allow structural object classes that do not declare a superior class. Technically, structural object classes must inherit from structural or abstract classes, although some servers may assume a default superior class of "top" for a structural class that does not declare any superiors.- Parameters:
allowStructuralObjectClassWithoutSuperior
- Indicates whether to allow structural object classes that do not declare a superior class. If this istrue
, then structural object classes that do not declare any superior class will be assumed to subclass "top". if this isfalse
, then an error will be reported for each structural object class that does not define any superior class.
-
allowInvalidObjectClassInheritance
public boolean allowInvalidObjectClassInheritance()
Indicates whether to allow object classes with an invalid inheritance relationship. As per LDAP specifications, structural object classes can only inherit from structural or abstract classes, auxiliary classes can only inherit from auxiliary or abstract classes, and abstract classes can only inherit from other abstract classes. By default, the schema validator will report an error for any object class that violates this constraint.- Returns:
true
if the schema validator will allow object classes with invalid inheritance relationships, orfalse
if an error will be reported for each object class with an invalid superior class.
-
setAllowInvalidObjectClassInheritance
public void setAllowInvalidObjectClassInheritance(boolean allowInvalidObjectClassInheritance)
Specifies whether to allow object classes with an invalid inheritance relationship. As per LDAP specifications, structural object classes can only inherit from structural or abstract classes, auxiliary classes can only inherit from auxiliary or abstract classes, and abstract classes can only inherit from other abstract classes.- Parameters:
allowInvalidObjectClassInheritance
- Indicates whether to allow object classes with an invalid inheritance relationship. If this istrue
, then invalid inheritance relationships will be allowed. If this isfalse
, then an error will be reported for each object class with an invalid superior class reference.
-
allowCollectiveAttributes
public boolean allowCollectiveAttributes()
Indicates whether to allow collective attribute type definitions. Collective attributes (as described in RFC 3671) have read-only values that are generated by the server rather than provided by clients. Although they are part of the LDAP specification, some servers do not support them or provide alternate virtual attribute mechanisms. By default, collective attribute definitions will be allowed.- Returns:
true
if collective attributes will be allowed, orfalse
if the schema validator will report an error for each collective attribute type definition.
-
setAllowCollectiveAttributes
public void setAllowCollectiveAttributes(boolean allowCollectiveAttributes)
Specifies whether to allow collective attribute type definitions. Collective attributes (as described in RFC 3671) have read-only values that are generated by the server rather than provided by clients. Although they are part of the LDAP specification, some servers do not support them or provide alternate virtual attribute mechanisms.- Parameters:
allowCollectiveAttributes
- Indicates whether to allow collective attribute type definitions. If this istrue
, then collective attribute type definitions will be allowed. If this isfalse
, then an error will be reported for each collective attribute type definition.
-
allowObsoleteElements
public boolean allowObsoleteElements()
Indicates whether to allow schema elements declared with the OBSOLETE modifier. Obsolete schema elements are those that are no longer active and cannot be used in updates, although some servers may not support obsolete schema elements. By default, obsolete elements will be allowed.- Returns:
true
if schema elements declared with the OBSOLETE modifier will be allowed, orfalse
if an error will be reported for each schema element declared as OBSOLETE.
-
setAllowObsoleteElements
public void setAllowObsoleteElements(boolean allowObsoleteElements)
Specifies whether to allow schema elements declared with the OBSOLETE modifier. Obsolete schema elements are those that are no longer active and cannot be used in updates, although some servers may not support obsolete schema elements.- Parameters:
allowObsoleteElements
- Indicates whether to allow schema elements declared with the OBSOLETE modifier. If this istrue
, then obsolete elements will be allowed. If this isfalse
, then an error will be reported for each OBSOLETE schema element.
-
validateSchema
@Nullable public Schema validateSchema(@NotNull java.io.File schemaPath, @Nullable Schema existingSchema, @NotNull java.util.List<java.lang.String> errorMessages)
Validates the schema definitions in the file or set of files at the given path.- Parameters:
schemaPath
- The file or directory containing the schema definitions to validate. It must not benull
, and the target file or directory must exist. If it is a directory, then files in the directory will be processed in lexicographic order by filename, optionally restricted to files matching the schema file name pattern.existingSchema
- An existing schema to use in the course of validating definitions. It may benull
if there is no existing schema and only the definitions read from the provided path should be used.errorMessages
- A list that will be updated with error messages about any problems identified during processing. It must not benull
, and it must be updatable.- Returns:
- A
Schema
object that contains the definitions that were loaded. This may include schema elements that were flagged as invalid (if they could be parsed). If an existing schema was already available, the schema that is returned will be a merged representation of the existing schema and the newly loaded schema. This may benull
if an error prevented any schema files from being processed and no existing schema was provided.
-
-