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