Some thoughts about step 6.
I have been experimenting with constraints on methods that indicates if the
method is allowed to be invoked or not, for example for security reasons
(requiring privileges) but also for business reasons such as if the user
has bought a product or not. I find it very useful to both verify that the
method cannot be invoked AND to generate links using reflection. We talked
about this in our JavaOne presentation..
https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=3383
The example we used was for a book shop for e-books and would look
something like this:
@Path("/book/{isbn}")
public class BookResource {
@GET
@Produces("application/epub+zip")
@HasBoughtBook(true)
@Path("epub")
public InputStream epub() {
...
}
@GET
@Produces("application/json")
public BookDTO get() {
// generate links to "epub" using refection if the contraint is ok
...
}
}
So if bean validation would validate return values there would be no
possibility to validate if the method call is allowed? Or will it be
possible to use different types of constraints? (method + return value)
/Jan
2012/10/18 Bill Burke <bburke_at_redhat.com>
> I just conversed with the Bean Validation spec lead (Emmanuel) and he is
> quite upset that JAX-Rs no longer has bean validation integration. While I
> was a bit happy it was removed initially, because I don't want special
> classes for it, he convinced me otherwise.
>
> First and foremost, IMO, it should only be required in a Java EE
> environment and integration should be specified in the Java EE chapters of
> the 2.0 spec. Emmanuel defined this particular integration:
>
> 1. The resource fields and setters are injected
> 2. fields and setters are validated and a HTTP 400 is returned on
> failure to inject @Param injections. 500 for @Context
> 3. method parameters are resolved
> 4. method parameters are validated and a HTTP 400 is returned on failure
> to inject @Param, 500 for @Context
> 5. method is executed
> 6. method return value is validated and a HTTP 500 is returned on
> failure
>
> The above does not require any special classes or binary dependencies on
> the validation spec. This sounds *very* reasonable to me. We require this
> in a Java EE environment only, IMO.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>