Am 18.07.2012 18:51 schrieb "Paul Benedict" <pbenedict(a)apache.org&gt;: > > Gunnar, thank you for writing back! > > On Tue, Jul 17, 2012 at 4:12 PM, Gunnar Morling wrote: > > Hi Paul, > > > > thanks for your feedback, that's much appreciated. > > > > The reason for the restriction basically is that a client of an API > > doesn't necessarily know its implementation. Let's for instance assume > > a client receives an implementation of the OrderService interface via > > dependency injection: > > > > public class Shop { > > > > @Inject > > private OrderService orderService; > > > > ... > > } > > > > Here, the programmer of the Shop class doesn't know which > > implementation will be injected, maybe it's SimpleOrderService, maybe > > it's an implementation type not even known to the Shop programmer at > > all. If it would be legal to add parameter constraints to the > > OrderService implementation, there is no way to find out for the > > caller what parameter values for placeOrder() are valid. > > I see your viewpoint. However, I am not sure BeanValidation needs to > be this smart. This is not specific to BV. OO design in general has the notion that any sub-type can be used where its super-types can be used. This principle is violated if parameter constraints could be added to sub-types, putting more constraints in place to be obeyed by the caller.

> > Let's make up an example. > 1. OrderService is a popular interface in the public domain for several > years. > 2. OrderService was created years before BeanValidation exists. I don't see a difference depending on when an interface was written. Imagine it would be allowed to add parameter constraints in implementations of java.util.List. Such an implementation would potentially break all code written against the List interface which is not aware of the additional constraints. > 3. OrderService constraints are documented in the javadoc. A custom > Exception type is thrown. > 4. A new vendor wishes to implement SimpleOrderService using Bean > Validation. Their plan is to capture ConstraintViolationException and > marshall it to the custom Exception type. The idea behind BV method validation is that some integration layer (e.g. CDI, AOP,based etc.) performs the constraint validation. So any ConstraintViolationException would not be reachable from within SimpleOrderService, as the call flow wouldn't get there. > > The new vendor will not be able make such a design under the current > spec. This is where the rub lies: assuming the lack of BeanValidation > means the validation constraints are specified. Is this sensible? > Actually, in this case, no constraints assumes all data is > automatically valid. I'm not sure whether I can follow. > > I believe it should be the opposite -- constraints are undefined. > Because a plethora of popular interfaces exist without BeanValidation, > the spec should give leniency to the situation. > > Would you consider a new annotation that prevents the strengthening or > loosening of validation? Perhaps you need something like this: > > @ValidationConstraintsComplete > public interface OrderService { > void placeOrder(String customerCode, Item item, int quantity); > } At the moment I don't see that this would help. If OrderService was written without BV in mind, the annotation can't be added there. If it was written with BV in mind, why not placing any parameter constraints on the interface? > Thanks! > Paul --Gunnar > _______________________________________________ > 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

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.

Gunnar, do you want to take the lead on 1. and 2.?

Gunnar, do you want to take the lead on 1. and 2.?

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

Thanks Emmanuel. I am sure the poll will bring interesting results. In the mean time, I am looking for some background information here. I would like to understand this reasoning a bit better. As I said, I was reading the Hibernate Validator guide and read (not news to me) that annotations on beans can be compounded: "Constraint annotations are aggregated if methods are overridden." Yet one of the arguments made to me (against allowing constraint redefinition on methods) is that the caller doesn't know if redefinition occurred. However, I see that's exactly the case today regarding constraint inheritance on beans -- subclasses can add more constraints by overriding superclass methods. So a client might be using a subclass, unbeknownst to the client, that has more constraints than what superclass/interface he compiled against. My question is really why treat validation different between beans and method parameters? Why allow the former but disallow the latter? The way we treat beans today is what I would expect even for method validation (hence my emails). I honestly see no difference so I find the difference in validating behavior puzzling. My question isn't rhetorical so any answer is appreciated to help better understand the opposing perspective. Thank you. Paul On Mon, Aug 27, 2012 at 9:12 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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 > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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