Guillaume VIEL :: java jee tomcat linux

Aller au contenu | Aller au menu | Aller à la recherche

Tag - springframework

Fil des billets - Fil des commentaires

mardi 31 janvier 2012

Log4j : changer le niveau de log à chaud via JMX

Changer le niveau de log directement sans avoir à redéployer l'application est parfois indispensable sur des plateformes critiques où il est impossible d'interrompre le service. C'est aussi un moyen de déboguer directement sur une plateforme qui est la seule à présenter un bug non reproductible ailleurs.

Il existe plusieurs solutions dont :

  • relecture de la configuration Log4j à intervalle régulier; il suffit alors de modifier la configuration des niveaux de log directement (soit avec l'API Log4j, soit avec les classes utilitaires de Spring Log4jWebConfigurer)
  • changement des niveaux de log à l'aide de JMX

C'est cette dernière solution que je préfère, car il est généralement déconseillé de modifier directement des fichiers à chaud dans un serveur d'applications.

Il faut d'abord créer une classe avec une méthode permettant de modifier le niveau de log de n'importe quel package :

Lire la suite...

mercredi 4 janvier 2012

Log4j avec Spring et applications multiples dans Tomcat

Je déploie habituellement les applications web dans Tomcat en multi-instance avec une instance Tomcat par application (ceux qui croient que c'est une hérésie iront voir les concepteurs de Tomcat Mark Thomas et Filip Hanik qui préconisent eux mêmes cette solution). Cependant, dans certains contextes, et notamment chez certains clients, les contraintes font que l'on est obligé de faire autrement...

Dans le cas présent, c'est la configuration de log4j via Spring qui pose (encore) problème : je déploie 2 applications identiques (avec configuration applicative légèrement différente) sous 2 contextes différents dans le même serveur Tomcat. Se posent donc 2 problèmes :

  • il faut pouvoir packager l'application sous des formes différentes et notamment 2 contextes différents : /my-app1 et /my-app2, donc paramétrer le packaging
  • la configuration log4j est à priori identique pour ces 2 applications (packages identiques) : ceci pose le problème de la séparation des logs (et éventuellement la différenciation des niveaux de log)

Lire la suite...

mardi 22 février 2011

Message Bundle avec Spring et problèmes d'encodage des fichiers de properties

Sur une application destinée à l'international, j'ai tout naturellement souhaité introduire l'internationalisation (i18n) des messages destinés aux utilisateurs, aux logs, aux erreurs etc.

Je me suis penché sur ce que propose Spring et j'ai commencé avec cette configuration très sommaire :

<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename" value="message"/>
</bean>

Le premier problème c'est l'apparition de ??? à la place de certains caractères UTF-8 : gênant non?! Ceci est en fait dû au ResourceBundleMessageSource de Spring qui utilise les classes standards java.util.ResourceBundle et java.util.Properties, or ces dernières ne supportent visiblement que l'encodage ISO-8859-1 !!!

La solution est d'utiliser le ReloadableResourceBundleMessageSource de Spring, plus complet. Il suffit de lui indiquer le defaultEncoding choisi.

L'autre problème est la non reconnaissance des fichiers de properties (mis dans le classpath) que j'ai nommés message_en.properties , message_fr.properties, etc. Apparemment il faut ajouter le paramètre fallbackToSystemLocale=false sur le ReloadableResourceBundleMessageSource de Spring pour éviter que soient recherchés les fichiers du type message_fr_FR ou message_en_FR.

<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<property name="basename" value="classpath:message"/>
<property name="fallbackToSystemLocale" value="false" />
<property name="defaultEncoding" value="UTF-8"/>
</bean>

Sources :

http://www.cakesolutions.net/teamblogs/2009/04/02/utf-8-encoding-and-message-sources/

http://forum.springsource.org/showthread.php?t=18199&page=2

mercredi 16 février 2011

Archetype maven et quickstart pour spring batch

Les archetypes maven ne semblent pas très fonctionnels... Pour créer un template de projet à partir d'un archetype existant voici la commande à exécuter :

$ mvn archetype:generate
Maven sort alors une liste d'une vingtaines d'archetypes possibles. On peut alors choisir l'archetype à utiliser et le customiser. Maven génère alors un répertoire projet prêt à l'emploi. En les testant on s'aperçoit que sur la majorité des archetypes disponibles, seuls quelques uns fonctionnent vraiment...
La liste des archetypes possibles se trouve ici : http://docs.codehaus.org/display/MAVENUSER/Archetypes+List
C'est un peu décevant...

De même, j'ai cherché un archetype pour Spring-batch. Visiblement rien n'existe et l'infrastructure maven ne semble pas être utilisée pour ça. Le mieux que j'ai trouvé c'est d'aller directement récupérer les exemples de code qui existent sur le repository SVN de spring !

$ svn export  https://src.springframework.org/svn/spring-batch/trunk/archetypes/simple-cli
$ cd simple-cli
$ mvn test

Et voilà! On y trouvera aussi d'autres exemples de projet.