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.
>
> * 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?
> 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.
> 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