5

I read many tutorials about JSR 303 spec, but I don't see any example ready for production. Everywhere described how to get Set<Constraintviolation<T>> object.

Example:

ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();
Set<ConstraintViolation<Car>> violations = validator.validate(car);

But what next? I want to inform method caller (client) that method parameter is in inconsistent state.

What I must do with Set<ConstraintViolation<Car>>? I need manually iterate over Set<ConstraintViolation>, collecting all error messages into one string, and then throw an exception with this messages?

Or exist some more convenient ways out of the box?

Or it's better to provide validate method inside each bean?

divanov
  • 6,173
  • 3
  • 32
  • 51
WelcomeTo
  • 19,843
  • 53
  • 170
  • 286

2 Answers2

2

I would go with your first suggestion - iterate over the constraint violations. You don't necessarily create an error message that contains all that stuff. It is probably a good idea to just have an error message saying bean <bean> is not valid and set the constraint violations as a property on an exception.

Maybe you need to convert the constraint violations to another object, because otherwise you would make much of your application dependent on the bean validation api. That might be a too strong coupling.

Your problem is that it is very use case specific what to do with the constraint violations. There are many cases where you don't want to inform the caller about the constraint violations, but some other object. For example in a web form you want to inform your view model that it should also display these constraint violations. Throwing an exception is just another thing. Note that this won't be a ConstraintViolationException in most cases, but a application specific exception.

SpaceTrucker
  • 13,377
  • 6
  • 60
  • 99
  • `Note that this won't be a ConstraintViolationException in most cases, but a application specific exception` - ok, but this app specific exception will be likely special exception like `BeanValidationException`, not application wide exception like `ServiceException`? I.e. it better to create _another_ custom exception (like `BeanValidationException`) instead of reusing existing application specific exception? Thanks – WelcomeTo Feb 06 '13 at 12:07
  • @MyTitle Yes, in my opinion it is better to create an exception that is independent of bean validation api. – SpaceTrucker Feb 06 '13 at 12:24
  • ok, thanks. But what you think about throwing such exception from service-layer? It's good or bad to allow my EJB methods to have signature like `throws BeanValidationException`. Or it's better to wrap it into service-layer specific exception (but if I warp them, then I can't implement thing you mentioned: `and set the constraint violations as a property on an exception`, because my service-layer exception doesn't have such property)? – WelcomeTo Feb 06 '13 at 13:47
  • @MyTitle That is going towards a discussion. Try to search for an answer. If you find nothing, you could ask a more specific question. Maybe this question will help you: http://stackoverflow.com/questions/14722579/three-tier-architecture-and-exceptions – SpaceTrucker Feb 06 '13 at 13:52
  • @MyTitle Just saw that it was you asking that question. So you should stick to the accepted answer there. – SpaceTrucker Feb 06 '13 at 13:54
1

It also depends on how you use Bean Validation. The use case you are describing is when you use the Bean Validation API directly yourself. In this case you will get a Set> as the result of the validate call. How you deal with it is up to you. However, a lot of technologies integrate Bean Validation and often hide all direct calls to the Bean Validation API. For example JPA. If you use JPA and Bean Validation is on the classpath, entities will be automatically validated on life cycle events (pre-persist/update/delete) and a javax.validation.ConstraintViolationException will be thrown in case of validation errors. Similar in JSF, there the validation of form element with Bean Validation happens automatically and the error can also be highlighted. So unless you want to use the plain Bean Validation API you will need to look for examples on how the technology of your choice integrates with JSR 303.

Hardy
  • 18,659
  • 3
  • 49
  • 65