Ahh, I see, it's a part of the spec. So basically if we wanted to do it the other way there's no other option then remove the @WithAnnotations, receive all PATs and do the filtering on our side, right?
And also thanks for a quick response! Have a nice day, Marko 2018-05-02 17:25 GMT+02:00 Martin Kouba <[email protected]>: > Hi Marko, > > comments inline... > > Dne 2.5.2018 v 16:57 Marko Bekhta napsal(a): > > Hi all, >> >> In Hibernate Validator CDI extension we are using @WithAnnotations to >> filter >> beans that potentially need to be validated (for actual usage see [1]): >> >> public <T> void processAnnotatedType(@Observes @WithAnnotations({ >> Constraint.class, >> Valid.class, >> ValidateOnExecution.class >> }) ProcessAnnotatedType<T> processAnnotatedTypeEvent) { >> // doing something ... >> } >> >> The problem that we've stumbled upon is that it looks like this filtering >> does >> not take into account the information from implemented interfaces. For >> example >> let's assume we have an interface: >> >> @ValidateOnExecution(type = ExecutableType.ALL) >> public interface ShipmentService { >> public void findShipment(@NotNull String id); >> } >> >> which is implemented by ShipmentServiceImpl: >> >> public class ShipmentServiceImpl implements ShipmentService { >> >> @Override >> public void findShipment(String id) { >> } >> } >> >> Our expectation would be that as interface is marked with one of the >> annotations >> listed among values of @WithAnnotations filter, the corresponding bean >> (ShipmentServiceImpl) would be pushed to processAnnotatedType(..) method. >> But it >> is not. As a result we don't create a validation proxy and corresponding >> service >> bean never performs any validation operations. In case when any of the >> filtered >> annotations is added to the impl bean things start to work (impl bean is >> processed). >> >> The above case shows placement of annotation on a type level, but similar >> behavior is observed in cases when annotation is on a method level. >> >> As forcing presence of one of the annotations from the filter list on a >> impl >> beans is not really an option, an alternative could be to drop the >> @WithAnnotations filtering completely. Which is also not that great, as >> dropping the filtering would mean that: >> >> - Validation extension would need to process all possible beans that are >> available >> - Such processing requires calls to Hibernate Validatior which must >> create the metadata >> for each bean hierarchy and store it, even if nobody actually needs to >> validate those >> beans. >> - This would lead to much greater memory consumption as well as longer >> bootstrap >> time. Which is not good. >> >> Hence we would like to ask if there is any particular reasons why >> @WithAnnotations >> > > Well, the reason is that the spec requires this: > > "If the annotation is applied, the container must only deliver > ProcessAnnotatedType events for types which contain at least one of the > annotations specified. The annotation can appear on the annotated type, or > on any member, or any parameter of any member of the annotated type, as > defined in Alternative metadata sources." > > See also http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_ > annotated_type > > Annotations should be inherited (and PAT fired) if @Inherited > meta-annotation is used. But I'm not quite sure this works. Also note that > annotations are never inherited from interfaces (see also > java.lang.annotation.Inherited javadoc)! > > filter does not consider looking at super classes and implemented >> interfaces to check >> for annotations listed in @WithAnnotations? >> > > >> Have a nice day, >> Marko >> >> [1] https://github.com/hibernate/hibernate-validator/blob/master >> /cdi/src/main/java/org/hibernate/validator/cdi/ValidationExt >> ension.java#L222 >> >> >> _______________________________________________ >> weld-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic >
_______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
