> On Jan 13, 2017, at 6:51 AM, Gunnar Morling <gunnar_at_hibernate.org> wrote:
>
> Hi,
>
> I've filed https://java.net/jira/browse/JAX_RS_SPEC-539 and
> https://java.net/jira/browse/JAX_RS_SPEC-540 for my proposals. Btw. in
> the issue tracker Marek is still mentioned as the lead.
Thanks.
>
>> It would also be nice to support injection of validation errors for further processing
>> by the JAX-RS instance. This is something that was found necessary in the context
>> of MVC. Sometimes an exception is too extreme an outcome; programmatically
>> inspecting validation errors and crafting a response seems useful.
>
> Note that Bean Validation itself usually will not raise exceptions for
> constraint violations (exceptions will only be raised in the case of
> illegal constraint declarations and the like). Instead, the different
> validation methods on (Executable)Validator return a
> Set<ConstraintViolation>.
Right, it’s a JAX-RS thing.
>
> So JAX-RS for instance could define a callback such as
> ConstraintViolationMapper which applications could use to alter the
> response depending on the specific constraint violations. Although,
> thinking about it, the same might already be achievable today by
> providing an exception mapper for ConstraintViolationException. At
> least if that's how JAX-RS providers are propagating constraint
> violations internally.
The difference is that mappers are global, and this type of processing tends to be resource specific.
— Santiago
> 2017-01-12 15:49 GMT+01:00 Santiago Pericasgeertsen
> <santiago.pericasgeertsen_at_oracle.com>:
>> Hi Gunnar,
>>
>> * The first is I18N of validation error messages. If nothing else is
>> configured, BV uses the JVM default Locale for accessing validation
>> message bundles. For JAX-RS it'd be great if the request locale (as
>> expressed via the Accept-Language header) could be used instead, if
>> present. Some people achieved that using some ThreadLocale hackery
>> [1], but mandating this behaviour in the JAX-RS spec would be much
>> more convenient.
>>
>>
>> Of course, this makes perfect sense.
>>
>>
>> * The other thing is means of disabling automatic validation of BV
>> constraints as part of the JAX-RS request lifecycle. That's based on a
>> request by Antonio Goncalves [2] and it seems reasonable to me.
>> Similar to the BV integration of JSF and JPA, there could be a
>> JAX-RS-defined property for controlling the validation behaviour,
>> allowing to disable it if needed, e.g. during certain kinds of
>> testing. It could look very similar to the property JPA defines for
>> that purpose:
>>
>> javax.persistence.validation.mode={auto|callback|none}
>>
>> "auto" will perform validation during the entity lifecycle if a BV
>> provider is present. So will "callback", with the difference that it
>> raises an exception if no BV provider is present. "none" will disable
>> validation.
>>
>>
>> It would also be nice to support injection of validation errors for further
>> processing by the JAX-RS instance. This is something that was found
>> necessary in the context of MVC. Sometimes an exception is too extreme an
>> outcome; programmatically inspecting validation errors and crafting a
>> response seems useful.
>>
>> If you have a few mins, it would good to capture your suggestions as JIRAs
>> [1]. We plan to address the new big-ticket items first and then go over
>> those JIRAs.
>>
>> Thanks.
>>
>> — Santiago
>>
>> [1] https://java.net/jira/browse/JAX_RS_SPEC
>>
>>