Package com.evolveum.midpoint.schema.config
package com.evolveum.midpoint.schema.config
This is an experiment how to provide reliable and consistent information about the origin of individual configuration items
(mappings, expressions, etc). The primary goal is to be able to derive expression profiles for execution of embedded
expressions.
Secondary goals:
. Understandable, consistent, and reliable error reporting. We use the origin information, along with custom "config item"
classes to do that.
. Easy access to the content of configuration items. Again, this is due to the use of custom "config item" classes.
These custom config classes are on a halfway between raw "beans" like `ExpressionType`, `MappingType`,
and fully processed (parsed, compiled) objects like `Expression`, `Mapping`, and so on.
Design notes:
. The names of the classes should correspond to the names of respective beans, even if they may not seem the optimal ones
(from the point of view of the current knowledge). The idea is to make them easily discernible and, in the future, maybe
also (semi)automatically generated.
+
The exception is when a bean has multiple uses like `ExpressionType` used as a library function.
== Broader context
The idea of providing a wrapper for configuration items is not new. However, the previous attempts were limited
to specific domains, for example:
- activity definitions (`ActivityDefinition` and its constituents, especially `WorkDefinition`),
- refined resource object class and attribute definitions
(
ResourceObjectDefinition
and its parts) - although these are more parsed
than configuration items here,
- TODO what else?
== Boundaries: what is this NOT meant to be
This is not to store the fully processed (parsed) information like `Expression` or `Mapping`.
It should be really a quite thin wrapper around the raw beans, with limited responsibilities mentioned above.
HIGHLY EXPERIMENTAL. MAYBE NOT USABLE FOR THE FUTURE. MAYBE YES, WITH SOME CODE GENERATION SUPPORT.-
ClassDescriptionException from naming convention (because of assignment vs inducement dichotomy).AbstractMappingConfigItem<M extends AbstractMappingType>Functionality common to all "mapping config items".AbstractPolicyRuleConfigItem<R extends PolicyRuleType>Exception from naming rulesType or class definition in schema handling.Used to access both "legacy" and "modern" association definitions.Unfortunately, this cannot extend MappingConfigItem because of the conflict in generic type parameters.Helper class that provides complex information about a configuration item (e.g., a mapping).Description of an origin of a configuration item (expression, mapping, and so on).Represents an item that was defined out of context of any prism object.Represents an item that was generated by the system.An item that is a part of a delta (of unspecified provenience) that is targeting a given object.A typical case: an item that is a part of a prism object.Represents an origin we are not currently able to determine exactly.Currently used for custom event handlers, as they are security-sensitive.Represents an
ExpressionParameterType
that is part of aFunctionExpressionEvaluatorType
i.e.Represents anExpressionType
that is part of aFunctionLibraryType
as a custom function.Represents anFunctionExpressionEvaluatorType
i.e.TODO what about the subtypes ofObjectSelectorType
?Unfortunately, this cannot extend MappingConfigItem because of the conflict in generic type parameters.PolicyActionConfigItem<A extends PolicyActionType>Used for both association definitions and resource object construction with associations.Access to legacy configuration (i.e.This is intended to help with refined resource definition parsing process.TEMPORARYShadowAssociationTypeParticipantDefinitionConfigItem<PT extends ShadowAssociationTypeParticipantDefinitionType>