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

[Gunnar Morling]

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.

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120719/ca8da3b0/attachment.html