Everything is wrong » Tomcat

@Model versus @Named versus @ManagedBean

Yan — Tue, 04 Feb 2014 21:52:29 +0000

Lorsque l’on débute en J2EE il est parfois difficile de voir la différence entre certaines annotations. Elles proviennent souvent de spécifications (JSR) différentes et peuvent avoir un rôle similaire ou totalement identique. Certaines fois, il s’agit uniquement d’une différence de contexte dans lequel le code est développé ou déployé.

Les annotations suivantes sont utiles pour déclarer des objets Java qui vont être accessibles dans le langage EL via les symboles #{} (on parle d’outjection par opposition à injection).

@javax.faces.bean.ManagedBean

Cette annotation arrive avec la JSR-314 JavaServer Faces 2.0. Grâce à elle, il n’est plus nécessaire de déclarer les Managed Bean JSF dans le fichier XML faces-config.xml. Elle n’est utile que lorsque le l’application développée est déployée dans un contexte où le conteneur CDI n’existe pas, comme Tomcat par example.

De plus, elle peut facilement être confondue avec l’annotation suivante @java.annotation.ManagedBean.

@javax.annotation.ManagedBean

Cette annotation est définie dans la JSR-250. Elle est utilisée pour déclarer un managed bean spécifié dans la JSR-316. Il ne faut pas confondre avec les managed bean JSF. Le principe de la JSR-316 est de pouvoir transformer n’importe quel POJO (Plain Old Java Object) en objet pouvoir avoir un cycle de vie, des intercepteurs, etc.

Dans un contexte CDI, cette annotation est obsolète car le principe du CDI est de transformer tous les POJO en Managed Bean. Donc cette annotation n’est pas du tout utile. Elle n’aura d’ailleurs aucun impact visible sur l’exécution du code.

@javax.enterprise.inject.Model @javax.inject.Named

L’annotation @Model est équivalante à l’annotation @Named à laquel il a été rajouté le contexte @RequestScoped (@javax.enterprise.context.RequestScoped).

Ces annotations proviennent de la JSR 299 “contexts and dependency injection” (CDI). Cette JSR offre beaucoup plus de possibilités d’utilisation que celle sur JSF2.0. Dans un contexte où une application est déployée dans un conteneur compatible CDI il est donc préférable d’utiliser les annotations CDI plutôt que JSF2.0.

Conclusion

Le choix de l’annotation à utiliser dépend essentiellement du conteneur où l’application sera déployée. Il est toujours préférable d’utiliser les annotations provenant de la JSR-299 (CDI) dans le cas où le conteneur est compatible avec CDI.

Pour plus d’information cet article est très intéressant : Is @javax.faces.bean.ManagedBean Dead on Arrival?

Tomcat + weld + JSF : java.lang.OutOfMemoryError: PermGen space

Yan — Sat, 01 Jun 2013 08:48:33 +0000

Après avoir démarré une application utilisant tomcat, weld-servet et JSF2, je me suis rendu compte que j’obtenais rapidement des erreurs de mémoire sur la PermGen space. En gros mon application, aussi petite soit elle, utilisait beaucoup plus de classes que ce que je pensais et surtout que ce que la JVM de Sun pouvait contenir par défaut.

Pour rappel, cette partie de la mémoire est utilisée dans les JVM de Sun pour stocker les classes chargées par le classloader, elle ne se vide jamais sauf si l’on fait des actions directement sur le classloader. La valeur par défaut de cette mémoire est de 64Mo.

A priori, cette valeur n’est pas assez grande pour contenir l’ensemble des classes chargées par weld-servlet et JSF2 dans un tomcat. Pour éviter de retrouver ces erreurs de mémoire, il faut donc l’augmenter avec le paramètre dans la JVM :

-XX:MaxPermSize=256m

Il est possible de voir l’évolution de cette mémoire avec le programme VisualVM qui est fourni par défaut dans une JDK.

mod_jk : Apache & tomcat

Yan — Fri, 19 Aug 2011 19:49:29 +0000

A chaque fois que j’essaie de configurer un tomcat derrière un serveur apache, je tombe toujours sur les mêmes problèmes, je perds toujours du temps à retrouver les mêmes solutions dans les documentations. C’est pour cela que j’écris cet article que j’espère le plus simple et pratique que possible.

Après avoir installé les deux serveurs, il faut télécharger le module apache mod_jk (la version 1.2) sur ce site : http://tomcat.apache.org/download-connectors.cgi.

Déposer le fichier mod_jk.so (qui se trouve dans l’archive téléchargée) dans le répertoire $APACHE_HOME/modules/. Pour configurer ce connecteur, deux fichiers sont nécessaires

workers.properties : permet au connecteur de se connecter au serveur tomcat.
httpd.conf : permet au connecteur de rediriger les requêtes HTTP vers le serveur tomcat.

Voici un fichier worker.properties exemple :

  # La liste des workers
  worker.list= worker1, jkstatus

  # Configuration du worker1 : connexion à tomcat
  worker.worker1.type=ajp13
  worker.worker1.host=localhost
  worker.worker1.port=8009

  # Configuration de jkstatus : agrège des statistiques sur le connecteur
  worker.jkstatus.type=status

Voici quelques lignes à ajouter au fichier httpd.conf pour configurer mod_jk :

  LoadModule    jk_module  modules/mod_jk.so
  JkWorkersFile workers.properties
  JkLogFile     /usr/local/apache/logs/mod_jk.log
  JkLogLevel    info
  JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

Une fois cette communication faite il faut rendre les applications tomcat visibles depuis Apache. Cette étape peut être aussi bien réalisée à partir du fichier httpd.conf que worker.properties. Par exemple, voici la directive à ajouter au fichier de configuration du serveur Apache :

   JkMount /my-webapplication/* worker1
   JkMount /my-webapplication worker1
   JkMount /jkstatus* jkstatus

Il existe beaucoup d’autre façons de configurer ces deux serveurs. Pour plus d’information voici quelques sites qui décrivent dans les détails les différentes configurations possibles :

tomcat-maven-plugin : debug

Yan — Fri, 29 Apr 2011 20:00:24 +0000

Le plugin tomcat de Maven est très pratique lors du développement d’une application web. Voici comment le configurer :

 
 
 
   org.codehaus.mojo
   tomcat-maven-plugin
   
     /${project.build.finalName}
     
     9090

Le plugin démarre le serveur dans la sa propre JVM. Pour pouvoir débuger votre application, il faut donc uniquement démarrer Maven avec l’option de debug comme cela :

mvn tomcat:run -DXdebug -DXnoagent -Djava.compiler=NONE -DXrunjdwp:transport=dt_socket,address=3998,suspend=n,server=y

Ou bien, si vous utilisez eclipse avec le plugin m2eclipse : cliquer avec le bouton droit de votre souris sur le projet : Debug As -> Maven build … .