Guillaume VIEL :: java jee tomcat linux

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

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...

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.



samedi 2 octobre 2010

Spring AOP advice et pointcut sur Servlet

La puissance de Spring AOP se limite a priori à son contexte (cf ce post http://forum.springsource.org/archive/index.php/t-11673.html )... Les servlets sont hors contexte Spring car gérées par le serveur d'application JEE et semblent exclues du champ de Spring AOP. Cependant, il est tentant de vouloir quand même utiliser Spring AOP sur les servlets sans avoir à passer par d'autres tisseurs d'aspects (comme AspectJ) qui complexifient la configuration du serveur d'application et le déploiement de l'application. Il s'avère que c'est possible par un moyen détourné. Il fallait juste y penser.

Lire la suite...

Spring AOP : trouver le bon pointcut avec la stack trace

Il est parfois difficile d'identifier le bon endroit pour une "coupe" (pointcut), et il ne faut pas perdre de vue qu'une méthode protected ne pourra jamais être interceptée par Spring AOP.

J'ai donc écris ce bout de code pour me faciliter la tâche et identifier plus aisément quelle pourrait être la méthode déclarée en public et donc candidate au pointcut.

Ce code est à placer dans la méthode qui sera appelée en dernier dans le fil d'exécution afin d'avoir une liste complète des méthodes pouvant être interceptée

        // récupération d'une trace de la pile pour notre thread courant
StackTraceElement[] stack = Thread.getAllStackTraces().get(Thread.currentThread());

for(StackTraceElement ste : stack) { // on parcourt la pile
// on parcours la liste de toutes les méthodes pour la classe
// trouvée dans la stack trace et l'on vérifie si la méthode
// utilisée dans la stacktrace est bien publique
Method[] methods = Class.forName(ste.getClassName()).getMethods();
for(Method m : methods) {
if(m.getName().equals(ste.getMethodName())) {
if(Modifier.isPublic(m.getModifiers()) ) {
logger.debug( ste.getClassName() + "." + ste.getMethodName() );
}
}
}
}

lundi 13 septembre 2010

Web services securisés avec CXF et WSS4J (partie 1)

La sécurisation des webservices devient de plus en plus nécessaire dans le monde de l'entreprise. Il y a une époque pas si lointaine, les entreprises ne se souciaient pas trop de la sécurisation de leurs données à l'intérieur de l'entreprise. Or il s'avère que les risques sécuritaires viennent majoritairement de l'intérieur!

Voici donc un tutoriel qui explique comment mettre en place toute l'infrastructure webservice : serveur et client. Nous utiliserons CXF qui nous parait être une des solutions les plus efficaces et maniables. CXF allie performances et simplicité d'intégration avec la plupart des frameworks (Spring et WSS4J).

Lire la suite...

jeudi 1 avril 2010

Oracle native JDBC connection extractor

L'utilisation d'API Oracle Java, comme par exemple la SDO API (sdoapi.jar) ou Oracle Network Modeling (sdonm.jar) pour gérer les graphes, nécessite d'avoir une connexion native Oracle. Or les applications sont souvent configurées avec un pool de connexions gérées par le conteneur JEE. Ceci pose alors problème pour les opérations spécifiques qui nécessitent d'avoir une connexion de type oracle.jdbc.OracleConnection et non une connexion de type java.sql.Connection. Cette dernière ne pourra en effet pas être utilisée avec les méthodes des API Oracle en Java.

Il faut alors extraire la connexion native sous-jacente à la connexion du pool de connexions.

Lire la suite...

dimanche 21 juin 2009

Statistiques Hibernate et EHCache via JMX grâce à Spring

Récemment, chez un client, nous avons dû mettre en place un cache de données pour améliorer les performances de l'application. Même si l'on peut attendre des gains de la mise en place d'un cache de données EHcache, encore faut il affiner le paramétrage en fonction de l'utilisation réelle de l'application. La seule manière de faire est d'avoir des statistiques sur le cache et les requêtes envoyées à la base de données. Mode d'emploi.

Lire la suite...