Santiago,
thank you for publishing this proposal. I tried to project its intention
onto some existing JAX-RS applications and I came to this conclusion: The
proposal would not work for all of them.
The reasons are:
* All inspected applications are using root resources as dispatchers to sub
resources only, so a validation that is not working inside of sub resources
is useless for non-trivial applications. My proposal to solve this is: It
must be mandatory that validation is executed in sub resources, too.
* It looks rather odd that the validation ruleset is glued to the code point
*when* it shall get executed. As the rule set is validating the consistency
of an entity, it should be glued to the entity class, not to some point in
time. My proposal to solve this is: It must be possible to annotate an
entity class with validation rules (just as a "NOT NULL" constraint can be
part of the "CREATE TABLE" command, but not only part of an AFTER INSERT
TRIGGER in SQL). But certainly it must be possible to still specify the
point in time *when* that ruleset shall get executed using an annotation at
the resource. So we need different annotations for "run validation here" (at
resource) and "use this ruleset when validation" (at entity class).
* On the client side we need to understand that using http is not the only
time when the entity can be validated. It can be validated at any time,
actually. For example, at each property change a swing GUI could pop up some
badges if a field must not be null. Or a JSF application could do that, too.
But the rule set is shared. So, again, the rule set must be specified at the
entity class, but the point in time must be specified separately. I do not
see that it makes pretty much sense in a GUI application to validate when
doing http (that would be much too late, and the GUI has validated already
anyways). But that makes much sense when the client is a server process. So
a GUI would use a separate API to validate the model bean and omit checks at
http time. But a server would need to run the checks at http time, so it
would use Client.create(URI).post(entity, validator); for example (which I
think is the most simple-to-read fluent API). I do not really see a need to
have an additional static registration of validators.
Regards
Markus
From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Freitag, 17. Juni 2011 18:17
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Validation Draft
Hello Experts,
The last topic that we planned to cover during 2.0-i01 is Validation. The
main objective for this part is to support JSR 303 annotations in resource
classes. As well as to support some form of validation in the client API.
A draft highlighting some initial thoughts is available for reviewing [1].
Incidentally, our goal would be to depend on the upcoming Bean Validation
1.1 spec that will also be part of EE 7.
-- Santiago
[1]
http://java.net/projects/jax-rs-spec/pages/Validation