<p>Right, XML mappings can indeed be helpful here.</p>
<p>I've written a post on <a href="http://beanvalidation.org">beanvalidation.org</a> [1] asking for feedback from a broader audience. Maybe we gain some more insight through this.</p>
<p>--Gunnar</p>
<p>[1] <a href="http://beanvalidation.org/news/2012/08/29/methodvalidation-inheritance/">http://beanvalidation.org/news/2012/08/29/methodvalidation-inheritance/</a></p>
<div class="gmail_quote">Am 29.08.2012 16:42 schrieb "Hardy Ferentschik" <<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I voted for the true PbC approach. As I mentioned before I was undecided and can see the<br>
Paul's and Matt's point.<br>
<br>
There are two reasons I voted for PbC now. First I think this the most typical use case where<br>
BV method validation will be used and, as Gunnar pointed out, the majority of existing PbC solutions<br>
took the no strengthening of preconditions road. The alternative is to allow weakening of preconditions<br>
(via ORing the constrains), but this is something we have not even discussed further and would not<br>
solve Paul's use case.<br>
<br>
Which leads me to the second reason I voted for PbC. Emmanuel reminded me of a very important<br>
BV feature, the XML configuration. Using it you can specify the constraints easily on the OrderService<br>
directly (to use our example again). So for me this covers even this use case without even using a<br>
option/flag.<br>
<br>
--Hardy<br>
<br>
<br>
On 27 Jan 2012, at 4:12 PM, Emmanuel Bernard wrote:<br>
<br>
> Just to get a better understanding of the dynamic here.<br>
> Can you all vote on what you think is the best approach for Bean Validation 1.1<br>
> <a href="http://www.doodle.com/qp78u6mqzetuas7p" target="_blank">http://www.doodle.com/qp78u6mqzetuas7p</a><br>
><br>
> On 26 août 2012, at 09:42, Paul Benedict wrote:<br>
><br>
>> I was reading the Hibernate Validator documentation today. Here was<br>
>> something that speaks to Gunnar's intentions:<br>
>><br>
>> "When validating an object that implements an interface or extends<br>
>> another class, all constraint annotations on the implemented interface<br>
>> and parent class apply in the same manner as the constraints specified<br>
>> on the validated object itself."<br>
>><br>
>> I buy into this 99% except when the parent class has no annotated<br>
>> constraints. Why not just make an exception for this case? I think<br>
>> that is so incredibly more reasonable than adding a custom<br>
>> implementation flag. Since constraints are meant to be compounded, a<br>
>> child should be able to add new constraints even if the parent never<br>
>> did.<br>
>><br>
>> Paul<br>
>><br>
>> On Wed, Aug 22, 2012 at 3:26 PM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>> wrote:<br>
>>>> Gunnar, do you want to take the lead on 1. and 2.?<br>
>>><br>
>>> Sure, I can do that. I'll prepare a blog post.<br>
>>><br>
>>> Personally, I'm still reserved about adding such a feature. Maybe I<br>
>>> would change my mind if someone pointed out to an existing PbC<br>
>>> solution which provides such sort of feature/switch. What I've seen so<br>
>>> far is either prohibiting parameter constraints in sub-types (as we<br>
>>> currently do) or OR-ing all parameter constraint contracts in the<br>
>>> hierarchy (effectively applying the weakest one).<br>
>>><br>
>>> An implementation-specific configuration switch might be a good<br>
>>> compromise. The spec still may define the current behavior as default<br>
>>> and mention that implementations may add means of configuring this.<br>
>>><br>
>>> --Gunnar<br>
>>><br>
>>><br>
>>> 2012/8/22 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>>:<br>
>>>> Reopening the debate here.<br>
>>>><br>
>>>> Matt, java.util.Deque.push actually does describe the risk of NPE depending on the implementation.<br>
>>>><br>
>>>> Let's take the OrderService that has been designed pre-BV 1.1 and that expressed constraints per JavaDoc. There are two options today to make it work:<br>
>>>><br>
>>>> - update it to add Bean Validation 1.1 annotations in compliance with the JavaDoc<br>
>>>> - use BV's XML capability to add constraints on the interface without having to touch it<br>
>>>><br>
>>>> Note that adding constraints not described on the interface javadoc would be a change of contract.<br>
>>>><br>
>>>> But I do hear Paul's concern as well. With all the interfaces around, do we want to force people to host their constraints on them instead of on the implementation?<br>
>>>> How much of this is a usability constraint? On the other hand, today we enforce good practice. If we open up the Pandora box, there is no way to close it.<br>
>>>><br>
>>>> I'd go and do a few things:<br>
>>>><br>
>>>> 1. open up a JIRA with a summary of the problem<br>
>>>> 2. blog about it on <a href="http://beanvalidation.org" target="_blank">beanvalidation.org</a> and push people for feedback<br>
>>>> 3. get people to try a preview and give us feedback<br>
>>>><br>
>>>> Gunnar, do you want to take the lead on 1. and 2.?<br>
>>>><br>
>>>> If we are still on the fence, I'm tempted to let implementations provide an implementation specific configuration switch.<br>
>>>><br>
>>>> Sebastian, OVal has had such features for a while AFAIK, what is your take on the subject?<br>
>>>><br>
>>>> Emmanuel<br>
>>>><br>
>>>> On 23 juil. 2012, at 20:38, Paul Benedict wrote:<br>
>>>><br>
>>>>> I concur with Matt's point below. Because there hasn't been a<br>
>>>>> validation standard for most of Java's lifetime, most method<br>
>>>>> constraints are in javadoc contracts only. I think it's important for<br>
>>>>> the BV spec to recognize this fact -- not every precondition is<br>
>>>>> available for introspection at runtime. Thus, there is a long pedigree<br>
>>>>> here of people who could benefit from BV, if only by chucking their<br>
>>>>> custom validation code for BV.<br>
>>>>><br>
>>>>> The OrderService is a great example due to the total absence of BV<br>
>>>>> annotations. I don't think the spec should assume the lack of BV<br>
>>>>> annotations is an intentional use of BV (i.e., no constraints). I can<br>
>>>>> only see two ways out of this problem to address this fact. Either<br>
>>>>> annotate OrderService to signify its validation is undefined or<br>
>>>>> annotate OrderService to signify validation is intended. Thoughts?<br>
>>>>><br>
>>>>> Paul<br>
>>>>><br>
>>>>> On Mon, Jul 23, 2012 at 9:16 AM, Matt Benson <<a href="mailto:mbenson@apache.org" target="_blank">mbenson@apache.org</a>> wrote:<br>
>>>>>> Okay, point taken. Thanks for clarifying the distinction between<br>
>>>>>> pre/post-conditions corresponding to method parameters vs. return<br>
>>>>>> values here. Still, consider the JDK itself: the java.util.Deque<br>
>>>>>> interface imposes no requirements on the parameter to its #push()<br>
>>>>>> method, yet the java.util.ArrayDeque implementation forbids null<br>
>>>>>> elements and is declared as throwing an NPE if the parameter to<br>
>>>>>> #push() is null. I can fully understand your assertion that this<br>
>>>>>> violates DbC and even basic OO principles, but is it *necessary* that<br>
>>>>>> BV deny users the option to work with such a design? I'm not yet<br>
>>>>>> convinced of the harm it would cause, beyond implementation complexity<br>
>>>>>> (which IMO doesn't seem extensive), to permit a user to add decoupled<br>
>>>>>> validation constraints per Paul's example, or to customize a given<br>
>>>>>> implementation as in mine. Nothing here would prevent the purist user<br>
>>>>>> from operating per your recommendations.<br>
>>>>> _______________________________________________<br>
>>>>> beanvalidation-dev mailing list<br>
>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> beanvalidation-dev mailing list<br>
>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
>>> _______________________________________________<br>
>>> beanvalidation-dev mailing list<br>
>>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
>> _______________________________________________<br>
>> beanvalidation-dev mailing list<br>
>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div>