Denis,
Could you try and change your bean Bar into this:
@Named
@ValidateOnExecution(type=ExecutableType.IMPLICIT)
public class Bar implements Foo {
@Override
public void doStuff(String v) {}
}
This should cause the interceptor to be registered for Bar, the reason
being that the portable extension is invoked only for those types annotated
or meta-annotated with one of @Valid, @Constraint or @ValidateOnExecution.
As your actual bean class has none of these annotations, the interceptor
isn't registered. The spec foresees ExecutableType.IMPLICIT for this case,
which itself doesn't change semantics, it is only used as marker (see [1]
for the details).
2013/7/8 Denis Silva <denis.analistajava(a)gmail.com>
One more information,
This is the source code of the annotation that enabled the interception,
It is not missing @Inherited?
No, I don't think so.
@Inherited causes only superclass annotations to be inherited. Annotations
on other elements (interfaces, methods etc.) can not be inherited that way.
We add @MethodValidated directly to each executable to be validated in the
portable extension, its presence on super-types is never taken into account.
@Target({ ElementType.METHOD, ElementType.TYPE, ElementType.CONSTRUCTOR })
@Retention(RetentionPolicy.RUNTIME)
@InterceptorBinding
public @interface MethodValidated {
}
--Gunnar
[1]
http://beanvalidation.org/1.1/spec/#integration-general-executable
2013/7/8 Denis Silva <denis.analistajava(a)gmail.com>
> Gunnar,
>
> I'm using glassfish 4.0, that uses hibernate validator 5.0.0.Final.
>
> Debugging ValidationExtension for a while, i found one problem (may be
> not).
> When i use validations constraints in the abstract class, the
> ValidationEnabledAnnotatedType that enable the interception of the bean, is
> applied on the subclass implementation and the abstract class, but when
> i use an interface, the wrappedType is applied just in the interface.
>
> That way, the interface implementation will never be intercepted, right?
>
> I will create an entry on forum, but there is no stacktrace in my case,
> the expected validation just not work.
>
> Att,
>
>
>
>
>
>
>
>
> 2013/7/6 Gunnar Morling <gunnar(a)hibernate.org>
>
>> Hi,
>>
>> I don't think that's a spec problem.
>>
>> The @NotNull constraint should be validated, no matter wether Foo is an
>> interface or an abstract class. Generally constraints on
>> overridden/implemented methods are to be considered, you only may not add
>> any more parameter constraints in subclasses/implementations.
>>
>> Are you using the Hibernate Validator CDI portable extension? Which
>> container do you use? Could you create an entry with the complete stack
>> trace and a detailed description of your environment to
>>
https://forum.hibernate.org/viewforum.php?f=9?
>>
>> --Gunnar
>>
>>
>>
>> 2013/7/6 Denis Silva <denis.analistajava(a)gmail.com>
>>
>>> Hi,
>>>
>>> I'm doing some tests with bean validation, and i have some doubts about
>>> the behavior of method constraints on inheritance hierarchies.
>>> The specification tells about Liskov substitution, on method
>>> constraints within inheritance hierarchies, but i made the test bellow with
>>> the reference implementation ( hiberante validator 5.1 ), and not
>>> understand if this is a bug in implementation or my misunderstanding the
>>> specification.
>>>
>>> public interface Foo {
>>> public void doStuff(@NotNull String v);
>>> }
>>>
>>> @Named
>>> public class Bar implements Foo {
>>> public void doStuff(String v) {}
>>> }
>>>
>>> Calling bar.doStuff(null), the validation is not fired.
>>> But if i changed Foo interface to an abstract class, and made Bar
>>> extends it, the validation is fired and a ConstraintViolationException is
>>> propagated.
>>> The test was done with cdi.
>>>
>>> What should be the appropriate behavior?
>>>
>>> --
>>> Denis Tiago
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
>
> --
> Denis Silva
> Analista Programador Java
> 11 - 8334-9915
>
--
Denis Silva
Analista Programador Java
11 - 8334-9915
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev