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

[Matt Benson]

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>:
>
>
>>
>> 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.
>

Gunnar, this argument makes perfect sense.  Yet, consider the fact
that the v1.0 BV validation routine evaluates "all getter level
validations (including the ones expressed on interfaces and
superclasses)".  This seems to establish a bit of a precedent IMO.  In
any event, it seems the requested functionality could be provided as a
parameter-driven, implementation-specific option.

Matt

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