Santiago,
see inlined.
Regards
Markus
From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Freitag, 17. Juni 2011 21:45
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Validation Draft
Markus,
Thanks, this is the type of feedback that I was expecting. See inline.
* 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.
Sub-resources returned by sub-resource locators? Yes, I agree this needs
more exploration. I believe in 1.0 objects returned by sub-resource locators
are not modified by the implementation runtime (so field and property
binding isn't guaranteed) since they aren't managed objects. There's also
the issue of annotated constructor params in those objects since they are
created by the app and not the implementation.
Yes, what I talked about are sub-resources returned by sub-resources
locators (so they are "seen" by the JAX-RS engine and such can be handled).
* 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.
If the goal is to annotate entity classes (beans), then you should be able
to use the Bean Validation API on its own and run the validators at any
point in time (albeit, manually and perhaps using different validation
groups), at least in an EE environment. Right?
Yes, correct.
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).
See above.
* 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 agree, in principle. But, this is a more general problem that seems out
of scope for JAX-RS. To me that is the point of having a separate Bean
Validation API --although, I'm not sure if there's support for SE. So I
think our focus should be on the integration points, rather than trying
solve the same problem again.
Yes, it is out of scope of JAX-RS but we have to keep in mind the big
picture to understand what we must do in JAX-RS and what we do not need to
do. What we do not need in JAX-RS is client side validation on GUI type
clients, as those actually will use the Bean Validation API, so our efforts
of client side validation can concentrate on server use of the client API.
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).
Right, I also agree with this being the easier to read approach.
I do not really see a need to have an additional static registration of
validators.
Make sense.
Thanks.
-- Santiago
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