Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Development/JPA 2.0/validation api integration"
(→JPA 2.0: Validation API Integration) |
(→JPA 2.0: Validation API Integration) |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
− | = JPA 2.0: Validation API Integration = | + | = JPA 2.0: Validation API Integration = |
− | [[EclipseLink/Development/ | + | [[EclipseLink/Development/JPA 2.0|JPA 2.0 Root]] | {{bug|266927}} |
− | + | == Issue Summary == | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | JPA 2.0 spec mandates that a persistence provider needs to validate managed classes (entities, mapped superclasses, and embeddable classes) using Bean Validation API(JSR-303) on lifecycle events. Please see JPA spec section 3.6 for more details. | |
− | + | ||
− | == | + | == General Solution == |
− | + | === Goals === | |
− | + | ||
− | + | *EclipseLink should not require either Bean Validation API or a Bean Validation Provider at run time if Bean Validation is not enabled. | |
+ | *There should be no performance overhead at runtime if Bean Validation is disabled | ||
+ | *There should be no dependency from foundation to jpa module | ||
+ | *Ensure EclipseLink JPA users who do not wish to use Validation do not require the javax.validation library on their classpath | ||
− | === | + | === Bootstrapping of ValidatorFactory and other Validation metadata === |
− | + | '''Validation Mode:''' Specified by user as value of property "javax.persistence.validation.mode" or as "validation-mode" element in persistence.xml.<br> '''Validation Groups:''' Specified by user as value of property "javax.persistence.validation.group.pre-*". It is specified as comma separated fully qualified class names of the groups.<br> '''ValidatorFactory:''' An instance of the factory would be used to obtain Validator used to perform validation. ValidatorFactory is obtained in one of following ways as specified by JPA spec: | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | *: | + | |
− | + | *Passed as value of property "javax.persistence.validation.factory" while creating EMF using Persistence.createEMF() or from a JavaEE container | |
+ | *While running in JavaSE mode, created by EclipseLink using Validation.buildDefaultValidatorFactory() | ||
− | == | + | === Enabling Automatic Bean Validation on lifecycle events === |
− | * | + | *Introduce a DescriptorEventListener listener called BeanValidationListener. |
+ | **BeanValidationListener would be initialized with ValidatorFactory, Validation Mode, Validation Group and a pointer to the MetaDataProject | ||
+ | *Install this listener at deployment time if Bean Validation is enabled | ||
+ | *BeanValidationListener performs Bean Validation on life cycle events prePersit, preUpdate and preRemove | ||
− | == | + | === Disabling cascading of validation and loading of lazy attributes === |
− | + | Spec requires that while executing automatic validation, Validation cascade (@Valid) must not occur for entity associations (single- or multi-valued). Validation should also not trigger loading of a lazy attribute. | |
− | + | *When obtaining a Validator instance to perform validation, supply a TraversableResolver that | |
+ | **returns false for isReachable() call corresponding to any lazy atttibutes | ||
+ | **returns false for isCascadable() call corresponding to any relationships | ||
− | + | <br> | |
− | == | + | === Open Issues === |
− | + | ||
− | == | + | == Future Considerations == |
− | + | *Bean Validation Meta Data constraints like @Size can be used at DDL generation time. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + |
Latest revision as of 01:45, 31 July 2009
JPA 2.0: Validation API Integration
Issue Summary
JPA 2.0 spec mandates that a persistence provider needs to validate managed classes (entities, mapped superclasses, and embeddable classes) using Bean Validation API(JSR-303) on lifecycle events. Please see JPA spec section 3.6 for more details.
General Solution
Goals
- EclipseLink should not require either Bean Validation API or a Bean Validation Provider at run time if Bean Validation is not enabled.
- There should be no performance overhead at runtime if Bean Validation is disabled
- There should be no dependency from foundation to jpa module
- Ensure EclipseLink JPA users who do not wish to use Validation do not require the javax.validation library on their classpath
Bootstrapping of ValidatorFactory and other Validation metadata
Validation Mode: Specified by user as value of property "javax.persistence.validation.mode" or as "validation-mode" element in persistence.xml.
Validation Groups: Specified by user as value of property "javax.persistence.validation.group.pre-*". It is specified as comma separated fully qualified class names of the groups.
ValidatorFactory: An instance of the factory would be used to obtain Validator used to perform validation. ValidatorFactory is obtained in one of following ways as specified by JPA spec:
- Passed as value of property "javax.persistence.validation.factory" while creating EMF using Persistence.createEMF() or from a JavaEE container
- While running in JavaSE mode, created by EclipseLink using Validation.buildDefaultValidatorFactory()
Enabling Automatic Bean Validation on lifecycle events
- Introduce a DescriptorEventListener listener called BeanValidationListener.
- BeanValidationListener would be initialized with ValidatorFactory, Validation Mode, Validation Group and a pointer to the MetaDataProject
- Install this listener at deployment time if Bean Validation is enabled
- BeanValidationListener performs Bean Validation on life cycle events prePersit, preUpdate and preRemove
Disabling cascading of validation and loading of lazy attributes
Spec requires that while executing automatic validation, Validation cascade (@Valid) must not occur for entity associations (single- or multi-valued). Validation should also not trigger loading of a lazy attribute.
- When obtaining a Validator instance to perform validation, supply a TraversableResolver that
- returns false for isReachable() call corresponding to any lazy atttibutes
- returns false for isCascadable() call corresponding to any relationships
Open Issues
Future Considerations
- Bean Validation Meta Data constraints like @Size can be used at DDL generation time.