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 <mkouba(a)redhat.com>:
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
> weld-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic