Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spring WebFlux - Custom messages validation in different languages [SPR-17231] #21764

Closed
spring-projects-issues opened this issue Aug 31, 2018 · 6 comments
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: superseded An issue that has been superseded by another type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

jakubdyszkiewicz opened SPR-17231 and commented

Hello,

I've got a problem with providing custom messages in different languages for bean validation using WebFlux. It does not use messages for locale I send in header.

I think this is a bug because LocalValidatorFactoryBean uses LocaleContextMessageInterpolator. Hibernate Validator calls the public String interpolate(String message, Context context) method, which relays on the LocaleContextHolder. It uses a ThreadLocal which can't be used in WebFlux.

I created sample repository, I hope you find it helpful
https://github.com/jakubdyszkiewicz/webflux-validation

There is the issue I created by mistake in spring-boot project spring-projects/spring-boot#14253

Dmytro Nosan provided workaround, but I think it should work out of the box.

Thanks


Referenced from: commits spring-attic/spring-framework-issues@d059b1a

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

We could potentially (re-)expose a short-lived thread-local for affected callbacks in WebFlux. This would be the easiest way to make existing locale resolution work... Otherwise we'd have to support an explicit Locale argument in every such place.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

jakubdyszkiewicz thanks for the sample project, and sorry for the delay!

Juergen Hoeller, we could set LocaleContextHolder in a try-finally block within the validate methods of AbstractMessageReaderArgumentResolver and ModelAttributeMethodArgumentResolver, the two places in WebFlux where such validation is applied. We could even if check with LocaleContext#getLocale() to see if there is a need. That said, it would be more in character for WebFlux to pass the locale. One way or another I see no way around the need to be aware of having to pass the Locale.

Couldn't we pass the LocaleContext as one of the validation hints? Then when processing constraint validations, SpringValidator or rather the LocalValidatorFactoryBean, would have a chance to look up through the MessageInterpolator with the LocaleContext provided as a hint. Or some such approach where the error messages are post-processed and mapped to their Locale-specific values.

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) and removed type: enhancement A general enhancement labels Jan 11, 2019
@slonka
Copy link

slonka commented Apr 1, 2021

Any updates on this?

@mdsina
Copy link

mdsina commented Jan 31, 2022

Someone have custom implementation for this?

@hicnar
Copy link

hicnar commented Apr 17, 2022

Any news here?

@rstoyanchev
Copy link
Contributor

This is now superseded by the attached pull request #28739.

@rstoyanchev rstoyanchev closed this as not planned Won't fix, can't repro, duplicate, stale Jan 27, 2023
@rstoyanchev rstoyanchev added status: superseded An issue that has been superseded by another and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: superseded An issue that has been superseded by another type: enhancement A general enhancement
Projects
None yet
6 participants