Package com.evolveum.midpoint.schema.processor

Interface ResourceObjectDefinition

All Superinterfaces:
AssociationDefinitionStore, AttributeDefinitionStore, Cloneable, ComplexTypeDefinition, DebugDumpable, Definition, Freezable, IdentifiersDefinitionStore, LayeredDefinition, LocalItemDefinitionStore, PrismContextSensitive, Revivable, Serializable, SmartVisitable<Definition>, TypeDefinition, Visitable<Definition>
All Known Subinterfaces:
CompositeObjectDefinition, CompositeObjectDefinitionDelegator, MutableResourceObjectClassDefinition, ResourceObjectClassDefinition, ResourceObjectClassDefinitionDelegator, ResourceObjectDefinitionDelegator, ResourceObjectTypeDefinition, ResourceObjectTypeDefinitionDelegator
All Known Implementing Classes:
AbstractResourceObjectDefinitionImpl, CompositeObjectDefinitionImpl, ResourceObjectClassDefinitionImpl, ResourceObjectTypeDefinitionImpl, TransformableComplexTypeDefinition.TrCompositeObjectDefinition, TransformableComplexTypeDefinition.TrResourceObjectClassDefinition, TransformableComplexTypeDefinition.TrResourceObjectDefinition, TransformableComplexTypeDefinition.TrResourceObjectTypeDefinition
public interface ResourceObjectDefinition extends ComplexTypeDefinition, IdentifiersDefinitionStore, AttributeDefinitionStore, AssociationDefinitionStore, LayeredDefinition
A definition that describes either an object class (as fetched from the resource, optionally refined by `schemaHandling`), or an object type (as defined in `schemaHandling` part of resource definition). It is used as a common interface to both "raw" and "refined" definitions. (Raw definitions are used e.g. in cases when there is no `schemaHandling` for given object class, or for the resource as a whole.) Note: Before midPoint 4.5, this interface was known as `ObjectClassComplexTypeDefinition`. So the hierarchy was: ComplexTypeDefinition ^ | ObjectClassComplexTypeDefinition ^ | RefinedObjectClassDefinition Now the hierarchy is like this: ComplexTypeDefinition ^ | ResourceObjectDefinition ^ | +------------------+-------------------+ | | ResourceObjectClassDefinition ResourceObjectTypeDefinition This change eliminates e.g. the need to create "artificial" refined object class definitions just to allow model and provisioning modules to work with object classes not described in schema handling. (Confusion stemmed e.g. from the fact that `RefinedObjectClassDefinition` had to have kind/intent. This is now fixed.)