CHALLENGE:
One test case within the BeanValidation TCK suite:
Test: org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.ExecutableValidationTest
Method: testCascadedReturnValueValidationOfConstrainedMethod

The Weld CDI RI is forcing vendors who implement Bean Validation to write Weld specific code to ignore annotations on CDI generated proxy classes. Without this Weld specific code the Bean Validation implementor cannot successfully pass the Bean Validation TCK due to the following portion of the Bean Validation 1.1 specification being in violation.

Section 4.5.5:
• One must not mark a method return value for cascaded validation more than once in a line of a class hierarchy.
In other words, overriding methods on sub types (be it sub classes/interfaces or interface implementations) can-
not mark the return value for cascaded validation if the return value has already been marked on the overridden
method of the super type or interface.

We've been in contact with the WELD community, and here they are confirming the behavior of annotations being duplicated on proxies:
"You're right, methods of a subclass generated by Weld have the same annotations applied as the original class. This behavior is depended on by framework/extension authors therefore we cannot change that.

The BV spec / apache bean validation check seems too strict to me. The purpose of the constraint is to make sure that the postcondition constraints are not weaker in a subtype (e.g. a subtype could define @Valid with a strict subset of constraints in an overridden method). That sounds reasonable in general. In this particular case however, since Weld copies all the annotations, the constraint set is the same. The check could perhaps be altered to not fail if the constraint sets are equal.

Alternatively, the BV implementation would need to recognize that this is a Weld proxy and not fail on cascaded validation in such case.

Jozef "

The Bean Validation RI appears to have made this concession for Weld to "recognize that this is a Weld proxy and not fail on cascaded validation in such case", which does not promote portability and forces vendor specific coding for integration.

The test fails with:
<test-method status="FAIL" signature="testCascadedReturnValueValidationOfConstrainedMethod()[pri:0, instance:org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.ExecutableValidationTest@dc9ab1e3]" name="testCascadedReturnValueValidationOfConstrainedMethod" duration-ms="1331" started-at="2015-05-22T17:58:53Z" finished-at="2015-05-22T17:58:55Z">
<exception class="javax.validation.ConstraintDeclarationException">
<message>
<![CDATA[@Valid on returned value can't be set more than once]]>
</message>
<full-stacktrace>
<![CDATA[javax.validation.ConstraintDeclarationException: @Valid on returned value can't be set more than once

This failure is due to the CDI proxy duplicating the annotations defined on the class being proxied.

The Weld CDI RI should not be forcing Bean Validation implementors to write Weld specific code to ignore duplicate annotations generated on the Weld proxy classes. This is forcing ALL implementations of Bean Validation to ignore section 4.5.5 of the Bean Validation 1.1 specification when integrating with Weld CDI proxies in order to pass this test.

This test should be excluded or changed to define the @Valid annotation via validation.xml, until the CDI RI is updated to not require bean validation implementations to add Weld specific code to pass the TCK.