How to get current Locale inside ResilienceDecorator.execute?

[mkampermann]

Ask the Question

Hello SDK team,

Internal SAP employee here (if that matters). Our setup is a service using Cloud SDK, CAP, and DWC.

We are trying to extract the current locale, however, as soon as we are in a ResilienceDecorator.executeCallable method, the HttpRequest and its locale is no longer available (which makes sense, I guess).

For the moment, we found a few solutions:

Here, we manually put the locale inside the resiliented function:

@Override
			public <T> Callable<T> decorateCallable(Callable<T> callable) {
				var locale = LocaleContextHolder.getLocale();

				return () -> {
					LocaleContextHolder.setLocale(locale);

					try {
						return callable.call();
					} finally {
						LogContext.initializeContext();
					}
				};
			}

Alternatively, we could tackle the RequestHeaderAccessor, and then extract the locale from the header:

var acceptLanguageRawString = RequestHeaderAccessor.getHeaderContainer().getHeaderValues("accept-language").stream()
					.findFirst()
					.orElse(null);

			if (StringUtils.isBlank(acceptLanguageRawString)) {
				return Locale.getDefault();
			}

			return Locale.LanguageRange.parse(acceptLanguageRawString).stream()
					.sorted((r1, r2) -> Double.compare(r2.getWeight(), r1.getWeight()))
					.map(Locale.LanguageRange::getRange)
					.map(Locale::forLanguageTag)
					.findFirst()
					.orElse(Locale.getDefault());

What, do you think, would be the best approach? Do you know even a better way to get the current locale?

Best regards
Marcel

[Jonas-Isr]

Hi @mkampermann,

thanks for reaching out! The Cloud SDK stores locale information in the ThreadContext, so it should be accessible also from inside your resilience call. The SDK-native way to access this would be via the LocaleAccessor. You should be able to call the following code from inside the callable you execute through the ResilienceDecorator.

Locale locale = LocaleAccessor.getCurrentLocale();

Regarding your two examples: I do not know the class LocaleContextHolder as it is not from the SDK and therefor I cannot say much about it. Your second attempt looks like it would work on first glance but also seems a bit verbose compared to using the LocaleAccessor. This is why I would suggest using the above way to do it.

Best,
Jonas