Re: [bv-dev] When is a method validated
by Gunnar Morling
Hi,
I agree with respect to parameter validation.
But shouldn't the validation interceptor also run last for return value
validation, that is after all interceptors potentially modifying the return
value? That way both contracts (pre- and postconditions) are enforced as
closest to their clients (method implementation respectively method caller)
as possible. Other interceptors generally couldn't rely on the correctness
of parameters/return values.
The order would then look like that:
...
validate parameters
method call
...
validate return value
--Gunnar
Am 26.02.2012 19:28 schrieb "Emmanuel Bernard" <emmanuel(a)hibernate.org>:
12 years, 10 months
Method validation: cross-parameter constraints
by Gunnar Morling
Hi all,
one of the larger open points related to method validation is how to
support cross-parameter constraints.
The BVAL-241 proposal discusses pro's and con's of several variants
[1]. The different options are:
#1 - Don't support cross-parameter constraints in BV 1.1
#2 - New interface MethodConstraintValidator
public interface MethodConstraintValidator<A extends Annotation> {
void initialize(A constraintAnnotation);
boolean isValid(Object[] parameterValues,
ConstraintValidatorContext context);
}
#3 - Invoke validator methods by signature matching
public class DateParameterCheckValidator implements
Initializable<DateParameterCheck> {
//defined in Initializable
public void initialize(DateParameterCheck constraint) {}
//invoked by convention for methods annotated with
@DataParameterCheck and the argument types Customer, Date, Date
public boolean isValid(Customer customer, Date from, Date to,
ConstraintValidatorContext context) { ... }
//invoked by convention for methods annotated with
@DataParameterCheck and the argument types Customer, Date, Date, Date
public boolean isValid(Customer customer, Date from, Date to, Date
alternativeTo, ConstraintValidatorContext context) { ... }
}
#4 - Script based approach
public class ReservationService {
@ParameterAssert(script="arg1.before(arg2)", lang="javascript")
void bookHotel(@NotNull Customer customer, @NotNull Date from,
@NotNull Date to) { ... }
}
#5 Parametrized interfaces MethodConstraintValidatorN for N method parameters
public interface MethodConstraintValidator3<A extends Annotation, T1, T2, T3> {
void initialize(A constraintAnnotation);
boolean isValid(T1 parameter1, T2 parameter2, T3 parameter3,
ConstraintValidatorContext context);
}
public class DateParameterCheckValidator implements
MethodConstraintValidator3<DateParameterCheck, Customer, Date, Date> {
public void initialize(DateParameterCheck constraint) {}
public boolean isValid(Customer customer, Date from, Date to,
ConstraintValidatorContext context) { ... }
}
Please refer to the proposal document [1] for the individual pro's and
con's. Emmanuel, Hardy and I also discussed this on GitHub [2]:
* our preference is generally for something around #2 and #3
* we might offer a mixed approach, both supporting #2 *and* #3
While #2 would define a more strict MethodConstraintValidator contract
it would require implementors to do some ugly casts. #3 has a less
strict MethodConstraintValidator contract (it works by convention) but
would provide implementors a more typed experience.
Personally I think both approaches actually aren't that much
different. Both are inherently type-unsafe, but #3 would move the
efforts for dealing with that away from the constraint implementor
towards the BV provider. Note that #3 could also be checked by an
annotation processor, while #2 couldn't.
Note also that all approaches are somewhat inconsistent compared to
"normal" parameter and return value constraints, as they are based on
a method-level annotation (opposed to parameter-level). But I don't
see really a way around that.
What do you other folks think about that? Which approach would you
prefer, and why? Do you have another idea altogether?
@Emmanuel: For the first BV 1.1 draft I suggest to leave out
cross-parameter constraints. This shouldn't change the general scheme
of method validation, so we could add that in a later draft revision.
--Gunnar
[1] http://beanvalidation.org/proposals/BVAL-241/#cross_parameter
[2] https://github.com/beanvalidation/beanvalidation.org/commit/bc37cfec514b7...
12 years, 10 months
Re: [bv-dev] When is a method validated
by Edward Burns
>>>>> On Mon, 27 Feb 2012 09:52:45 +0100, Hardy Ferentschik <hardy(a)hibernate.org> said:
HF> Hi,
HF> I think there are really two view points in this case.
HF> 1. method centric (Emmanuel's suggestion)
HF> 2. client centric (Gunnar's suggestion)
HF> For that reason and the fact that #1 is symmetric I vote for #1
>From a pragmatic perspective, whatever you do, pick one and discard the
other. Don't try to make it configurable.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
12 years, 10 months
Method validation: Validation of getter constraints
by Gunnar Morling
Hi all,
Another question with respect to method validation:
Constraints at JavaBean getter methods can be interpreted as
property-level bean constraint but also as method-level return value
constraint. So they would be validated when calling
Validator#validate() for the bean, but also when performing
method-level validation when the getter is invoked by some code and
the bean is enabled for method validation.
My question is whether we need a way to further control the behavior
here. In HV 4.2 getter constraints are considered in both cases, I
think in OVal there is some way to specify the intended behavior.
Possible options could be:
#1 Handle getter constraints as property as well as return value
constraints, don't provide means of configuration
#2 Have an attribute in @MethodValidated (a.k.a. @ValidateGroups),
e.g. use validationMode
#3 Provide a dedicated annotation, e.g. @IgnoreForMethodValidation
(handling getter constraints as property-level constraints needs to be
the default to be compatible with current behavior)
#4 Have a global option in bootstrap API, ValidatorFactory or Validator
Personally I tend to think that #1 is enough, I don't really see the
need for further configuration. Plus, validation groups could also be
used. Any thoughts?
--Gunnar
12 years, 10 months
When is a method validated
by Emmanuel Bernard
Hi all,
I have been discussing how to integrate our method validation feature with CDI and the Java EE spec in general. One question that got raised was when should methods be validated within the stack of interceptors. Here are a few common interceptors:
- transaction interceptor
- security interceptor
My answer is so far to be "last", though I can imagine many interceptors wanting to be last. An interceptor is able to change parameter values as well as return value potentially. Our intuition is that method parameter validation should:
- be done after a transaction has been started (esp if rich constraint validators are used)
- after the security layer has cleared the method call
- generally speaking after any interceptor that could interrupt the method call (to be cheap)
- after any interceptor that could alter parameter values
The idea is that the method validation interceptor guarantees that parameters provided to the actual method are sound.
With the same logic, return values should be validated before other interceptors. That makes the method validation interceptor logic be something like that
````
validateParameterValues
run method
validateReturnValue
````
Do you think this approach is sound, in particular wrt when method validation should occur in an interceptor stack?
Emmanuel
12 years, 10 months
Package javax.validation.spi
by Gunnar Morling
Hi all,
I'm in the process of integrating the method validation proposal into
to the first draft of the spec. document. Thanks again for all
comments and feedback.
While going over the ParameterNameProvider interface I wondered where
this interface should actually live. Should it be
javax.validation.ParameterNameProvider or
javax.validation.spi.ParameterNameProvider? Or put more generally,
what's the intention of the spi package in the BV API?
ParameterNameProvider is intended to be implemented by BV providers,
integrators and clients. According to my understanding of the SPI idea
(separate parts intended to be *implemented* by clients [SPI] from
parts intended to be *used* by clients [API]) therefore I'd say it's a
candidate for the SPI package. But following that reasoning, for
instance also the ConstraintValidator interface should be part of the
spi package, which it isn't in BV 1.0.
Based on the contained classes I'm supposing that the BV spi package
has a much more focused scope (bootstrapping). Then
ParameterNameProvider should go into javax.validation. Any thoughts?
Btw. there isn't much package-level JavaDoc for the BV API in general
(only for javax.validation.groups). I think we should add some more
for BV 1.1. WDYT?
--Gunnar
12 years, 10 months
Re: [bv-dev] Reminder: Proposal for method validation on beanvalidation.org
by Gunnar Morling
Hi,
I think we could approach this in the same way as triggering actual method
validation, that is provide an annotation in BV and let integrators deal
with handling it.
Another idea might be to add two attributes such as preValidateInvariants
and postInvalidateInvariants to the @MethodValidated annotation (final name
pending).
All in all this feature is not a MUST for 1.1 from my perspective, we might
also wait and see with what approaches BV implementors come up and spec
that later on.
WDYT?
--Gunnar
Am 15.02.2012 22:36 schrieb "Sebastian Thomschke" <
sebastian.thomschke(a)web.de>:
12 years, 10 months
Reminder: Proposal for method validation on beanvalidation.org
by Gunnar Morling
Hi all,
many thanks to those who already provided me with feedback on the
method validation proposal.
Everyone else I'd like to invite to have a closer look at the proposal
and share your thoughts. As I mentioned, there are several sections
needing further consideration or a decision to be made; I'll start
dedicated threads regarding these items on the mailing list within the
next days.
Thanks again for your efforts,
--Gunnar
2012/1/29 Gunnar Morling <gunnar.morling(a)googlemail.com>:
> Hi all,
>
> I've pushed now a first version of the proposal for method validation
> (BV-241) to beanvalidation.org [1].
>
> The proposal is still missing some parts (e.g. the XML configuration),
> but I hope it touches all major issues related to method validation.
> Throughout the document I've used the "DISCUSSION" marker for sections
> which still need further consideration or a decision between several
> possible options.
>
> I'd be very happy on any feedback related to these issues in
> particular but of course also to the complete proposal in general.
> Don't hesitate to speak up in case you think anything is incomplete,
> is missing or something doesn't make sense to you; after all this is
> very much work in progress. Feel free to add remarks in place within
> the document or start a dedicated discussion on the mailing list.
>
> --Gunnar
>
> [1] http://beanvalidation.org/proposals/BVAL-241/
12 years, 10 months
BVAL-265 exposing data in validation.xml
by Emmanuel Bernard
Hi,
I'd love your quick feedback on http://beanvalidation.org/proposals/BVAL-265/ which is in the way of solving the dependency injection proposal.
I am copying the content here for convenience.
---
# Expose settings defined in XML in the Configuration API (for ConstraintValidatorFactory, MessageInterpolator etc)
[Link to JIRA](https://hibernate.onjira.com/browse/BVAL-265)
## Goals
While working on the dependency injection (BVAL-238), I need to solve a subproblem. A container needs to know what is in `validation.xml`
to either:
- plug its `ConstraintValidatorFactory` / `MessageResolver` etc implementation,
- use the one defined by the user and possibly instantiate these objects as managed objects
There are a few strategies
## Option 1: Let the XML parsing be done by the DI bootstrap code
The easiest solution is to leave the container read `validation.xml` and extract information itself. No need to change the API in this case.
## Option 2: Expose the data on the `Configuration` object as strings
Add three methods to `Configuration` to return the explicit value (if set) and null otherwise:
- `String getConstraintValidatorFactoryFromXML()`
- `String getMessageInterpolatorFromXML()`
- `String getTraversableResolverFromXML()`
//example of bootstrap code by the container
Configuration conf = Validation
.byDefaultProvider()
.configure();
String cVFClassName = conf.getConstraintValidatorFactoryFromXML();
ConstraintValidatorFactory cVF;
if (cVFClassName == null) {
//use DI custom one
cVF = new ContainerCustomConstraintValidatorFactory();
}
else {
cVF = Container.getManagedBean(cVFClassName);
}
//same logic for MessageResolver and TraversableResolver
[...]
conf.constraintValidatorFactory(cVF)
.messageResolver(messageRes)
.traversableResolver(traversRes)
.buildValidatorFactory();
The spec would recommend that `getConstraintValidatorFactoryFromXML()` and its siblings lazily read the XML file.
## Option 3: Expose the data in `Configuration` as instantiated objects
Same as above except that `Configuration` returns already instantiated objects. But I don't think that's an
interesting option.
## Discussion
Which options should be favor? I am tempted by option 2 but the risk is an explosion of `getDefaultXXX()`
and `getXXXFromXML()` the more we add components to Bean Validation.
What do you think?
12 years, 10 months
