[Hibernate-JIRA] Created: (HV-135) Constraints can contains constraint annotations to validate params before initialize is called
by Emmanuel Bernard (JIRA)
Constraints can contains constraint annotations to validate params before initialize is called
----------------------------------------------------------------------------------------------
Key: HV-135
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-135
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Reporter: Emmanuel Bernard
not high priority
>From Sebastian Thomschke
--------------------------------------
I just had a look through the Hibernate Validator code, what struck me
was the way how you validate parameters. E.g.
private void validateParameters() {
if ( min < 0 ) {
throw new ValidationException( "The min parameter cannot be
negative." );
}
if ( max < 0 ) {
throw new ValidationException( "The max paramter cannot be
negative." );
}
if ( max < min ) {
throw new ValidationException( "The length cannot be
negative." );
}
}
I just had the idea, why don't we use the constraint annotations for the
built-in constraints themselves? E.g.
/**
* @return size the element must be higher or equal to
*/
@Min(0)
int min() default 0;
/**
* @return size the element must be lower or equal to
*/
@Min(0)
int max() default Integer.MAX_VALUE;
Then this kind of parameter validation could be done by the framework
and must not be repeated in every validator implementation.
What do you think?
Regards,
Seb
--------------------------------------
Emmanuel
Your idea is interesting. It could lead to infinite recursion if someone does not pay attention but could work.
I think it would better be a product feature though instead of a spec feature for this rev at least. We can't have "class" level constraints though as it conflicts with the composition model.
WDYT?
it seems to me that the ValidationException is wrong in the example you gave.
http://opensource.atlassian.com/projects/hibernate/browse/HV-134
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HV-388) Support property level ScriptAssert
by jason shi (JIRA)
Support property level ScriptAssert
-----------------------------------
Key: HV-388
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-388
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Affects Versions: 4.1.0.Final
Reporter: jason shi
Assignee: Hardy Ferentschik
Current hibernate validator's ScriptAssert can only defined on the Class level, not property level.
In OVal,it can define the ScriptAssert at the property level,eg:
{code}
public class BusinessObject
{
@NotNull
public String deliveryAddress;
@NotNull public String invoiceAddress;
// mailingAddress must either be the delivery address or the invoice address
@Assert(expr = "_value ==_this.deliveryAddress || _value == _this.invoiceAddress", lang = "groovy")
public String mailingAddress;
}
{code}
With property level,we can get following benefit:
1. Can be used in single property validation, It's very useful in UI layer validation
2. The validation rule is close to the property definition, it's easy to manage
In JSR303 spec, the ValueContext is not passed to the Contrain Validator as a parameter,
so the validator can't get the "Current Bean" of the current property to be validated.
The validation engine need to some special work to support this feature.
OVal can do this, so it won't be a problem for hibernate validator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HV-356) Consider if issue when bean's hashCode() uses lazy-loaded property needs to be addressed in default event listener/validator implementation
by Roman Arkadijovych Muntyanu (JIRA)
Consider if issue when bean's hashCode() uses lazy-loaded property needs to be addressed in default event listener/validator implementation
-------------------------------------------------------------------------------------------------------------------------------------------
Key: HV-356
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-356
Project: Hibernate Validator
Issue Type: Task
Components: validators
Affects Versions: 4.1.0.Final
Environment: Hibernate 3.5.3-Final, Spring 3.0.3.RELEASE, Hibernate Validator 4.1.0.Final
Reporter: Roman Arkadijovych Muntyanu
Assignee: Hardy Ferentschik
Priority: Minor
This issue has been created based on contributor's request in discussion
https://forum.hibernate.org/viewtopic.php?f=9&t=1006194&start=0
related to the issue occurring when persisted object's hashCode() implementation uses lazily-loaded properties.
This triggers "collection [...] was not processed by flush()" issue with default Hibernate Validator event listener (org.hibernate.cfg.beanvalidation.BeanValidationEventListener) and validator (org.hibernate.validator.engine.ValidatorImpl) implementations because of hashCode() usage in SingleThreadCachedTraversableResolver.buildHashCode().
The purpose of this task is to consider whether this is or is not an overlook in assumptions made in validator implementation. And depending on the result following outcomes are expected:
* either create a separate task for addressing the issue in default validator implementation;
* or provide suggestions and (if possible) examples on how the issue can be addressed at the framework user's site if lazily-loaded properties usage IS appropriate.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months