2017-06-05 11:07 GMT+02:00 Pavel Bucek <pavel.bucek@...>:
I'm sorry to say that, but I don't think that proposal is viable.
What if the app (BV layer) knows Locales L1 and L2 and the user (request)
asks for L3;q=0.9, L2;q=0.5, L1;q=0.1. In the latest version of the
proposal, L3 will be chosen - what happens when L3 is passed to BV?
The fallback mechanism of the JDK ResourceBundle API will kick in
which depends on the relationship between requested locales.
So say L3 = EN_US and L2 = EN, the ResourceBundle API automatically
will take care of that fallback and use EN if no messages for EN_US
are present. If L2 was something unrelated, e.g. FR then it'd fall
back to the default messages in whatever language defined by the user
(and in English as measure of last resort for the built-in
Producing an error? Using a default Locale? Neither is a good behavior, L2
should be selected. I haven't seen anything in BV which would return set of
I thought that's where the suggested LocaleResolver SPI comes in. The
user will know in which languages they have provided validation
messages, so they could plug in an alternative LocaleResolver which
could select L2 over L3 in your example.
Also, the selected locale (whatever it is), should be made available to
JAX-RS application, so it can work with that further if needed. We don't
have anything like that now. Not to mention that the selection process might
need to be pluggable.
Isn't that what the LocalResolver SPI exactly is about?
Last but not least - we would need to define how is the selected Locale used
in whole context of JAX-RS application, which might sound easier as it is.
On 05/06/2017 10:06, Gunnar Morling via Groups.Io wrote:
Any chance for considering the latest proposal for passing the
(highest-quality) request locale to Bean Validation?
2017-06-02 14:48 GMT+02:00 Pavel Bucek <pavel.bucek@...>:
as you might have noticed, we dealt with several small issues in the past
couple of weeks. Notable ones:
- @Priority for providers
- JSON-B integration update
- Introduction of JSON-P integration
- HTTP PATCH support on the server (client side was just reverted)
- CompletionStage can be returned from the resource method
- Response API: AutoCloseable + Status#asEnum
- Support for new HTTP Status codes
Complete list of closed issues:
If you have any questions or suggestions about changes we've made, please
let us know.
We are going to release another API milestone build soon and it will be
likely last milestone before submitting Proposed Final Draft.
Thanks and regards,