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

[Paul Benedict]

Gunnar, I address some of your points below...

On Thu, Jul 19, 2012 at 2:02 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Am 18.07.2012 18:51 schrieb "Paul Benedict" <pbenedict at apache.org>:
>> 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.
>

Sorry if my point was not clear enough. Let me try again. You
emphasized that you don't want a subclass to be more constrained than
its superclass. So if a superclass does not use BeanValidation,
neither can its subclass. What are the implications? One implication,
as I pointed out, is that is automatically declares all method
parameters as valid. Nothing is constrained and thus all method
parameters are licit.

>>
>> 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?
>

In my example, OrderService was not written with BV in mind. But, also
in my example, I am not in control of that interface -- it has been in
the public domain for several years. I am not able to claim it as my
own and begin modifying it. It's history written in stone. I imagine
99% of the Java world is using interfaces without BV 1.1 in mind.

For those maintaining custom validation code in implementations, I say
let them chuck it in favor of BV 1.1 functionality.

Thus I believe we have two use cases here.
1) Designer A makes interfaces with validation unspecified.
2) Designer B makes interfaces with validation specified.

I aptly addressed Designer A's concerns. For where Designer B wishes
no validation extensibility to be had, @ValidationConstraintsComplete
can be added.

Paul