<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Emily,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Alternatively, the BV implementation would need to recognize that
this is a Weld proxy and not fail on cascaded validation in such
case.<br>
<br>
Jozef<br>
<br>
<div class="moz-cite-prefix">On 05/27/2015 01:12 AM, Emily Jiang
wrote:<br>
</div>
<blockquote
cite="mid:CAECq3A_+hH5-OcBNFcXa5aZrz4ocf=rvDKSbmKJxHZqj4ARCSQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<table>
</table>
It seems Weld proxy has the same annotations as the proxied
class. However this conflicts with Bean validation spec as far
as @Valid is concerned.<br>
<br>
<br>
This section of the bean validation spec is ending up in
violation due to the duplicated annotation:<br>
• One must not mark a method return value for cascaded
validation more than once in a line of a class hierarchy.<br>
In other words, overriding methods on sub types (be it sub
classes/interfaces or interface implementations) cannot 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.<br>
<br>
"The @Valid annotation is used to declare that a cascaded
validation of the given method/constructor parameters or<br>
return values is performed by the Bean Validation provider. "<br>
<br>
<br>
Here is some debug added to the apache bean validation code
that shows which two classes have the @Valid on the
createValidEvent method:<br>
<br>
$$$$$$$$$$$$DEBUG clazz = class
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass
method = public
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass.createValidEvent()<br>
$$$$$$$$$$$$DEBUG clazz = class
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue
method = public
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event
org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue.createValidEvent()<br>
$$$$$$$$$$$$$$$$$DEBUG returnValid = 2 // number of hits
having @Valid
<br clear="all">
<br>
</div>
If I understand correctly, I think this annotation needs to be
treated differently.<br>
<div>
<div>
<div>-- <br>
<div class="gmail_signature">Thanks<br>
Emily<br>
=================<br>
Emily Jiang<br>
<a moz-do-not-send="true"
href="mailto:ejiang@apache.org" target="_blank">ejiang@apache.org</a><br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
weld-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a></pre>
</blockquote>
<br>
</body>
</html>