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