[Hibernate-JIRA] Created: (BVAL-225) JSR303 1.1: support resource bundles in constraint annotation packages
by Gabriele Del Prete (JIRA)
JSR303 1.1: support resource bundles in constraint annotation packages
----------------------------------------------------------------------
Key: BVAL-225
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-225
Project: Bean Validation
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Gabriele Del Prete
Attachments: ResourceBundleMessageInterpolator.java
(I published this same proposal also on the forum, and copying it here so that it does not get lost)
This is a proposal for the new version of JSR 303 (v1.1 ?).
The proposal is: modify the default message interpolation algorithm (section 4.3.1.1) so that the validation engine looks for a Resource Bundle called "ValidationMessages" in the constraint annotation's own package.
For example, when validating constraint annotation com.gdpcons.constraints.MustEqual, validator should also look for messages in a resource bundle called com.gdpcons.constraints.ValidationMessages.
The constraint annotation package ValidationMessages resource bundle should be checked after the "user" ValidationMessages resource bundle, but before the BeanValidation provider's own private ValidationMessages resource bundle, so as to allow users to override the string provided by the constraint annotation resource bundle.
This would allow people to write redistributable collections of constraint annotations, since as of today it's not possible to use multiple ValidationMessages resource bundles files (one will override all the others in the classpath); and it would still allow users to override the provided messages just by a new definition for the message key in their own ValidationMessages resource bundle.
I've written an example implementation, by modifying Hibernate Validator's own ResourceBundleMessageInterpolator. It seams to work without side effects, and is a very straightforward implementation.
See it attached to this issue.
--
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
11 years, 6 months
[Hibernate-JIRA] Created: (BVAL-211) Consider making javax.validation.ValidatorContext a self-referential generic type
by Gunnar Morling (JIRA)
Consider making javax.validation.ValidatorContext a self-referential generic type
---------------------------------------------------------------------------------
Key: BVAL-211
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-211
Project: Bean Validation
Issue Type: Improvement
Components: spec-general
Affects Versions: 1.0 final
Reporter: Gunnar Morling
Priority: Minor
It should be investigated whether the interface javax.validation.ValidatorContext could be re-defined as self-referential generic type as follows:
{code:java}
public interface ValidatorContext <V extends ValidatorContext<V>> {
V messageInterpolator(MessageInterpolator messageInterpolator);
V traversableResolver(TraversableResolver traversableResolver);
V constraintValidatorFactory(ConstraintValidatorFactory factory);
Validator getValidator();
}
{code}
Provider-specific extensions of this interface (such as [HibernateValidatorContext|https://github.com/hibernate/hibernate-validato...]) then wouldn't have to re-define all of ValidatorContext's methods returning their own type (which they currently must do in order to allow for the method chaining pattern to work correctly).
Generally this is a breaking change, as existing implementations wouldn't compile with the proposed new version of the interface. But as it is intended to be implemented by BV providers only, this seems acceptable. API users would get a raw type warning if they have variables of type ValidatorContext. This should happen very rarely though, as ValidatorContext typically is only used in chained method calls (with a final getValidator() invocation) but not assigned to a variable.
--
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
11 years, 6 months
[Hibernate-JIRA] Created: (HV-462) Allow ordered validator's annotations
by Pavla Nováková (JIRA)
Allow ordered validator's annotations
-------------------------------------
Key: HV-462
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-462
Project: Hibernate Validator
Issue Type: New Feature
Affects Versions: 4.1.0.Final
Reporter: Pavla Nováková
1) Consider domain object with simple constraints (just to demonstrate required feature, my real example uses custom cost-expensive validation of pictures):
{code}
public class DomainObject {
@Size(max=50) // constraint 1a
@Pattern(regexp="[a-z]*") // constraint 1b
private String name;
@Size(max=20) // constraint 2a
@URL // constraint 2b
private String email;
@Size(max=100) // constraint 3a
@Pattern(regexp="[0-9]*") // constraint 3b
private String password;
{code}
2) Consider validation requirements:
* all properties should be validated together (like one virtual group)
* FOR EACH PROPERTY validation should occur in ordered steps given by order of annotations for given property (if first validation step fails, SKIP following validation process on given property and add validation message specific to failed / last validated constraint for the property)
3) Why it is useful:
* simple cost-effective validation followed by cost-expensive validation (not executed if simple constraint fails)
* we get just the "main and specific validation error" (otherwise we have to iterate over all errors "to find the cause" or we display two or more errors for one property which is not user-friendly according my opinion)
3) What is unusable:
* groups and group sequences (it is not possible to create proper combination of groups and sequences for more than one property with two or more constraints)
* composed constraints (@ReportAsSingleViolation included)
** we cannot use @ReportAsSingleViolation since we want specific message for each failed constraint
** and main problem is: if we use composed constraints all constraints are evaluated for given property
4) Proposed solution:
* add optional order attribute to validator annotations and stop validation on first failure if order is specified
* possibly this can be configured on global validator level with property "skipOnFirstFailure" together with some given convention for annotation order
Please let me know if need better explanation or working examples.
--
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
11 years, 6 months
[Hibernate-JIRA] Created: (HHH-3502) getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type
by Sean Bridges (JIRA)
getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type
----------------------------------------------------------------------------------------------------------------------------
Key: HHH-3502
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3502
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Sean Bridges
Priority: Minor
I have an entity interface,
public interface IEntity {
public Object getId();
}
and I have an entity, say User that implements this interface with an id method
@Id
public Long getId() {
return id;
}
I can call getId() on an uninitialized proxy with,
user.getId()
however, if I call getId() in this way,
((IEntity) user)).getId()
I get org.hibernate.LazyInitializationException: could not initialize proxy - no Session
Looking at the code, BasicLazyInitializer has these lines,
else if ( isUninitialized() && method.equals(getIdentifierMethod) ) {
return getIdentifier();
}
the method.equals(getIdentifierMethod) returns false. The methods are not equal() because they have different return types (this is allowed in 1.5 with covariant return types).
Hibernate should not use Method.equals(), but should instead use the code below (modified from Method.equals(Object)),
public boolean equalsIgnoringReturnType(Method m1, Method m2) {
if ((m1.getDeclaringClass() != m2.getDeclaringClass()) {
return false;
}
if (m1.getName() != m2.getName()) {
return false;
}
Class[] params1 = m1.getParameterTypes();
Class[] params2 = m2.getParameterTypes();
if (params1.length != params2.length) {
return false;
}
for (int i = 0; i < params1.length; i++) {
if (params1[i] != params2[i])
return false;
}
return true;
}
--
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
11 years, 6 months