Hi,
I agree with Hardy - this looks very interesting.
I think there is to some degree an overlap with method validation as
possibly part of BV 1.1. I don't know about the timeline for the
JAX-RS proposal, but it might make sense that they base their work on
BV 1.1.
Some minor remarks:
* In listing 2 setEmail() instead of a getter is annotated.
I'm not sure whether this is intentionally, otherwise it would make
sense to use getters as in BV.
* "All constraint annotations used in resource classes are validated
in the Default group".
Maybe this could be configured using an annotation on the resource or similar:
@Path("/")
@ValidationGroups(SomeGroup.class)
class MyResourceClass {
...
}
* "The order in which validations are checked is as follows:
constraint validations on fields and properties are checked first, on
resource classes are checked next"
I don't think we could currently ensure such an order in HV but I
guess it could be implemented. The question is whether this is really
required.
* "If the getUser() method in [the implementing class] MyResourceClass
is decorated with any annotation ... all of the annotations in the
[implemented] interface will be ignored.
I think this might require some more consideration. In HV we decided
against such an approach, as preconditions shouldn't be strengthened
in sub-types in order to obey to the Liskov substitution principle
[1].
Instead of the very conservative approach currently taken by HV (not
allowing parameter constraints for one method in several places in a
hierarchy) one could also OR-join the constraints from a method
hierarchy causing the "weakest" contract in the hierarchy becoming
effective. That's the way taken by most DbC frameworks.
* "... including javax.validation.ConstraintValidationException"
I think ConstraintViolationException is meant.
* I'm not completely sure about the client API part. Maybe clients
could just validate standard beans populated with values retrieved via
JAX-RS? Implementing annotation interfaces with classes seems somewhat
uncommon. As Hardy said it might make sense to follow the
ConstraintDef approach from HV. If the programmatic API is added to BV
1.1 the JAX-RS team might benefit from this of course.
I'm also CC'ing Jozef, lead of the Seam REST module which provides an
integration with Bean Validation [2].
--Gunnar
[1]
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
[2]
http://docs.jboss.org/seam/3/rest/latest/reference/en-US/html/rest.valida...
2011/6/30 Hardy Ferentschik <hardy(a)hibernate.org>:
Hi,
looks very promising to me. Up to "Validation in Client API (Brainstorming)"
everything seems
straight forward.
Obviously parameter validation is not officially part of the spec, but
luckily we already implement it ;-)
Regarding the client api, they seem to struggle with the same problem we had
when defining our
programmatic API. You cannot programmatically create/configure annotations.
We created the XYZDef classes to
solve this and also GenericConstraintDef. The latter could be another option
in their API design.
I don't really understand though what the "Client API" really does, but
maybe some
syncing/brainstorming in the programmatic API area could be useful for BV
and JAX-RS.
--Hardy
On Thu, 30 Jun 2011 17:34:20 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
>
http://java.net/projects/jax-rs-spec/pages/Validation
>
> Can you guys have a look at it a give me your feedback. The JAX-RS expert
> group has created this draft and looks for feedback.