In my current rest-service scenario I need to be able to provide localized error messages to individual clients.
Think of a method like void validate(Locale locale) which is called on the parameter object when receiving some request.
The locale information can be squeezed out of the http headers.
How can I instruct/configure a validator to use a certain language when violation messages are getting interpolated?
As far as I know a validator chooses the used Locale by calling Locale.getDefault().
So far I couldn't find anything other than this article which does not exactly fit to my needs (a story too long to tell).
Thanks in advance!
According to the spec you have two possibilities:
Use interpolate(String, Context, Locale) or
implement a custom message interpolator.
A custom message interpolator may be provided (e.g., to interpolate contextual data, or to adjust the default Locale used).
See also:
Example 5.10. Use MessageInterpolator to use a specific Locale value
Example 5.11. Contextual container possible MessageInterpolator implementation
Related
There is quite a lot of documentation and guides that describe how to set up message localization in Spring framework. All of these that I found consider only changing messages (texts) on the webpages, but not page URLs. I would like to have completely different URLs for each locale. For example, http://example.org/en/welcome would be used in the English version, but http://example.org/de/willkommen would be used in the German version.
I assume that I will not be able to use class annotations to route the pages. I prefer storing the path–controller mapping in a file and loading it at runtime.
Could you tell me at least how to not hav
Websites implement localization in one of two ways. The first approach involves automatically detecting the user locale by examining HTTP request headers (Accept-Language header in particular) and localizing site content for the user locale (if supported).
Spring MVC uses this approach by default. It uses the HttpServletRequest.getLocale method to determine the client locale and then loads localized messages from message sources. Note that the getLocale method returns a single Locale object whereas the Accept-Language header passed by the client could contain multiple languages (for example, Accept-Language: en-US, en-GB, en). In such cases, the getLocale method returns the Locale for the first matching language (en-US in the example above).
Therefore, if you wish your Spring MVC application to automatically detect the client locale and serve localized content, simply declare a ResourceBundleMessageSource bean in the application context. No other configuration is required.
The second approach used by websites is to always display content in a default language first and then allowing the user to change the locale (using a dropdown or links in the site header or footer). In such cases, the users may choose locales that are not consistent with the Accept-Language header sent by their browser. For example, the Accept-Language header may contain fr-CH while the user may select de-DE as the locale.
It is in such scenarios that LocaleChangeInterceptor and SessionLocaleResolver are required to use the user selection instead of the request headers. These components can intercept the user choice and save it temporarily for the duration of the session to localize the site content correctly.
and if you want more info refer this:
Spring Localization without passing language in query string
Me and my colleague want to develop a camel component that not only takes care of the connectivity, but also converts the standard xml and / or json formats into the necessary message format for the target system.
Where should we implement that? In our opinion, we have two options:
Implementation directly in the producer
Implementation in a converter class which is used by the producer
Is there a standard or is it up to the developer himself how many helper classes he defines for his camel component?
There is no enforced standard. Both options are valid and it depends a bit. The type converters are more flexible and allows you to do these convertions elsewhere than only when sending via the producer.
For example some components that support industry standards like HL7 provide type converters to offer that kind of flexibility.
And some other components where these data formats of the target system are very special/specific do not use type converters but do it directly in the producer.
So we are using the nice #RabbitHandler annotation in spring-amqp to create endpoints that resemble the coding style of RestControllers but work with Rabbit under the hood. Its all very nice and neat and it works great especially with dynamic resolution of method handlers based on signatures. However we are facing a bit of a controversy here.
So imagine the following method
#RabbitHandler
public void handleEmailDto(EmailDto message) {
System.out.println(message);
}
This will get handled by fromMessage method on the MessagingMessageConverter.java class. At a certain point down the chain the type information of the message will be required in order for the handler resolver to determine which method to call with the payload of the message, and what class to serialise the payload to. The thing is we are using MappingJackson2MessageConverter. Nevertheless, we need a populated ____TypeId____ prop of the message with the fully qualified name of the type of the class. Thats not a problem either. very well engineered and thought out.
The problem comes when this class is not on the classpath. This is actually a huge pain for us as we are working in a microservices environment and some of our services are completely decoupled. That is.. we do not want to have "common" artefact which holds our data domain, just so we can use it at runtime in both the sender and receiver of the message. I have traced through the code, and I see how this hole type situation has been handled and why it is done the way it is.
However from architectural perspective, this is quite limiting... Does that mean that we definitely need to share code between microservices that are quite decoupled otherwise just to satisfy serialization/deserialization/method resolution logic ?
Maybe I am missing something or overlooking another way of doing it. If that is the case, I am certainly opened to suggestions. Thanks in advance for the help.
1.6 has a new feature where the argument type of the #RabbitListener is supplied to the JSON message converter which it can use instead of type id headers.
Unfortunately, this mechanism doesn't work with #RabbitHandlers because the hander method is (has to be) determined after the payload has been converted.
You don't need the source type on the class path, you can configure the converter to use a different type; see this test case for an example where we send a Foo1 and receive a Foo2.
The listener is here and the listener factory configuration with customized converter is here. See how the idClassMapping is set up to convert to the Foo2 type.
Obviously the type has to be compatible with the source type, but it doesn't have to be the same class.
I am trying to understand the concept of binding data from the POST to the model. I want to know whether we can have a control over how the binding is happening. I guess we can control the binding parameters using registering custom editors. But I want to have a finer control over the individual fields of the form. I mean when we register a custom editor, say for date, then all the instances of the, say date, will be treated the same. But may be I want to treat a particular date differently from the others. Moreover, I want to get the POST request parameters in raw string format and may be manipulate one or two fields and delegate the rest to the spring. I guess in the pre-annotation version of spring there was the provision of similar control for some method, may be processFormSubmission. So please let me know whether we can accomplish this in spring 3 annotation version.
Thanks
For the format of Date's you can use the #DateTimeFormat annotation. The annotation is specified on each field, so each field can have it's own format.
You can format and convert whatever fields you want using Formatter and ConversionService.
The documentation on all this can be found here.
I am not really a fan of the default messages used if the #RequestParam fails to validate (type, required, etc). I would like to use my own custom messages.
I also have several parameters that are conditionally required.
I am thinking to achieve this I will need to roll my own HandlerMethodInvoker. resolveHandlerArguments using a modified version of RequestParam.
Is there an easy way to 'inject' my new version of HandlerMethodInvoker into Spring? If not, will I need to create my own DispatcherServlet and the various pieces between it and HandlerMethodInvoker?
If you only want to replace the validation messages then you only need to add some properties to the message files.
For more details read Spring Reference Chapter 5.3 Resolving codes to error messages and have a look at the java doc of org.springframework.validation.DefaultMessageCodesResolver, it explain the used message codes very vell.