Method constraints and TraversableResolver contract
by Gunnar Morling
Hi all,
working on the TCK, I'm wondering whether a BV provider should use
TraversableResolver#isReachable() and isCascadable()) to check whether a
validated method parameter or return value may be accessed/traversed.
I think checking for cascadability might make sense, but I'm not so sure
about checking for reachability; can e.g. be a parameter not reachable?
If any of the checks shall be done for method validation, we need to update
the TraversableResolver contract (section 4.6.3) which
currently explicitly speaks about properties and is limited to the element
types FIELD and METHOD.
WDYT?
--Gunnar
13 years
Should we expose group conversions via meta-data API?
by Gunnar Morling
Hi all,
As the title says: should we provide a way to access configured group
conversions via the meta-data API?
I'm undecided, I don't really see where this would be useful, OTOH we've
exposed all BV-related configurations via the meta-data API so far, so I
guess we probably should for the sake of completeness.
Thoughts?
--Gunnar
13 years, 1 month
BVAL-327 Creation of an executable subpackage
by Emmanuel Bernard
With part of BVAL-327 now in the spec, I'm tempted to create a new
subpackage named 'executable'. It would contain the two new classes:
- @ValidateExecutable
- ExecutableType
I am also tempted to add ExecutableValidator to it but that's less
obvious.
Thoughts?
Emmanuel
13 years, 1 month
Group conversion on overridden method
by Gunnar Morling
Emmanuel, all,
I need a short confirmation related to the definition of group conversions
for the return value of an overriding method. IIUC, the following is legal:
Class Foo {
public Bar getBar() {}
}
Class SubFoo extends Foo {
@Valid
@ConvertGroup(from=..., to=...)
@Override
public Bar getBar() {}
}
That is, SubFoo can define a group conversion for the return value as
@Valid itself is added in SubFoo only. It would be illegal if @Valid was
given in Foo, too.
I think that makes sense since LSP is not violated by the first variant,
while it would in the second (a user of Foo wouldn't be aware of the
applying conversions).
Right?
Thanks,
--Gunnar
13 years, 1 month
Better name for @CrossParameterConstraint
by Gunnar Morling
Hi all,
While discussing some details around BVAL-340 (allowing constraints to be
generic and cross-parameter at the same time), Emmanuel and myself were
wondering whether @ParameterListConstraint might be a better name for
what's currently named @CrossParameterConstraint.
I like the alternative name because it makes very clear to what the
constraint applies, the list of parameters of a method or constructor.
Any thoughts?
--Gunnar
13 years, 1 month
Method interception configuration and interception technology
by Emmanuel Bernard
Hi Pete,
(I've added you as accepted sender to the mailing list so you can reply
to beanvalidation-dev wo being rejected).
We have a problem and we need your wisdom.
## Context
- Bean Validation offers method / constructor validation.
- the feature is defined at a generic level to be implemented on all
interception technologies
- we have a CDI specific section to make it clear how things work /
integrate with CDI
- we need to be able to enable / disable validation for constructors,
non-getter and getter method both per element and via a global default setting
## The problem
BV integrates with CDI via portable extensions (or some proprietary
means similar to this) that bind an interceptor to the constructors and
methods that require validation.
We offer @ValidateExecutable to customize whether or not a method /
constructor is validated. And we also would like to offer a global
setting.
We tried to make the validation configuration a core part of Bean
Validation so that the logic would be similar across all interception
technologies but we have hit a snag.
We wanted to make the global setting part of both:
- META-INF/validation.xml
- the BV bootstrap API (programmatic approach)
But it turns out that the portable extension is enabled at a different
tie than a ValidatorFactory. So using the programmatic API to change the
setting would not be reflected. Likewise, the portable extension would
need to read the validation.xml to find the setting.
that made some members of this group to push for having the method
interception setting in a CDI configuration rather than Bean Validation
one. Most likely beans.xml.
Is it a natural fit for CDI to augment beans.xml it with Portable Extension
specific options and what is the way of doing it?
We can try and keep things in validation.xml but that would be a
placeholder that would need to be read one way or another by the
interception technology.
What are your thoughts Pete?
Emmanuel
13 years, 1 month
BVAL-192 and BVAL-223
by Hardy Ferentschik
Hi all,
as you remember prior to the Holidays we have been discussing BVAL-192 [1] - the addition of an 'inclusive' flag to @DecimalMin/Max.
Adding the additional parameter was not a big issue, but rendering the right constraint error message was tricky, because the message varies depending
on the value of the flag.
One solution we discussed was to introduce Expression Language (JSR 341) into the message interpolation algorithm. In the case of
@DecimalMin/Max this would allow for something like this: "Must be greater than ${inclusive == true ? 'or equal to' : ''} {value}"
Using EL we can also bind the validated value itself into the EL context and allow message formatting along these lines: ${str:format("%1$5f", validatedValue}
Provided str:format is bound to the String.format method. This would address BVAL-223 [2]
I created a pull request for the BV spec [3] outlining the changes to the default message interpolation algorithm. It would be great to get some feedback
on this.
Here are some questions I am in particular wondering about:
* Is the benefit offered by this solution big enough to introduce a dependency to another API/JSR?
* I am proposing to bind the validated value to the string literal 'validatedValue'. Is this a good name? 'value' would be shorter, but would conflict with
the default annotation parameter name
* I am proposing to bind String#format to the literal 'str:format'. Does this prefix sound ok, or should it be 'string:format'.
* Is there a need to specify more functions which need to be available in the EL context (on top of String#format)?
* Using the ${expression} syntax causes a backward compatibility issue with BV 1.0 where '$' was used as literal, e.g. ${amount} would be $10 in BV 1.0
whereas now it would be just 10. Maybe '#' would be a better marker for EL expressions or to be 100% correct a configuration flag would be needed.
* Last but not least, how should be handle invalid EL expressions or expressions which reference non existent properties. For the user it might be best
to catch any EL based exception and just return the un interpolated expression (the actual impl could log a warning). If we propagate exceptions might have
to deal with exception based on poor message/expression design.
Looking forward to get some feedback,
Hardy
[1] https://hibernate.onjira.com/browse/BVAL-192
[2] https://hibernate.onjira.com/browse/BVAL-223
[3] https://github.com/beanvalidation/beanvalidation-spec/pull/41
13 years, 1 month
Distinguishing cross-parameter and generic constraints
by Gunnar Morling
Hi all,
As per the latest spec draft, a constraint must be either a cross-parameter
*or* a generic constraint, but not both at the same time, as otherwise it
would be ambiguous whether a constraint on a method refers to the method
parameters or return value.
Most of the time this does not really pose a limitation, but some
constraints actually might be both, cross-parameter *and* generic,
depending on the specific context. Examples are @ScriptAssert in Hibernate
Validator or generic constraints such as this:
@EqualPasswords
public void register(String userName, String password, String
confirmedPassword) {
}
@EqualPasswords
public class ResetPasswordRequest {
String userName;
String password;
String confirmedPassword;
}
Based on a recent BVAL issue [1], I'm proposing to introduce a special
constraint annotation attribute, "validationAppliesTo", allowing to specify
the required behavior at the usage site:
@EqualPasswords(validationAppliesTo=PARAMETERS)
public void register(String username, String password, String
confirmPassword) {
}
@EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
public class ResetPasswordRequest {
String password;
String confirmedPassword;
}
The following rules would apply:
* If a constraint is annotated with @Constraint and
@CrossParameterConstraint, it must define a member "validationAppliesTo".
The default value should be ANNOTATED_ELEMENT.
* If a constraint is annotated with only one
of @Constraint/@CrossParameterConstraint, defining a "validationAppliesTo"
member doesn't have any special effect
* Specifying validationAppliesTo=PARAMETERS anywhere except a method causes
ConstraintDeclarationException
Any thoughts?
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-340
13 years, 1 month
Legal to validate constraints more than once?
by Gunnar Morling
Hi all,
I'm wondering whether it's legal that one constraint gets validated more
than once during one validation operation. The spec seems a bit
contradictory in this regard.
In section 4.6 "Validation routine" [1] it says:
"[...] this implies that a given validation constraint will not be
processed more than once per validation."
Section 4.6.1 "Object graph validation" says though:
"[...] object graph navigation can lead to multiple validations of the same
constraint and the same object instance but the set of constraint
validation is deterministic and the algorithm prevents infinite loops."
What is right here? Or is this to say that *only* during graph validation a
constraint may be validated multiple times but not e.g. during validation
of multiple groups, all of which a constraint is part of?
Thanks,
--Gunnar
[1]
http://beanvalidation.org/latest-draft/spec/#constraintdeclarationvalidat...
[2]
http://beanvalidation.org/latest-draft/spec/#constraintdeclarationvalidat...
13 years, 1 month