Discussion :

[grunt2000]

Bonjour,

Pour une application à internationaliser, je dois rendre mes EJB multilingues.
(Pourquoi eux, et pas seulement la partie web? Parce qu'ils sont succeptibles de renvoyer des exceptions métiers dont le contenu sera exploité par l'appelant. Leurs messages dépendent de ce que le serveur d'application jugera utile à un instant donné - lui seul le saura alors -. Cependant l'utilisateur final doit pouvoir le lire ce message, si jamais il devait "lui tomber dessus".)

Tout est ok côté fichiers de ressources, ils sont là déclinés comme il faut. C'est l'invocation proprement dite des EJBs pour servir un appelant étranger (c.à.d. à langue variable) que je dois maintenant étudier.


Ma question: comment traiter le problème simplement?

J'ai quelques centaines d'invocations d'EJB non internationalisés à cet instant. Le plus souvent l'origine d'un premier appel est une page web. Mais un EJB peut appeler un autre EJB pour faire de la composition de service.

1) Une solution serait de placer un paramètre Locale localeUtilisateur dans chaque prototype de méthode dans les EJBs, mais c'est étouffant.

2) Une autre solution serait de dire: à la création de l'EJB, je le crée pour une Locale donnée. Mais là, il faut se défier que pour les EJB stateless, une instance peut se voir réutilisée à l'appel de méthode suivant, alors que l'utilisateur appelant peut très bien avoir une langue différente...

3) Une troisième solution serait de passer par une façade. En disant: avant chaque appel de méthode EJB, je me débrouille pour faire un set de la Locale à utiliser le temps de l'invocation (une instance d'EJB n'étant employée que pour un appel unique à un instant donné, pas de problème de concurrence d'accès sur la langue).
Dans ce cas, cela peut fonctionner sans trop de difficultés pour les invocations initiées côté web, mais dès qu'un EJB A appelle un EJB B pour l'aider à faire son boulot, il faut casser l'invocation B.getInstance().monPetitBoulot(); pour substituer à B.getInstance() un appel de façade.
C'est encore un travail assez important...


Quelle stratégie utiliser pour résoudre ce problème de manière générale?

En vous remerciant,

[Claythest]

Peut-être que les intercepteurs peuvent t'aider non ? (Je ne sais pas si tu y as pensé...) Genre à chaque appel (intercepteur @AroundInvoke), mettre la locale qui va bien... non ?

Le coût est juste de rajouter une ligne précisant l'intercepteur pour chacun de tes EJB...

[grunt2000]

C'est vrai que ça peut être intéressant.
Mais il faudra initialement aller chercher la locale "près du web" pour la première création de l'EJB, et s'assurer que l'intercepteur a exactement le même cycle de vie et de "verrouillage/syncronisation" que l'EJB auquel il est associé.

Si l'intercepteur se met à porter aussi une variable membre Locale m_locale, il ne faudrait pas que son instance soit conjointe à deux appels EJBs (qui auraient lieu, eux-mêmes, dans deux instances stateless distinctes). Sinon, la méthode utilisée pour répondre à la demande de l'appelant a ou b risquerait d'utiliser une locale parmi celle de a ou de b à l'exclusion de l'autre.

Néanmoins, même si les specs nous faisaient malchanceux, je pense que cela peut se corriger.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/** Les locales associées aux instances EJBs en cours. */
private Hashtable<Object, Locale> m_locales = new Hashtable<Object, Locale>(); 

@AroundInvoke public Object intercept(InvocationContext ctx) throws Exception
{
   Locale loc = m_locales.get(ctx.getTarget());

   if (loc == null)
   {
      loc = <valeur à associer>;
      m_locales.put(ctx.getTarget(), loc);
   }

   // On aurait marqué tous les EJBs déclarant setLocale(Locale loc) en leur faisant implémenter une interface.
   InterfaceDesEJBsQuiImplémententToujoursUneMéthodeSetLocale service = (InterfaceDesEJBsQuiImplémententToujoursUneMéthodeSetLocale)ctx.getTarget();
   service.setLocale(loc);

   return ctx.proceed();
}

Ce qui fait que ton idée est intéressante. Reste à trouver le moyen la <valeur à associer> initiale. Et comment assurer qu'un EJB parent transfère aux EJBs qu'il va appeler la locale avec laquelle lui-même a été initié?

Ca doit pouvoir se travailler avec le bloc de code que j'ai écrit plus haut, en faisant que la clé ne soit pas l'instance de l'EJB, mais quelque-chose fait à partir d'un identifiant de session web source initiale de la demande... mais du coup, c'est cet identifiant qu'il faut aussi transporter. Cela déplace le problème, même si en même temps ça a l'atout de l'exprimer mieux.