|
Description:
|
Weld creates proxy sub-classes for intercepted classes, re-declaring any annotations declared on the proxied super-class. For return values marked for cascaded validation this causes an exception because a return value must not be marked more than once as cascaded per hierarchy line:
{code}
javax.validation.ConstraintDeclarationException: HV000131: A method return value must not be marked for cascaded validation more than once in a class hierarchy, but the following two methods are marked as such: public org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarService$Proxy$_$$_WeldSubclass.createValidEvent(), public org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarService.createValidEvent().
at org.hibernate.validator.internal.metadata.aggregated.rule.ReturnValueMayOnlyBeMarkedOnceAsCascadedPerHierarchyLine.apply(ReturnValueMayOnlyBeMarkedOnceAsCascadedPerHierarchyLine.java:33)
at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:443)
at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:361)
{code}
For parameter constraints we circumvented the problem by checking whether any constraints on overriding methods resemble the constraints on the supertype method. For return values this can't be done in the same way, since there is an explicit TCK test expecting an exception when a return value is marked as cascaded several times. The only way I see around this is to try to detect proxy classes and ignore any cascaded markers on them
as discussed in HV-754
.
|
