Seam : visualiser au runtime les composants actifs
Dans un article précédent, je racontais que j'avais aidé un collègue à reprendre une appli Seam/JSF qui avait des problèmes de mémoire.
Mon premier mouvement, pour avoir une idée du nombre et de la durée de vie des composants créés, a été de faire un petit tableau admin pour lister tous les composants en mémoire et monitorer les conversations.
Pour ça, on a utilisé deux composants builtin de seam (cad qu'ils sont déployés automatiquement par seam) : Contexts et Conversation.
Contexts a un lien sur chaque Context (scope) de seam. Et la classe Context propose une méthode simple : getNames(). En appelant cette fonction sur un contexte, vous aurez le nom de chaque composant vivant dans ce contexte.
Exemple :
Conversation permet de contrôler et de monitorer la conversation courante. Parmi ses méthodes, on en trouvera quelques unes utiles pour le monitoring : getId(), isLongRunning(), isNested() et getParentId().
Ce petit panel de débug nous a été utile presque immédiatement : un composant contenant un datamodel de *beaucoup* de ligne était en scope session. Ce qui expliquait en partie pourquoi l'application sautait à 5+ utilisateurs !
Cool non ?
tags : Java EE, Seam
Mon premier mouvement, pour avoir une idée du nombre et de la durée de vie des composants créés, a été de faire un petit tableau admin pour lister tous les composants en mémoire et monitorer les conversations.
Pour ça, on a utilisé deux composants builtin de seam (cad qu'ils sont déployés automatiquement par seam) : Contexts et Conversation.
Contexts a un lien sur chaque Context (scope) de seam. Et la classe Context propose une méthode simple : getNames(). En appelant cette fonction sur un contexte, vous aurez le nom de chaque composant vivant dans ce contexte.
Exemple :
<r:dataList var="comp" value="#{contexts.getApplicationContext().getNames()}"> <h:outputText value="#{comp}" /> </r:dataList>
Conversation permet de contrôler et de monitorer la conversation courante. Parmi ses méthodes, on en trouvera quelques unes utiles pour le monitoring : getId(), isLongRunning(), isNested() et getParentId().
Ce petit panel de débug nous a été utile presque immédiatement : un composant contenant un datamodel de *beaucoup* de ligne était en scope session. Ce qui expliquait en partie pourquoi l'application sautait à 5+ utilisateurs !
Cool non ?
tags : Java EE, Seam