tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: Bean Validation 1.1 feasibility question
Date Fri, 23 Jun 2017 09:29:12 GMT
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 <> |  Blog
<> | Old Blog
<> | Github <> |
LinkedIn <> | JavaEE Factory

2017-06-23 9:25 GMT+02:00 COURTAULT Francois <

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message