Community
Participate
Working Groups
The locale on client-side is derived from the underlying platform. If the client part is running in a multi user environment (e.g. RAP) it is currently not possible to use different locales for different users. Scout's server part addresses the very same problem by using LocaleThreadLocale instead of Locale. The former one assigns a locale to each thread or uses the platform's default locale. Using this approach on client-side as well requires to store a locale on the client session and to set it on each client job.
Added locale to session and set LocaleThreadLocal whenever a ClientJob is executed. Migration: - Possibly available ClientSession.getLocale and ClientSession.setLocale must either be removed or renamed. - Dynamically changing the locale must be propagated to the client session as well. - Accessing a client's locale should always done by invoking LocaleThreadLocal.get() - ClientJob.run (and therefore ClientSyncJob.run as well as ClientAsyncJob.run) should not be overridden anymore. The method will be marked final in a subsequent release. Use ClientJob.runStatus or ClientJob.runVoid instead.
Marking the org.eclipse.scout.rt.client.ClientJob.run(IProgressMonitor) final in a subsequent release is not enough to ensure valid job environments. The method must be changed to final in this release and the current running ClientJob must be accessible as well, regardless of whether it is executed by the Eclipse job queue or from an arbitrary thread by invoking runNow. Additionally, changing the ClientJob this way provides a dual implementation to the ServerJob. This change enforces all implementors to override org.eclipse.scout.rt.client.ClientJob.runStatus(IProgressMonitor) instead of org.eclipse.scout.rt.client.ClientJob.run(IProgressMonitor).
Implemented as specified by andi bur.
ticket closed. deliverd as part of eclipse scout 3.8.0 (juno release train)
