[weld-dev] @WithAnnotations filtering not picking up annotations from implemented interfaces

Martin Kouba mkouba at redhat.com
Wed May 2 11:25:22 EDT 2018


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/ValidationExtension.java#L222
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic


More information about the weld-dev mailing list