X-plode – Blog de Mike François

Un article de X-plode    Pas de commentaires

À l’heure où l’interaction fastidieuse des couches applicatives touche à l’heure fin, je viens faire la présentation en détail des spécificités de ce nouveau bean.

Dans ce second article à propos des JWB, je vais vous exposer en détail :

Les scopes des Web Beans

Prérequis :

Avant de commencer le sujet, je vais définir les termes nécessaires.

Les scopes sont mappés à un objet context et gérés par le manager Web Bean.

Qu’est ce qu’un objet context ?

Un objet context détermine le cycle de vie et la visibilité des instances de tous les JWB qui possède le même scope.

Que gère le manager Web Bean ?

Il gère :

– La création, la destruction et gère la portée d’un context des Web Beans particulier
– La résolution de portée par type API, type d’annotation binding quand ils sont injectés
– La résolution de portée par type API et annotation
– Resolution de portée par nom ( utilisé dans une expression EL )
– Rappel de cycle de vie et l’injection automatique des autres instances Web Beans
– Interception de méthode, les interceptions de callback, et les decorations
– Les notifications d’évènements

Les scopes des JWB

Bon, rentrons dans le vif du sujet :

Par défaut, les JWB ont 4 scopes :
@RequestScoped
@ApplicationScoped
@SessionScoped
@ConversationScoped

Et 1 pseudo scope :
@Dependent

@RequestScoped :

Le request scope possède un context éphémère, qui est actif seulement pour une action donnée.

De : javax.webbeans.RequestScoped.

Il peut y avoir trois cas:

L’appel à une Servlet :
La requete du scope est actif pendant toute la durée de vie de la méthode service() d’une Servlet dans une application web.
Le context de la requête est détruit à la fin de la requête de la servlet, après le retour de valeur de la méthode service().

L’appel à un service web JEE :
La requete du scope est actif durant l’invocation d’un service web JEE.
Le context de la requete est detruite apres la complete invocation du service web.

L’appel à un EJB :
La requete du scope est actif durant n’importe quelle invocation d’une méthode distante d’un EJB, au cours de tout appel à une méthode EJB timeout et au cours d’un message délivré par n’importe quel EJB Message Driven Bean.
Bien entendu, le context requête est détruit à la fin de toutes ces opérations.

@ApplicationScoped :

L’application scope est identique à celui du scope request à cela prêt qu’il diffère dans la fin du context sur le scope.

De : javax.webbeans.ApplicationScoped

La requete du scope est actif pendant toute la dureté de vie de la méthode service() d’une Servlet dans une application web.

La requete du scope est actif durant l’invocation d’un service web JEE.
Le context de la requete est détruit après la complète invocation du service web.

La requete du scope est actif durant n’importe quelle invocation d’une méthode distante d’un EJB, au cours de tout appel à une méthode EJB timeout et au cours d’un message délivré par n’importe quel EJB Message Driven Bean.

@SessionScoped :

De : javax.webbeans.SessionScoped

Le scope Request est actif pendant toute la duree de vie de la méthode service() d’une Servlet dans une application web.

Le context est partage entre toutes les servlets qui se produisent dans la même session de la servlet HTTP.
Sa destruction est détruite quand le HTTPSession n’est plus valide ou a terminé.

@ConversationScoped :

De : javax.webbeans.ConversationScoped

Chaque JSF possède un scope conversation par défaut. Cependant, nous avons deux cas :

Une requête JSF Faces, auquel cas, nous avons un context actif depuis le commencement jusqu’à se que la réponse soit complétée.

Une requête JSF non Faces, qui a un context actif que durant le rendu de la réponse.

Cette association est gérée par le Web Bean Manager.

Pour information, cette association est effectuée à la restauration de la vue et ne change pas durant la requête.

Une conversation peut avoir deux états.
– Soit transient.
– Soit long-running.
Par défaut, c’est une conversation transient.
Mais nous pouvons détermine la conversation long-running en appelant sa méthode Conversation.begin() et en la terminant par Conversation.end().

Jusque-là, tout est normal. Cependant, je suis sûr qu’une question subsiste dans votre subconscient :

Comment le Web Bean Manager peut gérer les différentes conversations si on en détermine plus d’une,
tout en sachant qu’une conversation est associée à une requête JSF ?

Le principe est simple : un identifiant unique est déterminé (un String).

Tout autant, nous pouvons définir nos propres scopes.
Pour définir un type scope, nous devons :

– Définir une meta-annotation : @ScopeType
– Avoir défini @Target({TYPE,METHOD})
– Et ajouter @Retention(RUNTIME)

Comme je l’ai dit précédemment, un scope est lien à un objet context. Pour cette raison nous devrons définir le scope via notre manager.

Jusque-là tout va bien. Mais comment faire appel au manager ?

Le manager est une interface:

Et nous lui faisons appel par:

manager.addContext(new MethodContext());

Bon ok. Jusqu’ici, la notion est… Abstraite.

Le Web Bean Manager fait tout le temps appel à Manager.getInstance() durant l’instance ou une résolution de nom d’Expression Language.

Ainsi, pour remplir sont rôle, il fait appel à Manager.getContext() pour retrouver les objets context actif associé au scope du JWB.

( Pour information : public Context getContext(Class<? extends Annotation> scopeType); )

Au final, comment déclarer notre scope :

Le pseudo-scope : @Dependent

De : @javax.context.Dependent

Le scope @Dependent est dit pseudo-scope car il diffère de comportement comparé aux autres scopes.

– Aucune instance du bean injecté n’est partage avec les autres points d’injection
– Chaque instance du bean est limité au cycle de vie du bean, servlet ou EJB qui a été injecté.
– Chaque instance du bean qui est utilisé pour évaluer une expression UEL existe uniquement pendant la durée de l’évaluation
– Chaque instance du bean qui recoit une methode producer, un champ producer, une methode dsposal ou l’appel d’une méthode observer dure uniquement pendant la durée de l’invocation.

Mes prochains articles sur les Web Beans porteront sur : les types de binding, les types de déploiement, les Names Web Bean, les stéréotypes…