Bean Validation 1.1 feasibility question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bean Validation 1.1 feasibility question

Franos13
Hello,

Let's say that I want to use the same POJO with 3 fields (field1, field2, field3) for 2 REST calls.
For the first REST call, I want to check that one of the 3 fields are not null and the 2 other ones are null.
For the second REST call, I want to check that at least one of the 3 fields is not null.
In order to achieve that, my understanding is that I have to use class level constraint, right ?

But, how to achieve that with Java Bean Validation 1.1 using only annotation ?
Thanks to some reading, I was thinking about using Java Bean Validation group feature but what I don't get is that I can't use something like @Valid(group="mygroup1") for the first REST call and @Valid(group="mygroup2") for the second REST call!
But programmatically, I can perform the following operations: validator.validate(myobject, "mygroup1")  and validator.validate(myobject, "mygroup2"), right ?

Could someone help me to solve this issue ?

Best Regards.
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bean Validation 1.1 feasibility question

Romain Manni-Bucau
Right, rest integration uses Default group only.

Here are the easy solutions:

1. Design the API with different model (command pattern like) - I would
recommand it personally since it would make your *API* explicit
2. Custom bean validation interceptor supporting a @Group annotation,
ensure to disable jaxrs implicit validation
3. Move the validation in the object itself (Validable interface?) and
handle the contextual validation from the object directly



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-23 9:25 GMT+02:00 COURTAULT Francois <[hidden email]
>:

> Hello,
>
> Let's say that I want to use the same POJO with 3 fields (field1, field2,
> field3) for 2 REST calls.
> For the first REST call, I want to check that one of the 3 fields are not
> null and the 2 other ones are null.
> For the second REST call, I want to check that at least one of the 3
> fields is not null.
> In order to achieve that, my understanding is that I have to use class
> level constraint, right ?
>
> But, how to achieve that with Java Bean Validation 1.1 using only
> annotation ?
> Thanks to some reading, I was thinking about using Java Bean Validation
> group feature but what I don't get is that I can't use something like
> @Valid(group="mygroup1") for the first REST call and
> @Valid(group="mygroup2") for the second REST call!
> But programmatically, I can perform the following operations:
> validator.validate(myobject, "mygroup1")  and validator.validate(myobject,
> "mygroup2"), right ?
>
> Could someone help me to solve this issue ?
>
> Best Regards.
> ________________________________
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>
Loading...