[
https://issues.apache.org/jira/browse/BVAL-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925375#comment-16925375
]
David Blevins commented on BVAL-174:
------------------------------------
My typical approach on these kinds of things is to implement a prototype, show
it to as many people as I can, get people to see the appeal and get everyone
thinking about what missing pieces might have to be created if we were to do it
cleanly in a spec.
There's always a ton of people along the way who can't be convinced. That's
ok. It doesn't make them bad or the idea bad, just means we have different
brains – which is a good thing or there'd be no innovation.
In this situation, the desire to replace @RolesAllowed with the expressive
power of Bean Validation is a quite strong itch I have. I'm certain with
enough work there's a clean way to do it. To me @RolesAllowed looks like an
ugly Bean Validation before we knew what we were doing. Just like EJB is kind
of an ugly CDI before we knew what we were doing.
> Return Parameter Validation Ignore void methods
> -----------------------------------------------
>
> Key: BVAL-174
> URL: https://issues.apache.org/jira/browse/BVAL-174
> Project: BVal
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Reporter: David Blevins
> Priority: Major
> Fix For: 2.0.3
>
> Attachments: BVAL-174.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Given the following annotation:
> {code:java}
> import javax.validation.ConstraintValidator;
> import javax.validation.ConstraintValidatorContext;
> import javax.validation.Payload;
> import java.lang.annotation.Documented;
> import java.lang.annotation.Retention;
> import java.lang.annotation.Target;
> import java.util.Set;
> import static java.lang.annotation.ElementType.ANNOTATION_TYPE;
> import static java.lang.annotation.ElementType.METHOD;
> import static java.lang.annotation.RetentionPolicy.RUNTIME;
> @Documented
> @javax.validation.Constraint(validatedBy = {Audience.Constraint.class})
> @Target({METHOD, ANNOTATION_TYPE})
> @Retention(RUNTIME)
> public @interface Audience {
> String value();
> Class<?>[] groups() default {};
> String message() default "The 'aud' claim must contain '{value}'";
> Class<? extends Payload>[] payload() default {};
> class Constraint implements ConstraintValidator<Audience, JsonWebToken> {
> private Audience audience;
> @Override
> public void initialize(final Audience constraint) {
> this.audience = constraint;
> }
> @Override
> public boolean isValid(final JsonWebToken value, final
> ConstraintValidatorContext context) {
> final Set<String> audience = value.getAudience();
> return audience != null &&
> audience.contains(this.audience.value());
> }
> }
> }
> {code}
> BVal wil successfully avoid throwing errors when placed on a method like the
> following:
> {code:java}
> @GET
> @Path("foo")
> @Audience("movies")
> @RolesAllowed({"manager", "user"})
> public Movie getMovie() {
> return new Movie(1, "The Matrix", "Lana Wachowski");
> }
> {code}
> However on a method that returns void an exception will be throwing stating
> BVal cannot find a ConstraintValidator for return type void.
> {code:java}
> @POST
> @Audience("movies")
> @RolesAllowed("manager")
> public void addMovie(Movie newMovie) {
> store.put(newMovie.getId(), newMovie);
> }
> {code}
> If the BValInterceptor is updated to ignore checking return values of void
> methods, it appears to pass the Bean Validation TCK and solves the issue.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
