[bv-dev] Method Validation: Why Example 4.11 should be allowed

Thu Aug 30 02:44:57 EDT 2012

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 at hibernate.org>:

> 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 at hibernate.org>
> 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 at hibernate.org>:
> >>>> 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 at apache.org>
> 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 at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> beanvalidation-dev mailing list
> >>>> beanvalidation-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>> _______________________________________________
> >>> beanvalidation-dev mailing list
> >>> beanvalidation-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120830/72ff972b/attachment.html 