play framework 2.0.1DateFormatter reçoit paramètres régionaux du système

Question

j'ai écrit une coutume DateFormatter en jeu 2.0/Java, car celui par défaut semble être i18n-pas au courant (les détails de mise en œuvre ne sont pas pertinentes ici)

public class DateFormatter extends Formatters.SimpleFormatter<Date> 

Ma configuration de l'application contient

application.langs="pt-br, en" 

Les langues définies dans les options du navigateur contiennent ces deux (accepter langue)

Logiquement, Lang.preferred (Liste) retourne p t-br comme langue préférée comme dans

@Override 
public Action onRequest(Request request, Method method) { 

    Lang preferred = Lang.preferred(request.acceptLanguages()); 
    Logger.debug("Preferred language is " + preferred.toLocale()); 

    return super.onRequest(request, method); 
} 

MAIS (et assez tristement)

les paramètres régionaux reçus par mon DateFormatter personnalisé dans

@Override 
public Date parse(String date, Locale locale) { 
    ... 
} 

est le lieu de système (JVM), en -US, et ne pas en demander un préféré.

Est-ce normal? Qu'est-ce que j'oublie ici ?

Answer 1

Je pense que vous pouvez utiliser cette solution de contournement:

Pour chaque demande, en utilisant le Global interceptor, vous pouvez définir le LocaleContextHolder pour définir les paramètres régionaux de votre demande:

public class Global extends GlobalSettings { 

    @Override 
    public Action onRequest(final Request request, Method actionMethod) { 
     LocaleContextHolder.setLocaleContext(new LocaleContext() { 
      public Locale getLocale() { 
          Lang preferred = Lang.preferred(request.acceptLanguages()); 
       return preferred.toLocale(); 
      } 
     }); 
     return super.onRequest(request, actionMethod); 
    } 

} 

Je ne l'ai pas tester, mais ça vaut le coup :-)

Answer 2

Malheureusement le remplacement global mentionné par nico ekito n'est pas une solution fiable dans Play 2.2, probablement à cause des threads. Mon expérience est que les paramètres régionaux étaient parfois incorrects et que le formateur fonctionnait de manière imprévisible (parfois, le formatage dans une autre langue était mis en contexte).

Donc, fondamentalement, la solution finale de John Smith est beaucoup plus fiable. Au lieu d'utiliser locale passée dans le paramètre de la méthode de formatage, utilisez l'y locale contexte:

public Date parse(String date, Locale locale) { 
    Context context = Context.current(); 
    Lang preferred = Lang.preferred(context.request().acceptLanguages()); 
    Locale contextLocale = preferred.toLocale() 
    ... 
}