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

Paul Benedict pbenedict at apache.org
Wed Jul 18 12:51:50 EDT 2012


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.

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.
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 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 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);
}

Thanks!
Paul


More information about the beanvalidation-dev mailing list