Blog Xebia France » Benoit Moussaud

Séminaire Deployit: Karavel automatise ses déploiements Tomcat

Benoit Moussaud — Wed, 27 Apr 2011 14:06:51 +0000

De nombreuses sociétés font aujourd’hui confiance aux technologies Java EE pour leurs applications critiques d’entreprise, leurs sites web et / ou leur intranet. Pourtant, nombre d’entre elles se retrouvent aujourd’hui confrontées à un obstacle de taille : comment déployer plus rapidement et de manière plus industrielle des applications toujours complexes, livrées de plus en plus fréquemment sur des socles middlewares différents et/ou sur des environnements de plus en plus nombreux ?

Les tâches de déploiement et de configuration des applications deviennent ainsi bien souvent un goulet d’étranglement quand elles ne sont pas un frein à l’activité.
Deployit, de la société XebiaLabs, a été conçu en collaboration avec KLM/Air France pour adresser cette problématique. Il est aujourd’hui mis en oeuvre avec succès par de nombreuses sociétés dans des secteurs très variés.

Les bénéfices de Deployit

Réduire jusqu’à 95% des erreurs de déploiement et jusqu’à 50% de vos coûts de déploiement classique
Réduire les temps d’attente des équipes via des déploiements en self-service et continus
Standardiser les procédures de déploiement entre différents environnements
Fluidifier les relations entre départements études, intégration/recette et production
Augmenter contrôle et visibilité sur votre processus de déploiement applicatif
Accélérer votre time-to-market

Programme du séminaire : le 29 avril de 9h45 à 11h45, 156 bd Haussmann 75008 Paris

9h45 : accueil
10h : présentation des enjeux du déploiement applicatif et de la solution Deployit
10h30 : démonstration produit
11h : retour d’expérience client Karavel/Promovacances

Public cible : Directeur Informatique, Responsable des Développements / Etudes, Responsable Intégration / QA / Tests, Responsable Production / Exploitation, Responsable Qualité, Architecte, Chef de projet

Inscription: http://www.xebialabs.com/seminaire-deploiement-automatique

Les fournisseurs de serveurs d’application ont-ils vraiment compris le déploiement ?

Benoit Moussaud — Mon, 16 Nov 2009 11:09:35 +0000

Chez XebiaLabs, nous nous y connaissons en déploiement automatique d’applications Java EE. L’une des choses les plus surprenantes réside dans le fait que «les fournisseurs de serveurs d’application ne semblent pas faire partie des personnes qui maitrisent le mieux le déploiement d’applications».

Dans un article précédent, nous avons décrit ce que nous considérons comme le déploiement d’application J2EE global. Et force est de constater que:

Déployer va bien au delà d’un simple déploiement d’un EAR ou d’un WAR.
La plupart des applications ont également besoin d’autres artéfacts comme par exemple du contenu statique pour le serveur web ou encore des fichiers de configuration, utilisés par le code java, au démarrage.
Il faut également configurer des ressources JEE comme des Datasources JDBC ou des composants JMS (Queues, Topics, Servers).
A ceci s’ajoute, bien entendu, la configuration du middleware lui-même: création et configuration de clusters de serveurs d’application ou de virtual hosts d’un serveur Apache.
L’ordre d’exécution des tâches est important afin de réduire (voire de prévenir) la coupure de service de l’application pendant le déploiement et d’en augmenter la vitesse.

Alors posons nous la question. Que nous proposent les fournisseurs de serveurs d’application dans ce domaine ?

Oracle WebLogic Server

Oracle WebLogic Server propose un concept de ‘Deployment’: c’est la chose que vous créez quand vous déployez un EAR, un WAR ou un EJB Jar. Sic ! Vous pouvez l’adapter à l’environnement en fournissant un plan de déploiement. Cependant, rien n’est proposé pour regrouper plusieurs artéfacts JEE dans un seul déploiement ou inclure la création de ressources JEE telle qu’une Datasource.

Dans WebLogic, il y a le concept de ‘SubDeployement’ mais étrangement il n’est pas corrélé à un déploiement. C’est un mécanisme utilisé pour cibler des parties d’un module JMS vers des serveurs JMS ou des serveurs WebLogic. L’artifice proposé par les modules JMS semble destiné seulement à regrouper des ressources JMS. Sans doute qu’un jour un développeur l’a initialement appelé Déploiement sans se souvenir que le concept existait déjà dans WebLogic et il l’a alors renommé SubDeployement. Bien sûr, tout ceci n’est que supputation!

WebLogic propose un grand nombre d’API pour le déploiement: l’historique weblogic.Deployer en ligne de commande, la tâche ANT wldeploy et le WebLogic Scripting Tools, WLST pour les intimes, basé sur Python. Ce dernier est, je pense, le plus complet. Grâce à sa représentation sous forme de système de fichier de la hiérarchie des MBeans, il fournit un moyen très intuitif d’accéder à l’information.

JBoss Application Server

Le déploiement dans JBoss est géré par le Virtual Deployment Framework. C’est un framework basé sur des MBeans qui permet à différents artéfacts (EARs, WARs, EJB JARs, RARs, SARs …) et à différentes ressources (sources de données, paramètres JMS …) d’être déployés sur JBoss. Tout ceci est géré par leurs deployers.

Cependant, la plupart des gens n’invoque pas ces deployers, ni même ‘twiddle‘. Ils préfèrent simplement déposer leurs artéfacts dans le répertoire deploy/ de leur serveur d’application Jboss, puis attendre que le Deployment Scanner le détecte. Ils vérifient ensuite dans le fichier de log que le déploiement est terminé.

Le souci avec cette méthode : le déploiement n’est pas une opération atomique. Quand on automatise un déploiement, on ne veut redémarrer le serveur web qu’après un déploiement réussi du nouveau WAR. Mais écrire un bout de code qui analyse les logs du serveur à la recherche d’un mot clé est tout simplement moche. Une alternative serait de positionner la propriété ScanEnabled du DeploymentScanner à false d’invoquer manuellement le deployer. Non seulement cela complexifie le code, mais il faut également prévoir la copie des fichiers dans le répertoire deploy du serveur JBoss.

Ainsi, il s’avère qu’avec JBoss Application Server, il est difficile d’intégrer des déploiements vers ses serveurs dans un scénario de déploiement plus global. RedHat doit corriger ce problème au plus vite pour que JBoss soit réellement prêt pour les entreprises.

IBM WebSphere Application Server

Et pour le gros monstre JEE de chez ‘Big Blue’ ? Il offre une façon polyvalente et transactionnelle pour déployer des applications et des ressources. Globalement, le langage de script wsadmin permet de contrôler tous les aspects de WebSphere. Par exemple, vous pouvez synchroniser des nœuds explicitement et l’invocation de la méthode (par Jython ou JACL) pour déployer l’application ne rendra la main que lorsque l’opération sera réalisée. Le côté négatif est qu’il est beaucoup plus lent que l’outil similaire WLST proposé par WebLogic (les nombreuses copies de documents XML à travers SOAP doivent y être pour quelque chose) et les API proposées sont plutôt complexes à manipuler (qui peut donner la différences entre un containment path, un configuration id et un object name?)

Bien que WAS ne propose pas de mécanismes pour regrouper les différents artéfacts et ressources liés à un même déploiement, sa nature transactionnelle permet de commiter les différents changements de configuration en une fois. Il peut même gérer la configuration des instances des serveurs IBM HTTP Server ou Apache HTTP Server .

Malgré une vitesse de déploiement lente, rien ne vaut la fiabilité des déploiements de WebSphere !

Conclusion

Les serveurs d’application fournissent chacun un niveau de support différent pour prendre en charge les déploiements des applications d’entreprise. Bien sûr, ils offrent tous le déploiement basique des artéfacts Java EE mais aucun d’entre eux ne propose de regrouper différents artéfacts en un seul déploiement ou de lier des ressources Java EE à ces artéfacts. WebLogic Server est le seul qui essaye de regrouper des ressources (JMS Modules et SubDeployment). Mais ces abstractions ne couvrent qu’une petite partie de toute l’étendue du déploiement Java EE.

La répétition et la prédiction sont très importantes pour une stratégie de déploiement réussie, ce qui peut expliquer la prévisibilité de WebSphere sur le marché. Et finalement, une bonne API est nécessaire pour automatiser votre processus de déploiement: WebLogic et WebSphere l’offrent, JBoss a un sérieux manque dans ce domaine (même avec twiddle !)

Les consultants de Xebia et l’ensemble des développeurs chez XebiaLabs ont quasiment tous écrit dans leurs expériences passées des tonnes de scripts pour automatiser des déploiements et ont dû batailler sur ces questions encore et encore. Nous avons développé Deployit afin de prendre en charge ces différences entre serveurs d’applications et parce que nous croyons que l’automatisation des déploiements est de la plus haute importance du fait du nombre croissant de déploiements dans les entreprises.

–
Traduction libre du billet «Do application server vendors really understand deployment? » publié par Vincent Partington.

Booster vos recherches avec Oracle Coherence

Benoit Moussaud — Wed, 14 Oct 2009 08:36:24 +0000

Oracle Coherence est une solution de Data Grid. Elle permet de constituer des grilles de données à l’aide de 4 types de caches:

Cache distribué: l’ensemble des données est réparti sur les différents nœuds qui composent le cluster Coherence. Afin de garantir une bonne tolérance aux pannes, les données peuvent être sauvegardées sur un ou plusieurs nœuds du cluster. Cette typologie est extrêmement extensible : il suffit d’ajouter des nouveaux nœuds pour augmenter la capacité globale du cache.
Cache répliqué: l’ensemble des données est répliqué sur l’ensemble des nœuds du cluster. La modification d’une entrée sera propagée à l’ensemble des nœuds. Cette typologie permet d’offrir un accès très rapide en lecture car un seul nœud est sollicité dans l’opération. La contre-partie est que les opérations d’écriture sont lentes et que la taille du cache est indépendante du nombre de nœuds qui composent le cluster.
Cache local: les données sont conservées exclusivement sur la JVM.
Near Cache: il permet d’offrir le meilleur des caches de type ‘Répliqué’ (Performance) et de type ‘Distribué’ (Extensibilité) en fournissant un accès rapide aux données accédées le plus fréquemment et le plus récemment. Il est composé de 2 parties:

le ‘front-cache’ pour les accès locaux, de petite taille, typiquement un cache Local (Local Cache),
le ‘back-cache’ un cache de plus grande envergure, typiquement un cache distribué (Distributed Cache), qui contient l’ensemble des données avec leurs éventuelles sauvegardes.

Le point fort d’Oracle Coherence est de proposer la même API quelque soit le type de cache. Il est donc possible, par simple configuration, de modifier le type de cache et de l’adapter en fonction des besoins ou de l’environnement: cache local en « Développement », cache distribué en « Intégration », « Near » cache en « Production ».

En première approche, l’API d’Oracle Coherence est extrêmement simple : elle se résume à obtenir une Map et à la manipuler par les opérations habituelles: put(), get(), keySet(), entrySet()….

import com.tangosol.net.CacheFactory;
Map cache = CacheFactory.getCache("moncache");        //1. Récupération d'une instance de cache,
cache.put("benoit","moussaud");                       //2. Ajout d'un élément dans le cache
String name = (String)cache.get("benoit");            //3. Recherche par sa clé d'un élément dans le cache
assert name.equals("moussaud");

Le type de cache est déduit du nom du cache. Il est configuré dans le fichier coherence-cache-config.xml inclus dans coherence.jar. Par défaut, les règles suivantes sont appliquées:

Nom du cache	Type
`dist-*`	distribué
`near-*`	near cache
`repl-*`	repliqué
`local-*`	local
sinon	distribué

Si l’on veut appliquer ses propres règles, il faut définir son propre fichier de configuration et indiquer son emplacement au lancement de Coherence avec la propriété système tangosol.coherence.cacheconfig.

La suite de l’article va montrer comment interroger un cache Coherence autrement que par une clé dans une Map.

Un service de recherche de communes…

Prenons un service qui permet de rechercher l’ensemble des communes françaises en précisant le début de leur nom.

public interface CatalogService {
	public List getCommuneByName(String name);
}

Une implémentation classique est de créer une table ‘COMMUNE’ dans une base de données, d’y insérer les ensembles des communes de France (38206 dans mon exemple) avec leur libellé, un code postal et un code Insee, et d’effectuer la requête SQL SELECT ID, DEP_CODE, CODE_INSEE, LIBELLE FROM COMMUNE where LIBELLE like #name#.

Voici le résultat d’un benchmark du service avec pour paramètre la première lettre de la commune (de A à Z)

Benchmark Base de données

Le temps de réponse du service est mauvais et proportionnel au nombre de communes retournées

…Coherence à la rescousse…

La première idée est de placer le résultat de la recherche dans un cache avec pour clé le paramètre de recherche. Ce type de conception est efficace seulement si le nombre de filtres est fini, par exemple s’il résulte d’une sélection d’une combo-box dans une page web. Si la valeur du filtre est moins contrainte, le service sera appelé par un grand nombre de filtres différents et donc le cache risque d’être peu efficace (à moins de disposer d’une mémoire infinie de manière à conserver toutes les requêtes !).

La seconde idée est de charger dans un cache l’ensemble des communes et d’effectuer une recherche directement dans le cache. L’API Coherence offre la notion de Filter

public class CatalogServiceWithCoherence implements CatalogService,
     private final NamedCache cacheCommunes = CacheFactory.getCache("Commune");
     public List getCommuneByName(String name) {
         Filter filter = new LikeFilter("getName", name + "%", false);
         return performSearch(filter);
     }
     @SuppressWarnings("unchecked")
     private List performSearch(Filter filter) {
         Set entrySet=cacheCommunes
                 .entrySet(filter);
         List result = new ArrayList(entrySet.size());
         for (Map.Entry e : entrySet) {
             result.add(e.getValue());
         }
         return result;
     }
}

Appliquons le même benchmark.

Résultat du benchmark Coherence avec Filtre

Le temps de réponse du service est meilleur (autour de 500 ms) mais constant. Il y a donc un gain par rapport aux requêtes qui retournent beaucoup d’éléments (A,B,C,L,S,..) mais une perte sur les requêtes qui retournent peu d’éléments. Donc plus le filtre sera sélectif, moins la recherche dans le cache sera efficace.

Ceci se comprend mieux si on affine l’étude de l’API Coherence. L’interface Filter définit une seule méthode: evaluate

package com.tangosol.util;
public abstract interface Filter
{
  public abstract boolean evaluate(Object paramObject);
}

Donc une recherche dans le cache par filtre se résume à parcourir l’ensemble des entrées de la Map et à appliquer le filtre passé en paramètre.

…Encore plus rapide avec un index

Si on examine de plus près le filtre utilisé LikeFilter, on peut noter qu'il implémente l'interface IndexAwareFilter. Il est donc possible d'indexer le contenu d'un cache Coherence. Le code ci-dessous ajoute un index au cache "IndexedCommune": pour chaque entrée ajoutée au cache, il va extraire et indexer la valeur de la propriété "Name" (getName()).

NamedCache cache = CacheFactory.getCache("IndexedCommune");
cache.addIndex(new ReflectionExtractor("getName"), true, null);

Appliquons le benchmark.

Benchmark Coherence avec filtre indexé

Avec l'ajout de l'index, le temps de réponse du service a encore nettement chuté et reste proportionnel au nombre de communes retourné. Donc si le filtre est sélectif, le temps de réponse sera très bon.

En moyenne, la première solution a divisé le temps de réponse par 5, la seconde par 80. Cependant il faut garder à l'esprit qu'un accès à une valeur par son index (cache.get(key)) reste beaucoup plus performant que l'utilisation des Filters. Leurs utilisations doivent rester des exceptions.

Conclusion

Les solutions de "Data Grid" modernes comme Oracle Coherence offrent maintenant des services de haut niveau, semblables à ceux offerts par des SGBD, comme la gestion de la concurrence, des transactions, des indexs, du partitionnement, qui permettent d'améliorer nettement les performances d'une application J2EE.

Sources

Vous retrouverez l'ensemble des sources présentées dans ce billet dans le repository SVN de Xebia France.

Références

Stateful Aspects

Benoit Moussaud — Tue, 04 Aug 2009 09:30:49 +0000

L’AOP (Programmation Orientée Aspect) permet au sein d’un programme d’implémenter facilement des problématiques transversales, comme la gestion de transaction, les mécanismes de cache ou la sécurité. Généralement, le traitement de ces opérations est soit local à une méthode, soit sans état. Je vous propose dans cet article de vous montrer comment déclarer des aspects dont le cycle de vie n’est plus celui de la JVM (static) mais fonction d’un pointcut.

L’application témoin

Voici une magnifique application ayant la structure suivante : Application -> Manager -> DAO avec un modèle simple : Caddy -> * Item. Chaque run de l’application ajoute 10 items au Caddy et effectue un paiement. Le test case effectue 5 run().

package fr.xebia.aop.app;
import java.util.Random;
public class Application implements Runnable{
	static Random r = new Random();
	private CaddyManager  manager = new CaddyManager();
	public void run() {
		for (int i =0 ; i < 10; i++) {
			manager.addItem(new Item(i,"Item#"+i,r.nextInt(100)));
		}
		manager.purchase();
		manager.clearCaddy();
	}
}

Dans la suite de l’article nous allons écrire 2 aspects qui vont nous permettre de :

Connaître le nombre d’appels au DAO lors de l’appel à la méthode ‘purchase’.
Calculer la moyenne du prix des Item du Caddy.

Nombre d’appels au DAO

Utilisation d’un aspect ‘classique’

Le premier exemple va permettre de connaître le nombre d’appels au DAO lors de l’appel à la méthode ‘purchase’. Voici le code de la classe CaddyManager.

package fr.xebia.aop.app;
public class CaddyManager {
	private CaddyDAO dao = new CaddyDAO();
	private Caddy caddy = new Caddy();
	public void addItem(Item i) {
		caddy.add(i);
	}
	void purchase() {
		for (Item item : caddy.getItems()) {
			 dao.persist(item);
		}
	}
	public void clearCaddy() {
		caddy.clear();
	}
}

Dans une vision sans état, l’aspect peut être écrit comme ceci :

package fr.xebia.aop.aspects;
public aspect MonitorManager {
	pointcut onManager() : execution( fr.xebia.aop.app.CaddyManager.purchase(..));
	pointcut onDao() : execution(* fr.xebia.aop.app.CaddyDAO.persist(..));
	int managerCalls = 0;
	int daoCalls = 0;
	Object around() : onManager() {
		managerCalls++;
		try {
			return proceed();
		} finally {
			System.out
					.println(thisJoinPointStaticPart.getSignature()
							+ " managerCalls/daoCalls " + managerCalls + "/"
							+ daoCalls);
		}
	}
	before() : onDao() {
		daoCalls++;
	}
}

Lors de l’exécution du test, on obtient le nombre total des appels à purchase et à persist: l’effet ‘Aspect Sans Etat’

void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 2/20
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 3/30
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 4/40
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 5/50

Cet aspect ne répond donc pas à notre problématique : obtenir un nombre d’appels ‘hiérarchisé’ par appel à la méthode de plus haut niveau.

La solution : percflow

Il suffit de modifier légèrement l’aspect avec percflow pour modifier ses conditions de création:

public aspect MonitorManager percflow(onManager()) {
// code identique
}

Si un aspect A est défini avec l’instruction percflow(pointcut), alors une nouvelle instance de l’aspect est créée dès que le déroulement du code correspond au pointcut passé en paramètre. Dans notre exemple, avec l’ajout de percflow(onManager()) , la JVM va instancier l’aspect à chaque fois que le code exécutera CaddyManager.purchase()

L’exécution du test donne maintenant 10 appels au DAO par appel de la méthode purchase

void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10

L’exemple est ici trivial mais ce type d’aspect placé sur une application J2EE qui aurait mal vieillie peut permettre d’en extraire les principaux chemins d’exécution.

Prix Moyen des articles

Utilisation d’un aspect ‘classique’

Le second exemple va permettre de calculer la moyenne du prix des Item du Caddy. Voici le code de l’aspect sans état: à chaque appel à la méthode Cadd.add(), le prix total et le nombre d’articles est incrémenté. L’exécution de la méthode Caddy.clear() affiche le résultat et remet à zéro les variables.

public aspect MonitorItems  {
	private int total = 0;
	private int nb = 0;
	after(Item i) returning() : execution(* Caddy.add(Item)) && args(i) {
		total +=i.getPrice();
		nb ++;
	}
	before(): execution(* Caddy.clear()) {
		System.out.println(" Caddy items("+nb+"), average price ("+total/nb+")");
		total = 0;
		nb = 0;
	}
}

L’exécution de l’application donne un résultat correct dans sa version mono-threadée. Dans une version multi-threadée (qui se rappoche d’un serveur d’application J2EE), l’application échoue avec un message erroné (50 items au lieu de 10) suivie d’une exception:

Caddy items(50), average price (47)
Caused by: java.lang.ArithmeticException: / by zero
	at fr.xebia.aop.aspects.MonitorItems.ajc$before$fr_xebia_aop_aspects_MonitorItems$2$6dfa1e74(MonitorItems.aj:17)
	at fr.xebia.aop.app.Caddy.clear(Caddy.java:20)
	at fr.xebia.aop.app.CaddyManager.clearCaddy(CaddyManager.java:21)
	at fr.xebia.aop.app.Application.run(Application.java:16)

L’ensemble des threads partagent le même aspect, et donc les mêmes attributs. Un des thread effectue la mise à zéro l’attribut de nb pendant l’exécution du pointcut before() et lorsqu’un second thread veut effectuer la moyenne, une division par zéro arrive et provoque l’exception.

La solution : perthis

La solution est d’indiquer qu’il faut créer un nouvelle instance de l’aspect à chaque nouvelle instance de la classe Caddy. Si un aspect A est défini avec perthis(pointcut), alors une nouvelle instance de l’aspect est créée pour chaque objet qui exécute (this), le pointcut passé en paramètre. L’instruction pertarget(pointcut) existe également.

public aspect MonitorItems perthis (execution(Caddy.new(..))) {
// code identique
}

L’exécution du test donne maintenant un résultat correct (le prix moyen des 10 objets) en mode mono-thread et multi-thread.

ApplicationTest.testSameInstanceMT()
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
 Caddy items(10), average price (66)
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
 Caddy items(10), average price (50)
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
 Caddy items(10), average price (49)
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
 Caddy items(10), average price (51)
void fr.xebia.aop.app.CaddyManager.purchase() managerCalls/daoCalls 1/10
 Caddy items(10), average price (51)

Vous retrouverez l’ensemble des sources présentées dans ce billet dans le repository SVN de Xebia France.

Référence :

Aspects, Appendix B. Language Semantics

Prenez le contrôle de Confluence avec Swizzle

Benoit Moussaud — Tue, 16 Dec 2008 10:22:58 +0000

Je vais vous révéler un secret à propos de notre célèbre Revue de Presse ! Elle est élaborée collectivement par l’ensemble des consultants de Xebia sous Confluence avant d’être publiée sur notre blog. L’utilisation d’un wiki permet de suivre facilement les différentes modifications (contribution, corrections, commentaires). Une fois celle-ci terminée, la page est archivée et une autre est créée, vide, afin de recevoir la prochaine version. La fin de l’année arrive, c’est l’heure de faire les statistiques 2008. L’une des questions que je me pose est « Quelle est la proportion des entrées de la revue de presse entre les différentes catégories (Actualité éditeurs / SSII, Agilité, RIA, SOA, …) ? »

Solution N°1 : Ouvrir dans le navigateur toutes les pages ‘Revue de Presse’ une par une et compter les entrées. Une revue de presses par semaine, 52 semaines … non

Solution N°2 : Utiliser une API. En effet Confluence expose ses principales fonctions par web services. Voici le wsdl. Plus de 7300 lignes, 238 opérations, 50 types. À ce moment-là, j’étais presque prêt à repasser à la solution N°1 quand je suis tombé au détour d’une recherche Google (Google est notre ami à tous !), sur le projet Swizzle…

Swizzle est un wrapper Java autour de l’api XML-RPC proposée par Confluence.

Installation

Rapide ! Swizzle est disponible dans le repository Maven


    org.codehaus.swizzle
    swizzle-confluence
    1.1

Principe

Une seule classe, org.codehaus.swizzle.confluence.Confluence, permet d’accéder aux différents services.
Un ensemble de POJO qui servent de paramètres d’entrée et de retour. Exemple : org.codehaus.swizzle.confluence.PageSummary.

Se connecter

String endpoint = "https://the.confluence.of.xebia.com/confluence/rpc/xmlrpc";
confluence = new Confluence(endpoint);
System.out.println("Connected to " + endpoint);
String username = "bmoussaud";
String password = "tiger";
confluence.login(username, password);

Si vous êtes dérrière un proxy, initialiser les variables d’environnement suivantes:

System.getProperties().put("proxySet",  "true");
System.getProperties().put("proxyHost", "17.240.34.194");
System.getProperties().put("proxyPort", "3128");

Retrouver une page

Les Revues de Presse sont archivées, comme l’ensemble du blog, par trimestre. Il faut donc :

Retrouver la page correspondant à ce trimestre.
Récupérer les pages filles.
Filtrer pour ne garder que les articles « Revue de Presse ».

public List getRevuesDePresse(String quarter) throws Exception {
	List results = new ArrayList();
	Page page = confluence.getPage("Espace Xebia France", quarter); 	//#1
	List children = confluence.getChildren(page.getId());	//#2
	for (PageSummary pageSummary : children) {
		if (pageSummary.getTitle().contains(REVUE_DE_PRESSE)) {		//#3
			results.add(pageSummary);
		}
	}
	return results;
}

Une page est identifiée par son Id représenté par un type java.lang.String.
La classe PageSummary contient les informations minimales d’une page : Id, ParentId, Title, URL.
La classe Page contient toutes les informations de la page, y compris son contenu.

Analyser le contenu d’une page

La Revue de Presse contient 6 catégories principales (Actualité éditeurs / SSII, Agilité, RIA, SOA, …). Elles sont hiérarchisées en niveau 3 (syntaxe wiki h3.). Les différentes entrées de la revue de presse sont de niveau 4 (syntaxe wiki h4.). Il faut donc :

Récupérer le contenu de la page.
Filtrer les titres de niveau 3 et 4.
Effectuer le comptage.

public Map countArticleByCategory(String pageId)
		throws Exception {
	String content = confluence.getPage(pageId).getContent();	// #1
	String currentCategory = null;
	String currentEntry = null;
	Pattern h3h4 = Pattern.compile("(^h3|^h4)
.(.*)",
					 Pattern.MULTILINE);		// #2
	Matcher matcher = h3h4.matcher(content);
	Map categories = newMap();
	while (matcher.find()) {
		//entrées vides
		if (matcher.group().contains("...")
				|| matcher.group().contains(".."))
			continue;
		// niveau 3
		if ("h3".equals(matcher.group(1))) {			// #2
			currentCategory = matcher.group(2).trim();
			categories.put(currentCategory, 0);
			continue;
		}
		// niveau 4
		if ("h4".equals(matcher.group(1))) {			// #2
			currentEntry = matcher.group(2);
			if (currentCategory != null
					&& categories.containsKey(currentCategory)) {
				int c = categories.get(currentCategory);
				categories.put(currentCategory, ++c);	// #3
			}
		}
	}
	return categories;
}

Conclusion

Il suffit maintenant :

D’assembler les deux méthodes.
De dumper les informations au format CSV.
D’ouvrir Excel.
De construire un tableau croisé dynamique.

et vous n’aurez pas les résultats !!

Pour en revenir à Swizzle / Confluence : l’encapsulation proposée est correcte et performante. Le seul point négatif : toutes les méthodes de la classe Confluence lancent des java.lang.Exceptions, non typées. Elles sont dans l’ensemble le résultat d’un comportement de type Runtime. J’aurais donc préféré une signature finissant par throws RuntimeException.

L’api permet également :

D’obtenir des informations sur l’historique des pages et des contributeurs, les commentaires, l’état de la page (nombre de verrous, supprimées, …).
De créer, déplacer et détruire des pages et des espaces.

Exemple : archivage des revues de presse :

void run(String newParent) throws Exception {
	System.out.println("Archivage des Revues de Presse dans "+newParent);
	myConfluence = new MyConfluence();
	List draftedRevuesDePresse = myConfluence.getDraftedRevuesDePresse();
	int count = 0;
	for (PageSummary pageSummary : draftedRevuesDePresse) {
		if (pageSummary.getTitle().startsWith("DRAFT"))
			continue;
		myConfluence.moveTo(pageSummary,newParent);
	}
	System.out.println("Total "+count);
}
//....
public void moveTo(PageSummary pageSummary, String newParent)
		throws Exception {
	Page targetPage = confluence.getPage("XF", newParent);
	Page page = confluence.getPage(pageSummary.getId());
	System.out.println("Change Parent from '"
			+ confluence.getPage(page.getParentId()).getTitle() + "' to '"
			+ targetPage.getTitle() + "'");
	page.setParentId(targetPage.getId());		//Changement de Parent
	confluence.storePage(page);			//Applique les modifications
}

Swizzle propose également un wrapper sur les API exposées par Jira.
Note: Swizzle ne fonctionne que si l’option « API à distance (XML-RPC & SOAP) » est activée.

Analyse mémoire d’une JVM

Benoit Moussaud — Thu, 27 Nov 2008 13:04:40 +0000

Mardi, 10 heures
- La production « Allo, le projet, depuis 10 minutes on voit passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez-la valeur de l’option -Xmx «

Mardi, 13 heures
- La production « Allo, le projet, depuis 5 minutes on voit encore passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez encore la valeur de l’option -Xmx «

Mardi 18 heures
- La production « Allo, le projet, depuis 2 minutes on voit passer encore des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Tut, tut, tut,….. »
- La production « Plus d’équipe projet, la nuit va être longue… »

Cette petite scène est un classique, un air de déjà-vu mais que faire ? Si votre application a déjà subi une batterie de tests techniques, augmenter la mémoire est rarement la bonne solution. La scène décrite ci-dessus laisse penser à ce que l’on appelle classiquement une Fuite Mémoire (Memory Leak). En réalité, avec les JVM récentes, la fuite mémoire n’existe pas, je préfère parler d’accumulation d’objets non désirés. Cet article va vous montrer comment débusquer cette accumulation avec les outils jmap, jhat et Eclipse Memory Analyser

jmap

jmap est l’outil qui permet d’effectuer des photographies de la mémoire d’une JVM. Deux options sont particulièrement intéressantes : l’histogramme et le dump.

L’histogramme

L’option -histo permet d’obtenir un histogramme de la mémoire de la JVM. Les informations suivantes sont affichées pour chacune des classes Java :

son nom complet
le nombre d’objets et
la taille de la mémoire occupée en octets

L’ensemble est trié par taille mémoire décroissante. Attention, la demande d’un histogramme implique automatiquement un Full GC de la mémoire de la JVM.

Exemple :

jmap -histo 
 num     #instances         #bytes  class name
----------------------------------------------
   1:         41202       27502288  [C
   2:          2304        1332520  [I
   3:         37934         910416  java.lang.String
   4:          5130         503632  
   5:          5130         412968  
   6:         12348         395136  fr.xebia.memory.bean.Person
   7:         12846         308304  java.util.concurrent.ConcurrentHashMap$HashEntry
   8:          7650         285656  
   9:         12518         200288  java.lang.Long
  10:           349         189184  
  11:           349         138704  
  12:           327         132144  
  13:            38         115456  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
  14:           414          76392  [B
  15:           422          40512  java.lang.Class
  16:           556          32656  [[I
  17:           518          32056  [S
  18:            44          14080  
  19:           315          13480  [Ljava.lang.Object;
  20:           576           9216  java.lang.StringBuffer
.....
 184:             1              8  java.lang.System$2
 185:             1              8  java.io.File$1
 186:             1              8  java.lang.Terminator$1
Total        142211       32693376

Que peut-on en déduire ?

Les premières places sont souvent trustées par les objets de base ( java.lang.String, java.lang.Object, java.lang.class) et leur déclinaison en collections (java.util.* et les tableaux, symbolisé par des '['). Si vous retrouvez des classes de votre application dans le top 20, elles deviennent suspectes. Dans notre exemple, l'histogramme montre que la classe 'fr.xebia.memory.bean.Person' est instanciée 12348 fois pour une occupation mémoire de 308304 octets. Elle est suivie de près par des entrées d'une ConcurrentHashMap (java.util.concurrent.ConcurrentHashMap$HashEntry)
L'obtention de cet histogramme est extrêmement rapide ~~et perturbe peu la JVM (au Full GC près ;~~) ). Il est donc possible d'en faire régulièrement (exemple toutes les 'n' secondes) et d'en déduire ainsi des tendances : nombre d'instances d'une classe qui augmente, taille des instances d'une classe qui diminue, ...

Note : avec les JVM en version 1.4.2, il est possible d'obtenir également un histogramme à chaque thread dump en ajoutant l'option -XX:+PrintClassHistogram au démarrage de la JVM. Comme pour jstat -histo, cette option implique automatiquement un Full GC de la mémoire de la JVM.

L'histogramme permet de connaître les classes qui occupent le plus de mémoire, il n'indique pas qui les a allouées.

Le dump

L'histogramme c'est bien, mais ce n'est pas suffisant : il est parfois nécessaire d'obtenir un dump complet de la mémoire afin de déterminer précisément la chaîne de référencement.

L'outil jmap permet également d'effectuer un dump complet et binaire de la mémoire d'une JVM. Deux remarques importantes :

pendant la durée du dump, plus rien ne s'exécute dans la JVM, tous les threads sont stoppés, qu'ils soient applicatifs ou systèmes.
la durée du dump est proportionnelle à la taille de la mémoire occupée et fonction de la taille de la mémoire restante (il faut un peu de mémoire libre pour exécuter le traitement du dump !). Exemple: la durée d'un dump d'une JVM avec un heap de 1 Go à la limite de la saturation mémoire se compte en minute !

Exemple : création d'un dump

jmap -dump:format=b,file=c:tempheap.bin 
Dumping heap to c:tempheap.bin ...
Heap dump file created

Note : L'option -XX:+HeapDumpOnOutOfMemoryError indique à la JVM d'effectuer un heap dump en cas d'OutOfMemoryError. Le fichier est généré dans le répertoire de lancement de la JVM.

Vous voilà l'heureux propriétaire d'un fichier binaire de plusieurs centaines de méga-octets. Comment en extraire des informations ? C'est là que le compagnon de jmap rentre en jeu : jhat.

jhat

jhat est un analyseur de dump mémoire. C'est en réalité un serveur web, comme le montre l'exemple ci-dessous.

D:ProjetsMesProjetsMemoryLeakjmap5968>jhat heap5968.bin
Reading from heap5968.bin...
Dump file created Mon Nov 24 13:03:54 CET 2008
Snapshot read, resolving...
Resolving 118955 objects...
Chasing references, expect 23 dots.......................
Eliminating duplicate references.......................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

L'application jhat lancée, il suffit de lancer un navigateur web pour commencer l'exploration du dump.

[ MODE PLEIN ECRAN ]

Grâce à jhat, on a pu voir que les instances de type fr.xebia.memory.bean.Person étaient majoritairement référencées par un champ statique de type fr.xebia.memory.dao.MySuperSmartCache qui fait office de cache. Sans rentrer dans le code, on peut commencer à avoir des doutes sur l'efficacité de ce cache !

jhat a l'avantage d'être disponible dans tous les JDK récents. Cependant, l'interface proposée permet certes de naviguer facilement de classe en classe, d'instance en instance, mais il manque de fonctions d'analyse. Un outil est venu combler ce manque...

Eclipse Memory Analyzer

Eclipse Memory Analyzer (MAT) est un sous projet de la fondation Eclipse, initié par la société SAP. Son but est non seulement d'offrir une interface graphique permettant de naviguer dans un dump mémoire, mais également de proposer des rapports d'analyses précablés (Leak Suspects, Heap Dump Overview, Top Consumers,...).

Ouvrons le dump avec MAT. Après analyse, MAT ouvre une fenêtre avec une vue d'ensemble de la mémoire. Il est clair que l'ensemble de la mémoire est retenu par une seule instance de type fr.xebia.memory.dao.Loader.

La vue histogramme ressemble à celle fournie par jmap ou jhat mais avec des libellés un peu plus clairs.

Une fonction très intéressante, le 'Dominator Tree' donne la liste des plus gros objets, consolidée avec l'ensemble de leurs références.

Pour terminer, jetons un coup d'œil sur le rapport 'Leak Suspect', et là il n'y a plus de doute, nous avons trouvé le coupable.

Conclusion

Avec ces outils de capture et d'analyse de la mémoire, il est maintenant facile de débusquer les consommations mémoires excessives, même dans un environnement de production. N'hésitez pas à user et à abuser de ces outils afin de déterminer au plus tôt les tailles des JVM et les éventuelles accumulations d'objets non désirés !

Diagnostic d’une JVM à distance

Benoit Moussaud — Wed, 22 Oct 2008 08:28:07 +0000

Développer une application Java, c’est bien. La rendre performante, c’est mieux.

Cependant, qui dit « performance », dit « mesure ». En effet, il est nécessaire de pouvoir :

connaître les paramètres de lancement de la JVM,
mesurer l’empreinte mémoire et le comportement du Garbage Collector,

Cet article va décrire dans une première partie les différents outils permettant de collecter ces informations en local. La seconde partie se concentre sur les moyens pour obtenir ces mêmes informations à distance.

En local…

Au fur et à mesure des différentes versions et afin d’obtenir les meilleures performances, la machine virtuelle Java (JVM) s’est dotée d’outils de diagnostic. Les principaux sont:

jps liste l’ensemble des JVM qui s’exécutent sur un système.

#jps -l
22791 weblogic.Server
18602 sun.tools.jps.Jps
5697 weblogic.Server
16937 activity.jar
6324 weblogic.Server

jstat affiche les statistiques d’une JVM sur sa gestion mémoire et le compilateur JIT.

#jstat -gcutil 16937 1s
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
  0.00  99.96   0.00  89.53  33.10   1274   71.231   194   69.937  141.167
 83.53   0.00  65.48  77.26  33.10   1275   71.285   194   70.610  141.895
 83.53   0.00  75.30  77.26  33.10   1275   71.285   194   70.610  141.895
 83.53   0.00  84.44  77.26  33.10   1275   71.285   194   70.610  141.895
 83.53   0.00  96.26  77.26  33.10   1275   71.285   194   70.610  141.895
  0.00  99.77   0.00  90.35  33.10   1276   71.391   195   70.610  142.001
  0.00   0.00   4.87   0.73  33.11   1276   71.391   195   70.749  142.140
  0.00   0.00  10.18   0.73  33.11   1276   71.391   195   70.749  142.140
  0.00   0.00  29.65   0.73  33.11   1276   71.391   195   70.749  142.140

jconsole est une application graphique Swing qui affiche des informations sur la mémoire, les threads, les classes et les MBeans.

visualvm est également une application graphique qui reprend les informations affichées par JConsole mais en allant plus loin (ex: Détection de Contentions Thread). Livré avec le JDK de sun depuis la version JDK 6 update 7, VisualVM pourrait avec le temps remplacer complètement JConsole

visualgc affiche sous forme graphique les informations que l’on peut obtenir sur le garbage collector avec jstat. cette application n’est pas packagée avec la jvm, elle est disponible séparément avec les outils jvmstat. de plus, elle fonctionne avec les jvm 1.4.

Et à distance … ?

Par défaut, tous ces outils doivent être lancés sur la système d’exploitation où s’exécute la JVM à diagnostiquer. Cependant les contraintes de sécurité des entreprises interdisent parfois d’accéder physiquement à la machine. Dans le meilleur des cas, il est possible d’obtenir une connexion distante (Windows RDP, Telnet ou SSH), mais souvent avec des niveaux d’accréditations trop faibles pour pouvoir exécuter les commandes listées ci-dessus. Alors comment faire ?

Sun a pensé à tout. Si on regarde de prés une distribution d’une JVM, on remarque un binaire de type démon ‘jstatd’.

jstatd est un démon qui surveille la création et la destruction des JVM et fourni une interface qui permet à des outils distants de se connecter aux JVM qui s’exécutent sur la machine. Exactement ce qu’il nous faut, non ?

Le moyen le plus simple est d’exécuter jstatd de la façon suivante:

#nohup jstatd -J-Djava.security.policy=all.policy &
#cat all.policy
grant codebase "file:${java.home}/../lib/tools.jar" {
   permission java.security.AllPermission;
};
#

A partir de ce moment, il est possible d’utiliser les logiciels présentés ci-dessus.

jps, en précisant le nom de la machine distante. Noter l’apparition d’un nouveau processus java: sun.tools.jstatd.Jstatd

D:xebia-blog>jps -l myremoteserver
5697 weblogic.Server
28636 sun.tools.jstatd.Jstatd
22791 weblogic.Server
29726 activity.jar
6324 weblogic.Server

jstatd et visualgc en précisant le virtual machine identifier avec le format lvmid@servername

D:xebia-blog>jstat -gcutil 29726@myremoteserver 1s
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
  0,00  99,78   0,00  83,38  33,14   8476  474,694  1227  445,801  920,495
  0,00  99,78   0,00  83,38  33,14   8476  474,694  1227  445,801  920,495
  0,00  78,41  77,46  42,98  33,14   8478  474,784  1227  446,133  920,917
 79,47   0,00  43,86  78,69  33,14   8481  474,971  1227  446,133  921,104
  0,00  82,64  76,48  63,39  33,13   8484  475,206  1228  446,649  921,855
  0,00  82,64  76,48  63,39  33,13   8484  475,206  1228  446,649  921,855
 85,47   0,00  77,78  74,92  33,13   8485  475,350  1228  446,649  921,999

Au lancement de visualvm, il suffit d’ajouter le nom du serveur ‘myremoteserver’ au noeud remote pour voir apparaître l’ensemble des JVM s’exécutant sur ce serveur. Il est possible alors de se connecter à l’une des machines virtuelles pour pouvoir avoir accès à:
Onglet Overview donne des informations générales (PID, Host, JVM Version, JVM Flags)

Onglet Monitor affiche des graphiques sur la consommation de ressources (Mémoire, Threads, …)

La copie d’écran suivante montre visualgc intégré sous forme de plugin dans visualvm

Cependant l’utilisation seule de jstatd n’est pas suffisante si l’on veut avoir accès aux MBeans JMX par jconsole et à l’activité des Threads avec visualvm. Il est nécessaire d’ajouter les paramètres suivants au démarrage de la JVM

-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

il est alors possible de connecter jconsole en utilisant la commande suivante:

D:xebia-blog>jconsole myremoteserver:9999

Avec l’outil visualvm, deux nouveaux onglets sont maintenant disponibles:

Onglet Threads affiche l’activité de l’ensemble des threads et permet d’obtenir facilement un thread dump

Onglet MBeans affiche l’ensemble des MBeans JMX

Conclusion

Vous êtes maintenant armés pour scruter votre application qui s’exécute dans votre JVM. Vouloir rendre votre application performante est une bonne idée. Cependant, l’expérience montre qu’il faut commencer absolument par analyser le code Java.
Exemple: Traitements inutiles ou redondants, accès à la base de données peu efficaces (trop ou pas assez de données manipulées),…
Il n’existe pas de paramètre magique dans la JVM (ou dans le Serveur d’application) qui permet à une application mal écrite de devenir performante.

Ce n’est que par la suite que l’on peut tuner la JVM. Si vous vous lancez dans cette aventure (passionnante) commencez par lire cet article de Kirk Pepperdine ,
My advice on JVM heap tuning, keep your fingers off the knobs!

fr.xebia.concurrent.CyclicLatch

Benoit Moussaud — Wed, 24 Sep 2008 09:03:44 +0000

….ou comment effectuer un traitement régulièrement

Avec l’arrivée de l’api java.util.concurrent dans le JDK 5, la programmation concurrente est à la portée de tous. Auparavant, il fallait :

soit être un expert des APIs de bas niveau et être prêt à passer des nuits blanches à mettre au point le système,
soit se tourner vers les serveurs d’applications J2EE et leur implémentation JMS et EJB Message Driven Bean. Dans ce cas-là, la lourdeur de l’API JMS et les contraintes de persistance et de transaction (par défaut) des serveurs JMS viendront mettre à mal au final l’utilisation de traitements parallèles et concurrents.

Dans le cadre d’un de mes projets, j’ai eu besoin d’implémenter le comportement suivant :

les producteurs, N Threads effectuent une tâche qui entre autres collecte des données.
le consommateur, 1 Thread collecte ces données pour les agréger.

Dans un premier temps, je me tourne vers une java.util.concurrent.BlockingQueue partagée entre les producteurs et le consommateur. Cette conception fonctionne jusqu’au moment où je me suis aperçu que

le traitement effectué par mon consommateur pouvait être long et coûteux en ressources : il faut donc éviter d’effectuer le traitement au fil de l’eau et attendre d’avoir un certain nombre de données dans la file.
les producteurs, suivant la vie de l’application, pouvaient à un instant donné être très nombreux (beaucoup de données en peu de temps) ou au contraire peu nombreux. Dans ce dernier cas, le remplissage de ma file prendrait des heures et je ne pouvais attendre cette condition pour lancer mon traitement.

Cahier des charges

Je me suis donc fixé le cahier des charges suivant :
Le consommateur doit vider l’ensemble de la queue et effectuer le traitement si :

au moins N éléments ont été déposés (cf 1.)
S secondes se sont écoulées depuis la dernière collecte (cf 2.)

J’ai commencé, bien sûr, par examiner l’API java.util.concurrent. Deux éléments de synchronisation ont attiré mon attention sans réellement convenir à mon besoin.

java.util.concurrent.CountDownLatch permet de signaler à un ensemble de threads que N opérations sont terminées.
java.util.concurrent.CyclicBarrier permet à un ensemble de threads de s’attendre à un point d’exécution donnée.

J’ai décidé de mixer les deux pour écrire fr.xebia.concurrent.CyclicLatch

Utilisation

Une instance de la classe fr.xebia.concurrent.CyclicLatch est créée avec les paramètres suivants :

une valeur N qui indique le nombre de fois avant de que le Latch ne soit libéré
une valeur S qui indique le timeout

// création d'un CyclicLatch avec N=100 et S=10 secondes
latch = new CyclicLatch(100, 10, TimeUnit.SECONDS);

Cette instance est partagée entre les producteurs et le consommateur.

A chaque traitement terminé, chaque producteur va décrémenter le Latch.

public class Producer {
	public void doit() {
		//Perform its own business...
		latch.countDown();
	}
}

Le consommateur va se mettre en attente du latch

public class Consummer {
	public void run() {
		while (true) {
			latch.await() // attente avec les valeurs par défauts
			//ou
			latch.await(30,TimeUnit.Secondes) // attente de 30 secondes
			// Perform its own business....
		}
	}
}

Implémentation

La classe CyclicLatch est implémentée autour

d’un attribut de type CountDownLatch

final public class CyclicLatch {
	private final int initialcount;
	private CountDownLatch latch;
	private final ReentrantLock lock = new ReentrantLock();
	public CyclicLatch(int initialcount) {
		this.latch = new CountDownLatch(initialcount);
	}
}

de 2 méthodes, countDown() et await().

La méthode countDown() verrouille l’accès au latch et délègue au CountDownLatch.

	public void countDown() {
		try {
			lock.lock();
			latch.countDown();
		} finally {
			lock.unlock();
		}
	}

La méthode await() délègue au CountDownLatch.await(long, TimeUnit)
Extrait de javadoc : Causes the current thread to wait until the latch has counted down to zero, unless the thread is interrupted or the specified waiting time elapses.

Et ensuite effectue reset safe du CountDownLatch

	public boolean await(long timeout, TimeUnit unit)
			throws InterruptedException {
		log("Waiting for latch of "+this.initialcount+"  & " + timeout + " seconds timeout");
		boolean result = latch.await(timeout, unit);
		/* Reset Latch, on timeout & on overflow */
		try {
			lock.lock();
			log("Reset Latch...." + latch);
			latch = new CountDownLatch(initialcount);
		} finally {
			lock.unlock();
		}
		return result;
	}

L’implémentation complète du CyclicLatch permet de fixer les paramètres de taille et de timeout (méthode await()) ou à chaque attente du consommateur de positionner un nouveau timeout (méthode {{await(long, TimeUnit)}})

Tests

Dans le repository de Xebia-France, vous trouverez le code complet du CyclicLatch et un exemple de mise en œuvre avec la classe fr.xebia.xke.concurrency.NProducers1ConsumerTimedTest. Cette classe crée 4 producteurs qui remplissent une BlockinQueue. Le consommateur doit lire les messages en utilisant bien sûr un CyclicLatch. Suivant le paramétrage du latch on obtient les comportements suivants :

CyclicLatch taille 100, time out 30 secondes. Les traces, ci-dessous, montre que le latch a été déclenché sur ‘Overflow’ donc plus de 100 messages dans la file, au bout d’environs 2.5 secondes

main Consumer.Consumer()
MyBasket.start()
Thread Consumer #0 Consumer.run()
Thread Consumer #0 Waiting for latch of 100  & 5 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@45a877[Count = 0]
Thread Consumer #0 OverFlow, 2.4278326s
Thread Consumer #0 messages #100
Thread Consumer #0 Waiting for latch of 100  & 5 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@126b249[Count = 0]
Thread Consumer #0 OverFlow, 2.5149238s
Thread Consumer #0 messages #100
Thread Consumer #0 Waiting for latch of 100  & 5 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@182f0db[Count = 0]
Thread Consumer #0 OverFlow, 2.5150535s
Thread Consumer #0 messages #100
Thread Consumer #0 Waiting for latch of 100  & 5 seconds timeou
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@192d342[Count = 0]
Thread Consumer #0 OverFlow, 2.5142925s
Thread Consumer #0 messages #100
Thread Consumer #0 Waiting for latch of 100  & 5 seconds timeout
10062 main done
MyBasket.stop()

CyclicLatch taille 100, time out 2 secondes. Les traces, ci-dessous, montrent qui le latch a été déclenché maintenant sur timeout avec une file qui contient environ 80 messages.

main Consumer.Consumer()
MyBasket.start()
Thread Consumer #0 Consumer.run()
Thread Consumer #0 Waiting for latch of 100  & 2 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@45a877[Count = 20]
Thread Consumer #0 TimeOut,  2.0013237s
Thread Consumer #0 messages #80
Thread Consumer #0 Waiting for latch of 100  & 2 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@126b249[Count = 20]
Thread Consumer #0 TimeOut,  2.000778s
Thread Consumer #0 messages #80
Thread Consumer #0 Waiting for latch of 100  & 2 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@182f0db[Count = 20]
Thread Consumer #0 TimeOut,  2.0010734s
Thread Consumer #0 messages #80
Thread Consumer #0 Waiting for latch of 100  & 2 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@192d342[Count = 20]
Thread Consumer #0 TimeOut,  2.0014079s
Thread Consumer #0 messages #80
Thread Consumer #0 Waiting for latch of 100  & 2 seconds timeout
Thread Consumer #0 Reset Latch....java.util.concurrent.CountDownLatch@6b97fd[Count = 20]
Thread Consumer #0 TimeOut,  2.001409s
Thread Consumer #0 messages #80
Thread Consumer #0 Waiting for latch of 100  & 2 seconds timeout
10078 main done
MyBasket.stop()

Conclusion

La programmation concurrente est vraiment passionnante, mais il faut absolument devenir paranoïaque. En effet, il faut envisager tous les cas possibles: chaque instruction doit être envisagée comme pouvant être interrompue. Le simple conseil que je vous donnerais est de commencer par synchroniser toutes les sections critiques (mot-clé synchronized). Ensuite, et après réflexion et bench, vous pourrez passer à des verrouillages de plus bas niveau si nécessaire (les JVM modernes ont fait d’énormes progrès dans ce domaine!)

Depuis que j’ai implémenté cette classe pour un projet et un besoin précis, je trouve régulièrement un nouveau cas d’utilisation. Le dernier en date est l’affichage dynamique dans une application Swing de graphes JFreeChart d’un très grand nombre de valeurs en fonction du temps.

Et vous, que ferez-vous du CyclicLatch ?

WebLogic Persistent Store

Benoit Moussaud — Wed, 06 Aug 2008 06:43:48 +0000

Le serveur d’applications Weblogic permet de déclarer des serveurs JMS. À chaque serveur JMS est associé un Persistent Store, emplacement destiné à persister les messages JMS en cas d’interruptions de service entre la publication d’un message et sa consommation. Deux supports possibles :

File Persistence Store, un répertoire accessible par le serveur Weblogic composé d’un ou plusieurs fichiers de structures binaires (.DAT)
JDBC Persistence Store, ensemble de tables contenues dans une base de données relationnelle et accessible à travers une ‘DataSource’. La structure des tables et leur contenu sont exclusiment gérés par le serveur d’applications.

Le choix de l’un des deux types de stockage est principalement dicté par des contraintes d’architecture et d’exploitation; les avantages de l’un sont les inconvénients de l’autre.

Jusqu’à la version 8 de Weblogic, il était impossible de pouvoir les administrer, en particulier pouvoir les ouvrir, analyser ou dumper leur contenu.

À partir de la version 9, le serveur d’applications propose un outil : weblogic.store.Admin

java -classpath ${WLS_DIR}/servir/lib/weblogic.jar weblogic.store.Admin

Les commandes principales sont : open, dump et compact.

Open

La première opération à effectuer est de se connecter au Persistent Store, soit par openfile, soit par openjdbc. Le reste des commandes resteront identiques vis-à-vis du type de store.
storeadmin-> openfile -store FileStore_auto_1 -dir FileStore_auto_1 INFO: Store FileStore_auto_1 opened successfully storeadmin->list INFO: Currently open stores : FileStore_auto_1 storeadmin->

Dump

Cette commande permet d’obtenir le contenu du store et de le transférer dans un fichier
storeadmin-> dump -store FileStore_auto_1 -out /tmp/dump_FileStore_auto_1.log INFO: Dump from FileStore_auto_1 to /tmp/dump_FileStore_auto_1.log.xml successful

Le contenu du fichier indique le nombre total de messages, le nombre de création, lecture, mise à jour et suppression avec le détail par connexion.

Il existe une option à la commande dump qui permet d’avoir non seulement les statistiques, mais également le contenu des éléments, ici les messages JMS
storeadmin->dump -store FileStore_auto_1 -out /tmp/dump_FileStore_auto_1.log.deep -deep INFO: Dump from FileStore_auto_1 to /tmp/dump_FileStore_auto_1.log.deep.xml successful
Attention : la taille de ce fichier peut être extrêmement importante, c’est une projection XML de données stockées en mode binaire !


  
    0
    0
    0
    0
    0
  
  
    
          0: 0001 0000 0101 0000 0000 0000 0006 0000   ................
   16: 0000 0000 ba74 0000 0000 0005 0801 0000   .....t..........
   32: 0000 0017 e64a 0000 0000 0000 1bce 7fff   .....J..........
   48: ffff 0008 1e2d 0204 0000 0000 0000 0030   .....-.........0
   64: 0000 0002 0066 0011 5245 504f 5254 494e   .....f..REPORTIN
   80: 4744 4154 4154 5950 4500 6800 0000 0200   GDATATYPE.h.....
   96: 6600 074d 5347 5459 5045 0068 0000 0001   f..MSGTYPE.h....
  112: 0c00 0001 1b59 bea7 0e00 0000 0000 0c63   .....Y.........c
  128: ce00 0000 0002 0000 1bce aced 0005 7372   ..............sr
  144: 0037 636f 6d2e 6265 612e 776c 692e 7265   .7com.bea.wli.re
  160: 706f 7274 696e 672e 6a6d 7370 726f 7669   porting.jmsprovi
  176: 6465 722e 7275 6e74 696d 652e 5265 706f   der.runtime.Repo
  192: 7274 4d65 7373 6167 6576 850c c3d6 d6bf   rtMessagev......
  208: 8502 0004 5b00 0a62 696e 5061 796c 6f61   ....[..binPayloa

Compact

L’ajout et la suppression d’éléments dans le store peuvent engendrer de la fragmentation. L’outil permet d’effectuer un compactage d’un PersistenceStore non-ouvert.
storeadmin-> close -store FileStore_auto_1 INFO: Store FileStore_auto_1 closed successfully storeadmin-> compact -dir FileStore_auto_1 -tempdir /var/weblogic/ INFO: Original FileStore_auto_1 moved to /var/weblogic/STOREADMIN_46757 INFO: Compacting store ... FILESTORE_AUTO_1 INFO: Store FILESTORE_AUTO_1 opened successfully INFO: Store STOREADMIN_FILESTORE_AUTO_1 created and opened successfully INFO: Copy from FILESTORE_AUTO_1 to STOREADMIN_FILESTORE_AUTO_1 successful INFO: Store FILESTORE_AUTO_1 closed successfully INFO: Store STOREADMIN_FILESTORE_AUTO_1 closed successfully INFO: Renamed STOREADMIN_FILESTORE_AUTO_1 to FILESTORE_AUTO_1 INFO: ... Compacted store FILESTORE_AUTO_1 INFO: Compact of FileStore_auto_1 successful : pre-compact files in /var/weblogic/STOREADMIN_46757 storeadmin->

Un dernier conseil : il est déconseillé de lancer cet outil alors que le serveur d’applications est en pleine charge: cela peut provoquer des effets de bords indésirables, du temps de réponse en berne à la corruption irréparable du Persistence Store.

Référence: Administering a Persistent Store

Exception synchronisée

Benoit Moussaud — Wed, 02 Jul 2008 06:00:33 +0000

Symptômes

Lors d’un test de performance sur une application J2EE, je note que celle-ci a des soucis de montée en charge. Généralement une ou deux thread dumps peuvent mettre en évidence les points de contentions. Dans mon cas, rien de probant. Je repense alors à l’article publié sur notre blog Chroniques de la performance : À propos de contentions…. Je récupère les sources de l’agent et l’installe sur le serveur d’application, Weblogic 8.1 – JVM 1.4.2. Lancement du tir….

Dès le début de phase plateau, l’agent affiche régulièrement une partie du code que je n’aurais pas soupçonné: la bibliothèque iBatis qui gère l’accès aux données.

[JTPROF] Contention report [id=-1250505672,thread=ExecuteThread: '14' for queue: 'weblogic.kernel.Default',blocked=210ms]
[JTPROF] Stack trace:
[JTPROF]         com.ibatis.sqlmap.engine.accessplan.EnhancedPropertyAccessPlan. (EnhancedPropertyAccessPlan.java:29)
[JTPROF]         com.ibatis.sqlmap.engine.accessplan.AccessPlanFactory.getAccessPlan (AccessPlanFactory.java:62)
[JTPROF]         com.ibatis.sqlmap.engine.exchange.JavaBeanDataExchange.initialize (JavaBeanDataExchange.java:63)
[JTPROF]         com.ibatis.sqlmap.engine.mapping.parameter.BasicParameterMap.setParameterMappingList (BasicParameterMap.java:93)
[JTPROF]         com.ibatis.sqlmap.engine.builder.xml.SqlStatementParser.applyInlineParameterMap (SqlStatementParser.java:431)
[JTPROF]         com.ibatis.sqlmap.engine.builder.xml.SqlStatementParser.processSqlStatement (SqlStatementParser.java:215)
[JTPROF]         com.ibatis.sqlmap.engine.builder.xml.SqlStatementParser.parseGeneralStatement (SqlStatementParser.java:120)

Les temps de blocage affichés vont de 20ms à 500ms !

Analyse

A la lecture de cette pile d’appel, je me dis « encore un bloc synchronisé mal placé dans iBatis« . L’avantage avec l’open source, comme son nom l’indique, est que l’on a accès aux sources. J’ai donc ouvert la classe EnhancedPropertyAccessPlan qui, à ma grande déception, infirma ma 1ère intuition :

27  EnhancedPropertyAccessPlan(Class clazz, String[] propertyNames) {
28    super(clazz, propertyNames);
29    bulkBean = BulkBean.create(clazz, getGetterNames(propertyNames), getSetterNames(propertyNames), getTypes(propertyNames));
30  }

La ligne #29 indique l’appel à une méthode statique de la classe « BulkBean » qui appartient à la bibliothèque cgLib, bien connue pour accélérer efficacement la création de beans Proxy . Idem: cette méthode n’est pas ‘synchronized’. Alors pourquoi l’agent m’indique cette méthode ?
Les grands moyens : injection de traces manuelles dans le code d’iBatis afin de comprendre ce qu’il se trame. Après de nombreux allers-retours de type ‘essais-erreurs’, je finis par trouver l’origine du problème : chaque appel à la méthode BulkBean.create() engendre une levée d’exception NoClassDefFoundError.
En effet, le packaging de l’ear est incomplet : cglib.jar est bien présente mais il manque l’une de ses dépendances : asm. Or le code de la méthode BulkBean.create() s’appuie essentiellement sur l’API d’asm.
Cependant le packaging n’est pas le seul coupable, iBatis est également fautive ! La méthode AccessPlanFactory.getAccessPlan est extrêmement défensive : l’appel à EnhancedPropertyAccessPlan est gardé par un bloc try…catch(Throwable). L’ajout d’un message de log de type « Erreur » aurait été le bienvenue, au moins la première fois.

60:       if (bytecodeEnhancementEnabled) {
61:        try {
62:          plan = new EnhancedPropertyAccessPlan(clazz, propertyNames);
63:        } catch (Throwable t) {
64:          try {
65:            plan = new PropertyAccessPlan(clazz, propertyNames);
66:         } catch (Throwable t2) {
67:            plan = new ComplexAccessPlan(clazz, propertyNames);
68:          }
69:        }

Explications

La levée d’une exception dans une méthode oblige la JVM à rendre l’appel synchronisé afin de garantir un traitement par le catch cohérent. Il ne faudrait pas que les données (attributs, paramètres, variables) aient été modifiées par un autre thread entre la levée de l’exception et son éventuel traitement.

Pour se convaincre de ce phénomène, il suffit d’écrire une simple classe de test : 10 threads, chaque thread appelle une méthode qui suivant un paramètre lève une Exception, une Error ou ne fait rien, et ceci 1 000 000 de fois. Le résultat :

lorsque la méthode ne lève aucune Exception ou Erreur : Temps de réponse : 89 ms
lorsque la méthode lève une exception : Temps de réponse 5892 ms, 66 fois plus lent !

Règle: La levée d’exception doit rester un cas exceptionnel et ne dois en aucun cas devenir un design pattern, c’est même un anti-pattern.

public class AntiPattern {
	class NotEvenException extends Exception {
	}
	boolean isEven(int nb) {
		try {
			if (nb % 2 > 0)
				throw new NotEvenException();
			return true;
		} catch (NotEvenException e) {
			return false;
		}
	}
}

Note : Une fois le packaging complet, l’agent jtprof ne mentionne plus du tout cette zone de l’application.

Les plans de déploiement Weblogic

Benoit Moussaud — Thu, 17 Apr 2008 09:33:25 +0000

« Il faudrait pouvoir changer le nom de la DataSource en fonction des environnements »
« Ouh la la, c’est compliqué, il faut décompresser l’archive de l’application MonApp.ear et les 5 fichiers .war et les 8 fichiers .jar des ejb. Ça prendra 3 semaines minimum, et sans la documentation! »

(La fonctionnalité « plans de déploiement » décrite dans cette article est disponible à partir de WebLogic 9)

Lors de l’article précédent, nous avions montré comment packager un pool de connexions JDBC avec un EAR. Il semble évident que si cette solution est intéressante, elle n’est suffisante pour paramétrer cette application dans différents environnements projets (Recette, Pré-Production ou Production). Il n’est pas envisageable que pour chaque environnement, il faille ouvrir l’archive, modifier le fichier XML avec les nouveaux paramètres et pour finir de la refermer.
L’idée des plans de déploiement est de laisser l’archive telle quelle et de lui associer au moment du déploiement les nouveaux paramètres. Un plan de déploiement est un fichier XML qui reprend l’ensemble des nouveaux paramètres à surcharger.

Reprenons l’application MyWebApplicationEAR décrite dans la première partie et appliquons un plan de déploiement pour modifier quelques paramètres.

Préparation de l’environnement de travail

mkdir DeployementPlan
mkdir DeployementPlan/MyWebApplicationEAR
mkdir DeployementPlan/MyWebApplicationEAR/app
cp MyWebApplicationEAR.ear DeployementPlan/app
#vérifions la structure de répertoire
find DeployementPlan
./MyWebApplicationEAR
./MyWebApplicationEAR/app
./MyWebApplicationEAR/app/MyWebApplicationEAR.ear

Génération du template du plan

WebLogic fournit un outil qui permet de générer un template de plan de déploiement basé sur les différents éléments de l’ear passé en paramètre.

cd D:xebia-blogdeploymentplan
java -classpath ${WLS_HOME}/server/lib/weblogic jar weblogic.PlanGenerator -root MyWebApplicationEAR
Generating plan for application MyWebApplicationEARappMyWebApplicationEAR.ear
Export option is: dependencies
Exporting properties...
Saving plan to D:xebia-blogdeploymentplanMyWebApplicationEARplanplan.xml...
<4 avr. 2008 18 h 03 CEST>    
MyWebApplicationEAR
+---app
|       MyWebApplicationEAR.ear
|
---plan
        plan.xml

Le fichier template du plan (plan.xml) a été créé dans le répertoire plan

Structure du fichier plan.xml

A ce niveau du processus, le fichier plan.xml contient uniquement la définition des différents modules qui composent l’archive EAR. On retrouve donc:

un module MyWebApplicationEAR.ear, de type EAR, avec 3 descripteurs de déploiement (weblogic-application.xml, application.xml et ds-jdbc.xml)
un module MyWebApplication.war, de type WAR, avec 2 descripteurs de déploiement (web.xml et weblogic.xml)



  MyWebApplicationEAR.ear
  
  
    MyWebApplicationEAR.ear
    ear
    
      weblogic-application
      META-INF/weblogic-application.xml
    
    
      application
      META-INF/application.xml
    
    
      jdbc-data-source
      META-INF/ds-jdbc.xml
    
  
  
  
    MyWebApplication.war
    war
    
      weblogic-web-app
      WEB-INF/weblogic.xml
    
    
      web-app
      WEB-INF/web.xml

Paramétrage du plan en utilisant la console d’administration

Notre plan est vide, il faut maintenant indiquer les paramètres à modifier. Dans un premier temps, le plus simple est d’utiliser la console d’administration du domaine.

Déployer l’application en sélectionnant le répertoire DeployementPlan/MyWebApplicationEAR.
Accepter l’ensemble des valeurs par défaut (Next, Next, Finish)
Activer les modifications.

Remarque : On voit que le fichier plan.xml est indiqué comme ‘Deployment Plan’

Paramétrage pour un environnement de Recette.

Sélectionner le module MyWebApplicationDS
Dans le menu Configuration / ConnectionPool, modifier les propriétés UserName et Password (Recette/Recette) et Maximum Capacity=10 et Web Session Timeout (in seconds) = 360.
Après les différentes phases de sauvegarde, les modifications sont inscrites directement dans le fichier plan/plan.xml, les fichiers de configuration du domaine Weblogic (config/config.xml et consorts) restent inchangés. La console WebLogic indique cette différence par un bouton ‘ReleaseConfiguration’ et non ‘Apply Changes’.

Structure du fichier plan.xml

Si on examine les modifications faites par la Console Weblogic sur le fichier plan.xml, on peut noter:

l’apparition d’un ensemble de nœuds gardé par . Il contient un ensemble de couples de variables (name, value) qui correspondent aux paramètres modifiés


  MyWebApplicationEAR
  
  
    
      JDBCDriverParams_PasswordEncrypted_12040376123280
      {3DES}QZJ2MfqOliA=
    
    
      JDBCConnectionPoolParams_MaxCapacity_12040378132185
      10
    
    
      JDBCProperty_user_Value_12040378358436
      recette
    
    
      SessionDescriptor_timeoutSecs_12040384414060
      360
    
  
  .....

la modification des nœuds . Pour chaque variable qui concerne le module, une expression XPath est définie pour permettre au serveur d’application d’effectuer la substitution avec la nouvelle valeur.


....
   
      jdbc-data-source
      META-INF/ds-jdbc.xml
      
        JDBCDriverParams_PasswordEncrypted_12040376123280
        /jdbc-data-source/jdbc-driver-params/password-encrypted
      
      
        JDBCConnectionPoolParams_MaxCapacity_12040378132185
        /jdbc-data-source/jdbc-connection-pool-params/max-capacity
      
      
        JDBCProperty_user_Value_12040378358436
        /jdbc-data-source/jdbc-driver-params/properties/property/[name="user"]/value
      
    
....

A partir de ce plan créé pour un environnement de type ‘Recette’ (plan-recette.xml), il est facile de le décliner pour d’autres environnement, ex la ‘Production’ (plan-production.xml). Les changements sont :

les propriétés UserName et Password (Production/Production) et
la propriété Maximum Capacity=20.

DeployementPlanMyWebApplicationEAR
+---app
|       MyWebApplicationEAR.ear
|
---plan
        plan-production.xml
        plan-recette.xml

(Note: le fichier plan.xml a été renommé en ‘plan-recette.xml’).

Utilisation du plan

Une fois les plans créés, il est très facile avec WLST de déployer l’application sur l’environnement cible avec son plan de déploiement.
Note : Une fois les fichiers de plan de déploiement créés, il n’est pas nécessaire de conserver une arborescence ./app et ./plan comme établi en début d’article.

Exemple: déploiement de l’application MyWebApplicationEAR en mode production.

deploy(appName='MyWebApplicationEAR',path='/vers/monfichier/ear/MyWebApplicationEAR.ear', planPath=/vers/mon/plan/MyWebApplicationEAR/plan/plan-production.xml')

Vérification avec l’application MyWebApplication:

Les plans de déploiement peuvent également servir à mettre à jour les paramètres de l’application si celle-ci est déjà déployée dans le serveur WebLogic

Soit avec la console d’administration, deployement –> update

Soit avec la commande WLST updateApplication ou redeploy

Exemple:

updateApplication(''MyWebApplicationEAR','/vers/mon/plan/MyWebApplicationEAR/plan/plan-production-tuning.xml')

Conclusion

Les plans de déploiement :

répondent à un besoin longtemps exprimé par les utilisateurs: pouvoir modifier le paramétrage d’une application sans à nécessiter de lourdes procédures d’extraction des descripteurs de déploiement enfouis dans les archives J2EE (.ear/.jar/.war).
permettent de séparer clairement les rôles: d’un côté les développeurs créent l’application, de l’autre le ‘déployeur’ ou l’administrateur adapte l’application à l’environnement cible.

Documentation BEA,Deploying Applications to WebLogic Server

Activer un aspect par JMX

Benoit Moussaud — Wed, 19 Mar 2008 09:00:34 +0000

En mai 2007, Manuel Eveno expliquait comment avec la programmation orientée aspect (AOP) et l’outil Jamon, il est facile de relever des points de mesure dans une application Java / J2EE. Cependant, il existe des situations (exemple : environnement de Production) où l’on aimerait pouvoir activer temporairement ou désactiver complètement ce type d’aspects. Dans cet article, je vais expliquer comment avec l’AOP on peut activer un aspect par JMX.

Voici l’aspect PerfMonitor présenté par Manuel dans son article : le pointcut monitor concerne l’exécution de la méthode methodToMonitor de la classe fr.xebia.appz.ClassToMonitor, quel que soit son nombre de paramètres et sa visibilité. L’advice de prise de mesure est appliqué avant et après le pointcut monitor.

public aspect PerfMonitor {
	pointcut monitor() :
              execution(* fr.xebia.appz.ClassToMonitor.methodToMonitor(..)) ;
	Object around() : monitor() {
		Monitor monitor = MonitorFactory.start(thisJoinPoint.toShortString());
		try {
			return proceed();
		} finally {
			if (monitor != null)
				monitor.stop();
		}
	}
}

Ajouter l’attribut ‘enabled’ à l’aspect

Tout d’abord, il faut ajouter un attribut ‘enabled’ à l’aspect et modifier l’advice pour prendre en compte l’état de l’attribut. Voici le nouveau code de l’aspect PerfMonitor :

public aspect PerfMonitor {
	private boolean enabled = true;
	public boolean isEnabled() {
		return enabled;
	}
	public void setEnabled(boolean enabled) {
		this.enabled = enabled;
	}
	pointcut monitorEnabled() : if(aspectOf().isEnabled());
	pointcut monitor() :
                execution(* fr.xebia.appz.ClassToMonitor.methodToMonitor(..)) ;
	Object around() : monitor() && monitorEnabled() {
		Monitor monitor = MonitorFactory.start(thisJoinPoint.toShortString());
		try {
			return proceed();
		} finally {
			if (monitor != null)
				monitor.stop();
		}
	}
}

Quelques remarques :

l’attribut ‘enabled’ est initialisé à la valeur ‘true’ par défaut.
l’attribut est accessible par les deux méthodes à la manière ‘JavaBean’, isEnabled(), setEnabled()
un nouveau pointcut monitorEnabled a été défini. Il retourne ‘true’ si l’appel de la méthode de l’aspect isEnabled() retourne ‘true’. L’instruction aspectOf() retourne une référence sur l’aspect, comme le mot-clé this en Java retourne une référence sur l’objet lui-même.
l’advice a été modifié pour prendre compte le nouveau pointcut. Il sera activé que si les pointcuts monitor et monitorEnabled sont vérifiés.

A partir de là, si la valeur l’attribut ‘enabled’ est égale à false, il n’y aura pas de prise de mesure par l’API Jamon.

Exposition JMX

Avoir un attribut ‘enabled’ est intéressant mais pas suffisant. Il faut pouvoir modifier sa valeur dynamiquement et modifier le comportement au runtime sans nécessiter un redémarrage de la JVM. On pense aussitôt à l’API JMX. Mais comment exposer un aspect par JMX alors qu’à aucun moment on n’est maître de son instanciation ? Un aspect n’est pas une classes sur laquelle on peut appliquer l’operateur new().

Les possibilités offertes par l’AOP à travers l’aspect ‘Management‘ vont nous permettre l’inimaginable !

public aspect Management {
	public interface ManagedBean {
		public boolean isEnabled();
		public void setEnabled(boolean enabled);
	}
	private pointcut managedBeanConstruction(ManagedBean bean) :
                  execution(ManagedBean.new(..)) && this(bean);
	after(ManagedBean bean) returning: managedBeanConstruction(bean) {
		ObjectName registered = getMBeanExporter()
				.registerManagedResource(bean);
		System.out.println("Bean " + bean
				+ " is exposed with this object name " + registered);
	}
	declare parents: PerfMonitor implements ManagedBean;
	private MBeanExporter getMBeanExporter() {
		///Spring Framework Stuff !
	}
}

L’exposition JMX se fait en 3 temps :

Le pointcut managedBeanConstruction est vérifié lors de l’exécution de l’instanciation de toute classe implémentant l’interface ManagedBean.
L’advice suivant est appliqué après le retour du pointcut managedBeanConstruction : il récupère une instance de type org.springframework.jmx.export.MBeanExporter, une classe qui permet d’exposer n’importe quelle classes à l’intérieur d’un MBeanServer, sans qu’il soit nécessaire de définir l’ensemble des informations spécifique à l’API JMX, puis enregistre l’instance de type ManagedBean passé en paramètre comme MBean JMX.
Le code ‘declare parents: PerfMonitor implements ManagedBean’ indique que maintenant la classe PerfMonitor implémente l’interface ManagedBean. C’est de l’Injection d’interfaces ! L’instruction ‘déclare parent’ permet modifier l’arbre d’héritage d’une classe: dérivation, ajout d’interfaces,… Dans notre cas, le contrat défini par l’interface ManagedBean ajouté à notre Aspect PerfMonitor est déjà rempli par l’aspect lui-même (méthodes isEnabled() et setEnabled()).

Au runtime, dès que le framework AspectJ va procéder à l’instanciation de l’aspect PerfMonitor sous la forme d’une classe Java qui implémente l’interface ManagedBean, l’aspect sera exposé en tant que MBean JMX.

Le screencast suivant détaille les deux aspects (Management et PerfMonitor) et montre sur un exemple très simple le comportement de l’aspect en fonction de la valeur de l’attribut ‘enabled’ modifié par l’outil JConsole

L’ensemble des sources est disponible dans le repository SVN de Xebia France.

Packagez vos sources de données avec WebLogic

Benoit Moussaud — Tue, 11 Mar 2008 12:00:13 +0000

Cet article inaugure une série autour de fonctions avancées et souvent méconnues apparues dans les dernières versions du serveur d’application WebLogic.

Une application J2EE utilise généralement une ou plusieurs sources de données (datasources). La spécification J2EE permet au mieux de référencer le nom JNDI de la source de données dans le descripteur de déploiement de l’application (ou de la web-app). En revanche, le paramétrage complet de la source de données (Type, URL JDBC, Taille du Pool,…) est une opération spécifique à chaque serveur d’application. Lorsque vient le temps de la livraison de l’application en dehors de l’environnement de développement (Intégration, Recette, …), les équipes fournissent généralement l’archive de l’application à déployer et un document d’installation au format Word. Il décrit, à l’aide de nombreuses copies d’écran, les opérations à effectuer à travers l’application d’administration pour déclarer et paramétrer les sources de données avant de procéder au déploiement du fichier MonApplication.ear proprement dit. Cet article montre comment avec le serveur d’application Weblogic 9+, il est possible d’associer, à l’application à déployer, l’ensemble des ses ressources, en particulier, le paramétrage de ses sources de données.

Exemple: Pour illustrer mon propos, j’utiliserai une application web, MyWebApplication, qui affiche des informations sur une connexion JDBC obtenue par une DataSource inscrite dans l’arbre JDNI. Cette application est classiquement packagée sous forme d’une archive web, MyWebApplication.war, elle-même encapsulée dans une archive MyWebApplicationEAR.ear.

télécharger MyWebApplicationEAR.ear et retrouver l’ensemble des sources dans le repository SVN de Xebia France, branche /svn/trunk/wls/deployment.

Si on déploie cette application et que la source de données MyDataSource n’est pas correctement installée, par exemple suite à un mauvais paramétrage du nom JNDI, on obtient l’erreur suivante:

javax.naming.NameNotFoundException:
Unable to resolve 'MyDataSource'. Resolved ''; remaining name 'MyDataSource'

Depuis la version 9, le serveur d’application WebLogic offre un moyen de packager les ressources JDBC dans l’archive ear.

Etapes

Dans le fichier META-INF/weblogic-application.xml,spécifique à l’éditeur, déclarer un module de type JDBC.


  MyWebApplicationDS
  JDBC
  META-INF/ds-jdbc.xml

Cette configuration indique que le fichier ds-jdbc.xml placé dans le répertoire META-INF de l’archive contient des élements de configuration de type ‘source de données’ (JDBC)

l’extension -jdbc.xml est obligatoire (sic !)
le répertoire de stockage du fichier xml est libre. Il est possible de placer ces modules dans un répertoire autre que ‘META-INF/’, par exemple ‘modules/’.
si Eclipse WTPest utilisé comme IDE, déposer les modules dans le répertoire META-INF/ et ils seront automatiquement intégrés au packaging de l’EAR et déployés sur le serveur d’application.

Contenu du fichier META-INF/ds-jdbc.xml:



    MyDevDataBase
    
        jdbc:oracle:thin:@localhost:1521:xe
        oracle.jdbc.OracleDriver
        
            
                user
                weblogic
            
        
        weblogic
    
    
        1
        5
        1
        900
        true
        SQL SELECT 1 FROM DUAL
    
    
        MyDataSource
        Global

On retrouve l’ensemble des informations que l’on pourrait renseigner dans la console d’administration de WebLogic.

Si on ajoute ce fichier à l’archive MyWebApplicationEAR.ear, le déploiement de cet EAR va engendrer la création d’une nouvelle source de données déployée dans l’arbre JNDI sous le nom ‘MyDataSource’. Elle sera accessible à toutes les applications déployées dans le serveur (scope=Global).

Si on se connecte à la console d’administration, on peut apercevoir quelques différences.
Le point marquant est que la source de données n’est pas présente dans l’arborescence Services –> JDBC –> DataSources, comme d’habitude. Elle n’est visible que si on sélectionne le ‘JDBC Module’. (Deployments –> MyWebApplicationEAR –> MyWebApplicationDS). A partir de là, on accède au paramétrage et aux données de monitoring de la source de données.

Ce screencast montre les différents éléments déployés dans la console d’adminstration de Weblogic.

Dans l’exemple précédent, la source de données est globale à l’ensemble du serveur d’application. Il est possible de restreindre la visibilité de cette source de données, seulement à l’application. Les changements à effectuer sont:

dans le fichier web.xml (spécifications J2EE)


    MyDataSource
    javax.sql.DataSource
    Container

dans le fichier META-INF/ds-jdbc.xml


  .....
  
        MyDataSource
        Application

Et la sécurité ?
La première remarque est généralement: « Le mot de passe est en clair dans le fichier XML ! ». C’est exact ! Si l’objectif de ce packaging est de pouvoir installer rapidement un environnement de développement ou une plateforme de démonstration, ce n’est pas gênant. Sinon, il est toujours possible de crypter le mot de passe dans le fichier XML avec le commande weblogic.security.Encrypt. Attention ! le cryptage du mot de passe dépend du domaine sur lequel l’application va être déployée (le domaine est d’ailleurs précisé par la propriété -Dweblogic.RootDirectory).

java -classpath ${WLS_HOME}/server/lib/weblogic.jar -Dweblogic.RootDirectory=./mywlsdomain weblogic.security.Encrypt weblogic
{3DES}QdEw5GGOy4GM/8QwBmTEbg==

Il ne reste qu’à copier ce mot de passe crypté dans la balise password-encrypted.

{3DES}QdEw5GGOy4GM/8QwBmTEbg==

Référence: http://e-docs.bea.com/wls/docs90/admin_ref/utils.html#encrypt

Et en cas de mauvais paramétrage ?
Modifions l’url de la source de données (ex changement de port 1521 –> 1525) et déployons l’archive. Echec du déploiement! Le serveur conserve l’environnement cohérent et refuse d’effectuer le déploiement.

<26 févr. 2008 12 h 11 CET>    
<26 févr. 2008 12 h 11 CET>

Si on observe le cycle de vie d’une application, du développement à la mise en production, on s’aperçoit que le mécanisme exposé est intéressant mais pas suffisant. En effet, il existe de grandes différences d’infrastructure et de contraintes entre les environnements typé ‘Développement’ et les environnements typés ‘Production’: Charge nominale supportée, Haute disponibilité, Typologie réseau (DMZ, Intranet…),… Ces différences impliquent un paramétrage différent du serveur d’application. Dans un prochain article, nous verrons comment utiliser les plans de déploiement pour configurer l’application et l’adapter facilement à ces différents environnements.

Documentation Officielle BEA http://e-docs.bea.com/wls/docs90/jdbc_admin/packagedjdbc.html

Xebia Web Framework Contest

Benoit Moussaud — Fri, 26 Oct 2007 04:42:36 +0000

Pour tous les consultants de Xebia France, le dernier vendredi de chaque mois est important : c’est le jour du XKE, le Xebia Knowledge Exchange. L’ensemble des consultants est rassemblé pour échanger durant une journée entière sur tous les sujets liés à l’écosystème Java / J2EE ainsi que les méthodes agiles. D’habitude la journée est découpée en plusieurs sessions allant de 45 mn à 3 h, suivant les sujets et le mode d’interaction (de la présentation formelle à des travaux pratiques sur des sujets complexes).

Le mois dernier, nous avons décidé de faire du XKE le Xebia Web Framework Contest, un concours de développement autour des framework de présentation.

4 équipes ont développé la même application web, chacune avec un framework (très) différent. Les frameworks retenus étaient :

Strut2,
Google Web ToolKit,
Wicket,
My Faces (JSF).

8h30 certains, les plus scolaires, sont déjà arrivés et aiguisent leurs environnements, se concertent sur les rôles de chacun.
9h00 tout le monde est là, certains prennent leur café en discutant de tout sauf du concours qui les attend alors que d’autres sont fin prêts …
9h30 les spécifications, tenues secrètes jusqu’au jour J sont enfin distribuées aux équipes et là : grande surprise et grande rigolade ….

Wanda Zeller, directrice d’un réseau de call girls international, a décidé d’augmenter son volume d’affaire en mettant en ligne un site de réservation interactif de ses protégées. Mme Zeller, que son activité contraint à la discrétion, a délégué son chargé d’affaires, M. Moussaud, de relayer ses exigences et de piloter les développements. Mme Zeller, qui vit avec son temps, dispose d’ores et déjà d’un système de réservation qu’utilisent les opérateurs de son call-center marocain. Afin de limiter les efforts de développement, il a été décidé de réutiliser les services métier mis au point pour ce système de réservation, et de limiter les développements à la couche de présentation.

Les spécifications de nouveaux lots seront ensuite distribuées à un rythme assez soutenu, à raison d’une toutes les heures trente. Chacune ayant pour but d’adresser un pan particulier.

Le premier lot mettait en place les mécanismes de recherche simple et un système de panier avec commande.
Le lot 2 apportait la couche « sécurité » sur les commandes.
Le lot 3 ajoutait la mise en place d’un workflow de validation des commandes.
Enfin le dernier lot mettait l’accent sur l’aspect validation.

Après une journée intense de développement, chaque équipe est venue présenter son œuvre et donner son avis sur les avantages et inconvénients de la solution étudiée.

Google Web Toolkit

L’équipe a bataillé un moment pour trouver quels fichiers étaient à synchroniser entre les membres de l’équipe et ceux qui ne l’étaient pas. Pour ne pas perdre de temps (c’était quand même un concours !), la synchronisation s’est faite finallement par clé USB !

Ce qui avait séduit l’équipe avec ce framework nouvelle génération est le concept du ‘Tout-Java’: le client et le serveur sont codés en java, GWT se charge de la génération des pages web et du javascript. Mais ce modèle à des contraintes:

Implémentation d’une interface IsSerialisable pour tout objet qui transite entre le client et le serveur (réglé depuis la version 1.4).
Support de Java 1.4 (seulement), donc il faut oublier les génériques et les annotations pour la partie client (fonctionnalité programmé pour la future version 1.5 ).
Le concept client-serveur reste quand même assez déroutant quand depuis des années on manipule chaque jours des objets de type Request/Response, des pages JSP/Html ou des actions ‘Struts’.

La conclusion de l’équipe est qu’il faut vraiment aborder GWT comme un framework Client Riche avec un concept de client/serveur; les outils se chargeant entièrement de l’exposition en mode Web (JSP/CSS/AJax). Le coût d’entrée semble assez important et les composants graphiques limités (il n’est pas évident d’intégrer des composants d’une maquette HTML existante). Donc GWT est un outil à suivre en attendant la maturité.

Synthèse de l’équipe :

Les bons points :

Gestion transparente des différents browsers.
Possibilité d’utiliser un debugger Java (celui de l’environnement de développement choisi, Eclipse par exemple).
Beaucoup de buzz autour du projet. Notamment concernant les extensions graphiques (portage de plusieurs librairies AJAX), début d’intégration avec Spring.
Un retour à la programmation graphique par composant.
Facile de mettre en place une IHM simple.

Les mauvais points :

Seule une partie du JRE est supportée côté client et pour les DTO utilisés par les RCPs (ex: pas toutes les collections).
Besoin d’un mapping objet métier/DTO utilisés par GWT (Serializable et un constructeur public par défaut).
Manque guide de bonnes pratiques et de la documentation en général.
Les API ne sont pas toutes détaillées.
Il n’y a que des composants graphiques « simples ». Si l’on veut utiliser des composants plus évolués, il faut soit les coder ou bien se tourner vers des librairies de widgets GWT Open Source « non Google ».

Les points non abordés :

Possibilité de faire des tests unitaires.
Internationalisation.
JavaScript Native Interface (JSNI).
Exposition de services via Web Services/JSON/XML.
Facilité/difficulté du respect d’une charte graphique.
Authentification.
Respect des standards, facilité de référencement.
Intégration à l’IDE Idea (semble assez poussée, gestion des CSS et modules à partir du code Java).

Struts 2

L’équipe avait préparé un template de projet Struts2 avant le XKE, projet Eclipse/Maven 2, web.xml déjà configuré, librairies installées, et différents tests « Hello World » de plugins (zero conf, etc…).
Résultat : c’est l’équipe gagnante.

L’équipe n’a pas rencontré de difficultés particulières, et a décidé de développer l’application avec ses tests unitaires, ce qui n’était peut être pas nécessaire dans le cadre du concours, mais qui a permis de démontrer la facilité avec laquelle les actions Struts2 peuvent être testées unitairement (le gros défaut de Struts 1).

Synthèse de l’équipe :

Les bons points :

Testabilité : écrire des tests unitaires pour les actions, qui sont de simples POJOs, est très simple.
Modularité des filtres sur les actions : les piles d’Interceptors sont très pratiques pour appliquer des filtres différents aux actions (authentification etc.). Mais est-ce réellement si utile ? A part le classique interceptor d’authentification qui ne s’applique pas aux actions de type « login » et « forgotten password », a-t-on vraiment besoin de tant de modularité sur les filtres ?
Simplicité : Struts 2 est simple à utiliser par une équipe projet. Sa modularité et sa testabilité le rendent parfaitement adapté au travail en équipe.
Prédictibilité par son efficacité et son classicisme : Struts2 est un framework éprouvé aux concepts très répandus (« Action based », Orienté Objet simple) qui ne causera pas de mauvaise surprise. Struts 2 sera prédictible sur un projet.
Elégance des interactions HTTP : URL claires et un modèle post-and-redirect fiable (double submit) et efficace (bookmarkable) malgré WW-1714 qui est en cours de résolution.
Souplesse de l’interface graphique : le mécanisme de template est très pratique mettre en œuvre la charte graphique d’un site ou d’une application. SiteMesh est un complément naturel très efficace.
Débuggabilité : des tags de debug (facilement désactivables pour la production) et un browser de configuration simplifient le troubleshooting (voir également les mauvais points sur la débuggabilité de Struts2).
Coût d’entrée réduit : le framework est plus simple à appréhender que Struts 1.
Form beans : aucun fichier de configuration, on peut passer de simples POJO à la vue Tests unitaires : les actions sont testables facilement avec JUnit, les actions sont des POJO.
Templates : intégration avec Sitemesh aisée pour les templates, les templates Sitemesh ont accès aux tags Struts grâce au plugin struts2-sitemesh.
Ajax : tags Ajax (support Ajax basé sur le toolkit Dojo) simplifient, voir masquent, l’utilisation de dojoSpring: support de Spring, on choisit le framework d’injection à utiliser dans la configuration.
Expression Language : les taglibs utilisent OGNL, plus puissant que JSTL, Communauté: framework MVC le plus téléchargé du moment (http://www.jroller.com/TedHusted/entry/struts_skyrockets ) , les mailing lists sont très actives.

Les mauvais points :

Hétérogénéité / dispersion : Struts 2 se disperse en proposant souvent plusieurs solutions pour un sujet sans qu’aucune ne soit pleinement satisfaisante.
- Trois technos pour le HTML : JSP, Freemarker et Velocity.
- Plusieurs projets de configuration par annotations : Zero config etc.
Configuration propriétaire (struts.xml).
- Spring est le standard de-facto pour configurer l’assemblage des composants d’une application. Il serait très pratique de pouvoir configurer Struts2 dans les fichiers Spring grâce au mécanisme d’extension de configuration introduit dans Spring 2 à l’instar de la configuration d’Apache CXF (e.g. , etc.).
Productivité modérée : c’est probablement un écueil du classicisme et de la testabilité (découplage actions-pojo de la présentation) mais la productivité n’est pas stupéfiante.
Debuggabilité : Struts2 n’affiche aucun message d’erreur en cas de coquille sur les variables de scripting (i.e. manipulées par OGNL) aussi bien dans les page web (jsp, ftl ou velocity) que dans la config (paramètres dans les redirections …). Le problème est en cours de résolution.
Performances : l’application doit être configurée d’une certaine manière pour obtenir des performances acceptables (http://struts.apache.org/2.x/docs/performance-tuning.html). OGNL est plus lent que JSTL dans certains cas (mais est aussi plus riche).
Développement : l’équipe de commiteurs est réduite, les trous de sécurité prennent du temps à être corrigés.
Ajax : Le support Ajax est intégré dans le cœur de Struts2, pas sous forme de plugin, une mise à jour de dojo toolkit demande de sortir une nouvelle version de Struts2 (va changer dans Struts 2.1).
Documentation : il est parfois difficile de se repérer dans la documentation, certaines pages font parfois référence à webwork, elle n’est pas tout le temps à jour (c’est bien évidemment lié au faible nombre de commiteurs sur le projet).

Conclusion :

Struts2 est basé sur l’excellent WebWork 2.2, les bases sont saines. En revanche, les nouveaux développements Struts 2.0 ont pris du temps, et certains ont été remis en cause dans le futur Struts 2.1. Struts 2.1 est plein de promesses, les performances devraient être meilleures (mise à jour vers OGNL 2.7, vers Dojo 0.9,…), et le plugin SmartURLs devrait permettre de se passer de la configuration explicite, pour se rapprocher encore du paradigme « Convention over Configuration ». Le projet tend vers une consolidation des différents plugins, et a appris de ses erreurs depuis la première release de Struts2. Aujourd’hui nous pouvons conseiller d’attendre la première release stable et éprouvée de Struts 2.1 (Struts 2.1.0 devrait sortir à la fin Octobre 2007) pour démarrer un nouveau projet. La branche 2.0 ne va plus évoluer, et le saut 2.0 vers 2.1 ne sera pas forcément transparent!

JSF/My Faces

Ce groupe de Travail a véritablement bataillé durant toute la journée et le bilan affiché en fin de journée est un peu mitigé.

Les bons points :

Concepts proches des frameworks Struts 2 et Spring MVC
Utilisation de POJO simple
La tentative de standardisation
Le support des éditeurs

Les mauvais points :

Complexité de mise en oeuvre
Manque de documentation
Manque de transparence sur le fonctionnement du framework
Impossibilité de mixer JSF avec d’autres composants (Tag JSP 2.0, Taglibs tierces, etc.)

Synthèse de l’équipe :

Dès le début JSF présente la spécificité d’utiliser un buffer spécifique pour écrire la response.
Il n’est pas possible d’utiliser directement du code HTML à l’intérieur de tags JSF ! Vous devez baliser tout vos blocs html par (bye bye xhtml) ou utiliser la tablig htmLib pour remplacer tous vos tags html par le tag équivalent (perfs ?).
Autre impact, plus gênant : l’intégration du code JSF avec les autres taglib. JSF ne dispose pas de certains tags intégrés de base dans d’autres frameworks. Par exemple, en JSF les conditions et les boucles n’existent pas. Et comme on atteint vite les limites des fonctionnalités offertes par les taglib JSF, on aimerait bien pouvoir retourner sur du JSTL ; mais là encore vous vous heurterez à des problèmes de compatibilité à cause du « buffer JSF » mentionné plus haut.
La gestion des templates n’existant pas non plus dans JSF, il faut utiliser struts-tiles.
Côté gestion des erreurs justement, on peut dire que JSF n’est pas bavard. Pour certains problèmes de navigation la page appelante est simplement réaffichée, sans aucun message d’erreur ! Autant dire que certains bugs deviennent très difficiles à analyser.
Autre détail, le nom des tags dans les taglib ou même pour les fichiers de conf ne sont pas très intuitifs, mais si vous avez besoin, des plugins permettent de vous imprégner du vocabulaire JSF assez rapidement.

Conclusion :

JSF n’est clairement pas le framework le plus productif, en tous cas pas sur une journée car le coût d’entrée est lourd. Et même une fois habitué au framework, on peut se demander comment être productif sans remontée d’erreur et quelles limites posera cette gestion de buffer spécifique dans le cadre d’un vrai projet ?

Wicket

On peut considérer Wicket comme la bonne surprise de cette journée. Replaçons le contexte. Au moment des choix de chaque consultant, certains ont préféré partir sur la nouveauté (Wicket) par rapport à l’ancien solide et fiable (ex : Struts 2). Les différents contraintes de leur vie professionnelle n’ont pas permis aux membres de cette équipe d’affiner le sujet avant le jour J. Seul un rapide coup d’œil sur le « HelloWorld » de Wicket le soir précédant la compétition. C’est donc sans grandes connaissances qu’ils ont abordés ce concours. A la fin de la journée, ils avaient implémentés globalement l’ensemble du Lot 1 (Rappel: My Faces et GWT n’y sont pas arrivés !). C’est là que le framework choisit intervient.

Les bons points :

Prise en main rapide
Véritable séparation entre la partie cliente et la partie serveur (utilisation de plain HTML)
Retour à la programmation graphique des composants
Mécanismes de templating par héritage Java
Pas de fichier de configuration : une classe définie dans le web.xml sert de point d’entrée
Navigation entre les pages définies en Java (ex: new Link(PageSuivante.class))
Démarrage rapide (notamment grâce à l’archetype Maven2)

Les mauvais points :

Documentation très très succinte malgré l’existence d’exemples
- Pas d’explication des concepts de base (navigation, gestion de la session, templating, etc)

Les points non abordés :

Possibilité de faire des tests unitaires
Validation de formulaire
Internationalisation
Intégration de composant Ajax

Synthèse de l’équipe :

Les concepts de wicket sont les suivants :

Séparation très claire entre la présentation (.html) et les actions métiers (.java).
Pas de longue configuration xml, le seul fichier xml est le web.xml.
Une création automatique d’un squelette d’application avec un seul artefact maven. (est-ce maven la réelle clé de la productivité ?)
Haute réutilisation des maquettes html (fournie avec les spécifications) : le positionnement des éléments dynamiques utilisent principalement des balises HTML de type avec un attribut « wicket.id ».

Conclusion :

En un mot, un framework web simple, facile et pragmatique. Ces 3 qualificatifs ont permis à l’équipe d’aller très vite une fois les concepts acquis. Ils ont cependant beaucoup « ralé » sur le manque de documentation. Seuls les exemples fournis leur ont permis de déjouer et de comprendre les subtilités du framework. Il faut cependant relativiser cet enthousiasme :

Que vaut wicket sur des fonctions avancées comme la validation de formulaire ou un workflow d’écran avec suivant et précédent ?
Est-il seulement un buzzword du moment ou va-t-il perdurer ?

Alors qui est le gagnant ?

Catégorie « Couverture », l’équipe Struts2 a implémenté le plus de fonctionnalités, c’est indéniable. En revanche déception vis à vis du rendement !
Catégorie « Découverte », Wicket a été une révélation pour beaucoup d’entre nous ! Une fois passée la barrière de la découverte, le développement est rapide et efficace.

Pour des raisons évidentes de bonne moralité, nous ne pouvons mettre en ligne les différentes applications développées …

Laissez les coder !

Benoit Moussaud — Thu, 06 Sep 2007 07:30:55 +0000

Les grands intégrateurs ont depuis longtemps institué un chemin d’évolution basé sur la gestion de projets. Les jeunes débutants, le plus souvent de formation ingénieurs, sont rapidement formés à encadrer des équipes de développeurs et à piloter les projets : la voie royale ! Ces dernières années, vue la complexité technique des nouvelles architectures, une autre voie a émergé : la filière technique. Cette dernière destinée à promouvoir les compétences techniques et d’architectures applicatives, plus en adéquation avec une formation initiale d’ingénieur. Cependant la pression économique impose que ces personnes progressent rapidement vers une spécialité, une expertise (J2EE ; Les bases de données ; La sécurité …) et en les affectant de plus en plus à des missions en parallèle (2 jours chez Untel, 1 jour sur le projet Bidule). Cette rapidité de progression pose toujours le même souci : qui développe réellement l’application ? Très souvent des stagiaires ou, dans le meilleur des cas, de très jeunes embauchés après leur formation.

Les techniques de développement demandent de plus en plus d’être polyvalent : de l’écriture de requêtes SQL à la présentation des données dans une page JSP. Cette polyvalence ne s’acquière pas en quelques années et nécessite également de rester à jour dans ses connaissances. Alors pourquoi propulser ces personnes dans d’autres fonctions ?

Intégrer dans une équipe de développement un ou plusieurs développeurs expérimentés permet deux choses :

Accélérer les phases de codage et de validation technique et fonctionnelle : l’expérience permet de réduire le nombre d’allers retours entre ces deux étapes.
Créer une continuité de savoir et d’intérêt entre de jeunes débutants et des profils tels que les chefs de projets voire même les architectes.

Reste à définir la notion d’expérience. Deux composantes rentrent en jeux : les années passées à exercer cette compétence, 3 à 5 ans et surtout le nombre de projets, 5 à 10. Ce dernier point est très important : confronter sa compétence à différents clients, technologies ou architectures est essentiel pour aguerrir les meilleurs développeurs !

Alors laissez les coder !

JConsole et WebLogic 9

Benoit Moussaud — Thu, 28 Jun 2007 13:57:49 +0000

JConsole est un outil disponible à partir du JDK 5.0 qui repose sur l’API JMX pour afficher et suivre les métriques d’une machine virtuelle Java.
Les différentes catégories sont :

L’état de la mémoire et des garbages collections.
Les threads, liste et activité, comme sur un Thread Dump.
Les chargement des classes .
Les suivi et la gestion des MBeans.
Des informations générales sur la JVM (ClassPath, Library Path, Argument de la JVM, …).

Il existe deux façons de connecter une JConsole sur une machine virtuelle Java 5 :

En local

Le mode local nécessite que la JConsole et la machine virtuelle soient sur la même machine. Il suffit alors d’ajouter au démarrage de la machine virtuelle la propriété : -Dcom.sun.management.jmxremote.
Note : A partir du JDK 6, cette propriété est positionnée par défaut, donc toutes les JVM pourront être monitorées ‘Out Of the Box’.

L’exécutable de la JConsole est situé dans /bin. Au démarrage, la JConsole affiche l’ensemble des JVM accessibles.

A distance

JMX définit le protocole RMI comme protocole d’échange. Par défaut, on considère qu’il existe deux implémentations de RMI :

JRMP (Java Remote Method Protocol)
IIOP (Internet Inter-Orb Protocol)

Le serveur d’applications BEA Weblogic propose une implémentation supplémentaire (et plus performante), le protocole T3.

La suite de ce billet détaille la configuration à mettre en place pour chacun des trois protocoles, et les avantages et inconvénients de chacun.

JRMP

Pour accéder à une JVM par JRMP, il faut ajouter les propriétés suivantes :

[CODE]
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
[/CODE]

Note : Les paramètres com.sun.management.jmxremote.ssl=false et com.sun.management.jmxremote.authenticate=false introduisent une large faille de sécurité sur la JVM (ni authentification, ni cryptage des données échangées). La mise en place d’une authentification est possible en définissant une liste d’utilisateurs dans le fichier /jre/lib/management/jmxremote.password. Tout est détailé sur ‘Luis-Miguel Alventosa’s Blog’ : Authentication and Authorization in JMX RMI connectors. Le cryptage par SSL est possible mais très lourd à mettre en place (génération de certificats)

Avec la JConsole, il existe alors deux moyens de se connecter :

Soit par l’onglet ‘Remote’ en précisant le nom ou l’adresse IP de la machine et le port spécifié par la propriété com.sun.management.jmxremote.port.
Soit par l’onglet ‘Advanced’ en spécifiant l’URL suivante : service:jmx:rmi:///jndi/rmi://192.168.199.131:7001:12345/jmxrmi. La construction de l’URL est en partie expliquée dans la javadoc de la classe JMXServiceURL. Les champs User Name et Password restent vides.

Avantages : Simplicité de mise en œuvre et de connexion (Onglet ‘Remote’).
Inconvénient : Sécurité.

IIOP

Java RMI Over IIOP permet de s’interfacer avec les ORB, spécifiés par CORBA (Common Object Request Broker Architecture). Les serveurs d’applications certifiés J2EE se doivent de supporter le protocole IIOP (RMI/IIOP). Pour connecter une JConsole sur un serveur d’applications WebLogic 9.x avec le protocole IIOP, il est nécessaire d’activer ce protocole et de déclarer un utilisateur afin de s’authentifier. La procédure est décrite ici. La JVM nécessite d’être démarrée avec l’option :

-Dcom.sun.management.jmxremote

Dans la JConsole, il est faut utiliser l’onglet ‘Advanced’ et indiquer l’url suivante :
service:jmx:rmi:///jndi/iiop://192.168.199.131:7001/weblogic.management.mbeanservers.runtime

Avantage : -
Inconvénients : Compliqué à paramétrer, complexité liée au protocole IIOP.

T3

J2EE 1.0 n’imposait pas le support d’IIOP. BEA a alors mis au point T3, un protocole propriétaire plus performant. Depuis, le protocole T3 est le protocole par défaut pour accéder aux différents objets distants hébergés sur un serveur d’applications WebLogic. Puisque T3 implémente RMI, il est possible de brancher la JConsole à une JVM avec T3.

Tout d’abord il faut :

Ajouter le jar weblogic.jar au lancement de la JConsole.
Indiquer les ‘ClientProviders’ fournis par BEA (propriété jmx.remote.protocol.provider.pkgs).

[CODE]
set JAVA_HOME=D:\bea\alsb21\jdk150_04
%JAVA_HOME%\bin\jconsole.exe
-J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote -J-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;D:\bea\alsb21\weblogic91\server\lib\weblogic.jar;%JAVA_HOME%\lib\tools.jar

[/CODE]

Pour se connecter, il faut utiliser le mode 'advanced' et indiquer :

JMXURL : service:jmx:t3://192.168.199.131:7001/jndi/weblogic.management.mbeanservers.runtime
UserName : weblogic
Password : ********

Il faut que l'utilisateur possède les droits d'administration.

Après activation des logs et analyse j'ai remarqué que les credentials (UserName et Password) n'étaient pas transférés au moment du lookup de l'objet MBeanServer. Pour y remédier, il suffit d'écrire un nouveau 'ClientProvider' du protocole T3 qui va effectuer cette manipulation : transfert de la propriété 'jmx.remote.credentials' vers 'java.naming.security.principal' et 'java.naming.security.credentials'.

[JAVA]
package fr.xebia.jmx.remote.t3;

import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

import javax.management.remote.JMXConnector;
import javax.management.remote.JMXServiceURL;

public class ClientProvider extends
weblogic.management.remote.t3.ClientProvider {

public JMXConnector newJMXConnector(JMXServiceURL jmxserviceurl, Map map)
throws IOException {
Map newMap = checkCredentials(map);
return super.newJMXConnector(jmxserviceurl, newMap);
}

@SuppressWarnings("unchecked")
private Map checkCredentials(Map map) {
if (!map.containsKey("java.naming.security.principal")
&& !map.containsKey("java.naming.security.credentials")) {
if (map.containsKey("jmx.remote.credentials")) {
Map newMap = new HashMap();
newMap.putAll(map);
String[] cred = (String[]) map.get("jmx.remote.credentials");
newMap.put("java.naming.security.principal", cred[0]);
newMap.put("java.naming.security.credentials", cred[1]);
return newMap;
}
}
return map;
}
}

[/JAVA]

Il faut ensuite ajuster la ligne de commande (ajout de la classe fr.xebia.jmx.remote.t3.ClientProvider au classpath et modification de la propriété jmx.remote.protocol.provider.pkgs).

[CODE]
set JAVA_HOME=D:\bea\alsb21\jdk150_04
%JAVA_HOME%\bin\jconsole.exe
-J-Djmx.remote.protocol.provider.pkgs=fr.xebia.jmx
-J-Djava.class.path=t3jconsole.jar,%JAVA_HOME%\lib\jconsole.jar;D:\bea\alsb21\weblogic91\server\lib\weblogic.jar;%JAVA_HOME%\lib\tools.jar
[/CODE]

Avec les mêmes informations rentrées dans l'onglet 'Advanced', vous serez maintenant connecté à votre serveur d'applications WebLogic 9 avec la JConsole en utilisant le protocole T3.

Avantage : Pas de paramétrage supplémentaire (l'activation du protocole IIOP et la déclaration du user IIOP nécessitent un redémarrage du serveur).
Inconvénient : Il est impossible de brancher la JConsole avant que le serveur soit 'Running', donc pas de suivi du démarrage du serveur.

Conclusion

La JConsole permet rapidement de voir le comportement mémoire, le CPU et les traitements d'un serveur d'applications. Désormais, pensez à ajouter le '-Dcom.sun.management.jmxremote' sur l'ensemble de vos JVM 5.0 afin de permettre un diagnostic rapide en cas de problème.

Références

JMX et JConsole au labo Sun de Sup Info.
Using jconsole sur le site de Sun.
Fichier T3Console.Jar (.java et .class)

WebLogic Scripting Tools

Benoit Moussaud — Wed, 09 May 2007 12:33:05 +0000

Dans un post précédent, j’ai expliqué comment exposer un MBean avec Spring dans WebLogic Server 8.1. Je vais vous montrer comment interagir avec ce MBean avec WLST.

WebLogic Scripting Tool (WLST) est un outil en ligne de commande qui permet de surveiller et gérer des instances WebLogic Server. Cet outil de scripting est basé sur le langage Jython[1], une implémentation du langage Python 100% Java. A l’origine, cet outil a été développé pour WebLogic 8.1.x. Il est disponible en version 5.4 [2] sur le site CodeShare, le repository des projets open source liés au monde des serveurs WebLogic. A partir de la version 9.0 de WebLogic Server, WLST a été intégré à la distribution et est complètement supporté par BEA.

Avec WLST il est possible :

De parcourir la configuration d’un domaine et ses paramètres runtime.
D’éditer la configuration d’un domaine et de sauvegarder ces modifications.
D’accéder à l’ensemble des MBean du serveur (MBean WebLogic, MBean WebLogic Integration, Mbean WebLogic Portal, MBean défini par les utilisateurs).
D’automatiser les procédures de déploiement d’application et de configuration.

Procédure d’installation de WLST pour WebLogic 8.1 :

Télécharger wlst_v64.zip
Extraire l’archive dans un répertoire (ex c:\wlst)
Créer un script de lancement (ex c:\wlst\wlst.cmd)

title WLST set WL_HOME=D:\bea\bea815\weblogic81 Set JAVA_HOME=D:\bea\bea815\jdk142_08 set WLST_HOME=c:\wlst set CLASSPATH=%WLST_HOME%\wlst.jar;%WLST_HOME%\jython.jar;%WL_HOME%\server\lib\weblogic.jar %JAVA_HOME%\bin\java weblogic.WLST %*

Lancer le script wlst.cmd

Note : pour les utilisateurs d’un serveur WebLogic 9.x, le script de lancement se trouve dans le répertoire %WL_HOME%\common\bin\wlst.cmd

Au lancement vous devez obtenir :
Initializing WebLogic Scripting Tool (WLST) ... Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands wls:/(offline)>

La première étape est de se connecter à un serveur. Cette action s’effectue avec la commande connect(login, password, url). Si votre domaine comporte un serveur d’admin et des serveurs managés, il est préférable de se connecter au serveur d’administration qui vous donnera l’accès à l’ensemble des serveurs du domaine.
wls:/(offline)> connect('weblogic','weblogic','t3://localhost:7001') Connecting to weblogic server instance running at t3://localhost:7001 as username weblogic ... Successfully connected to Admin Server 'myserver' that belongs to domain 'wlsdomain'. wls:/wlsdomain/config>

A partir de là, vous pouvez parcourir l’ensemble du domaine avec les commandes ls() et cd().
wls:/wlsdomain/config> ls(); drw- ApplicationManager drw- Applications drw- BasicRealms drw- BridgeDestination drw- BridgeDestinationCommon drw- CachingRealms drw- Clusters drw- ConversationService drw- CustomRealm ….. -rw- AdministrationMBeanAuditingEnabled false -rw- AdministrationPort 9002 -rw- AdministrationPortEnabled false -rw- ArchiveConfigurationCount 5 -r-- CachingDisabled true ...La commande affiche les différents paramètres avec leur mode d’accès (r:read, w:write, d: répertoire). Le contenu d’un élément de type d peut etre accédé avec la commande cd()
wls:/wlsdomain/config> cd ('Servers') wls:/wlsdomain/config/Servers> ls() drw- myserver wls:/wlsdomain/config/Servers> cd('ExecuteQueues/weblogic.kernel.Default') wls:/wlsdomain/config/Servers/myserver/ExecuteQueues/weblogic.kernel.Default>

L’appel à la commande ls() affiche l’ensemble des paramètres liés à la queue d’exécution ‘weblogic.kernel.Default’.

Les commandes get() et set() permettent de manipuler les paramètres des Mbean. En effet, les fonctions offertes par les différentes consoles d’administration de WebLogic Platform ne sont en réalité que des appels à des Mbeans fournis par le serveur WebLogic. Tout ce vous pouvez faire avec la console, vous pouvez le faire avec WLST.

Exemple de modification de la valeur ‘ThreadCount’.
wls:/wlsdomain/config/Servers/myserver/ExecuteQueues/weblogic.kernel.Default> get('ThreadCount') 15 wls:/wlsdomain/config/Servers/myserver/ExecuteQueues/weblogic.kernel.Default> set('ThreadCount','20') wls:/wlsdomain/config/Servers/myserver/ExecuteQueues/weblogic.kernel.Default> get('ThreadCount') 20

L’une des grandes forces de WLST est sa capacité à exécuter des scripts afin de rendre automatisable l’ensemble des opérations d’administration.
Dans le répertoire d’installation de WLST, créer un fichier texte : ex1.py

connect('weblogic','weblogic','t3://localhost:7001')
cd ('/Servers/myserver/ExecuteQueues/weblogic.kernel.Default')
print "Afficher le nombre de thread:"+str(get('ThreadCount'))
set('ThreadCount','25')
disconnect()

Lancez une autre instance de l’interpréteur WLST et exécuter le script ex1.py
wls:/(offline)> execfile('ex1.py') Connecting to weblogic server instance running at t3://localhost:7001 as username weblogic ... Successfully connected to Admin Server 'myserver' that belongs to domain 'wlsdomain'. Afficher le nombre de thread:20 Disconnected from weblogic server: myserver wls:/(offline)>
Si vous retournez sur le précédent interpréteur WLST et exécutez la commande get(‘ThreadCount’), la valeur ’25′ devrait apparaître.

Le script suivant ex2.py exécute la même opération que ex1.py en définissant une fonction python. Attention, en python, l’indentation fait partie du langage !

def modifierThreadCount(executequeue, valeur):
cd ('/Servers/myserver/ExecuteQueues/'+executequeue)
print "Afficher le nombre de thread:"+str(get('ThreadCount'))
set('ThreadCount',valeur)
connect('weblogic','weblogic','t3://localhost:7001')
modifierThreadCount('weblogic.kernel.Default',15)
disconnect()

wls:/(offline)> execfile('ex2.py')

Revenons à notre MBean développé précédemment. WLST permet de manipuler non seulement les MBeans BEA mais également nos propres MBeans. Le script suivant recherche les MBeans à partir d’un nom (), de lire et modifier les attributs.

def manipulation():
#recherche de tous les MBeans qui portent le nom 'testBean', quelque soit le package.
testBeans = mbs.queryMBeans(ObjectName("*:*,name=testBean"), None)
#parcours de la liste de resultat
for tb in testBeans:
#affichage de l'objectName
objectName = tb.getObjectName()
print 'ObjectName : '+str(objectName)
print 'Lecture des Attributs Age et Name'
age = mbs.getAttribute(objectName,"Age");
name = mbs.getAttribute(objectName,"Name");
print "Age="+str(age)+", Name="+name
#Modification des valeurs
print "Modification de l'attribut Name"
mbs.setAttribute(objectName,Attribute('Name','J2EE'));
print "La nouvelle valeur de l'attribut Name est "+mbs.getAttribute(objectName,"Name")
connect('weblogic','weblogic','t3://localhost:7001')
manipulation()
disconnect()

Différentes remarques :

Ce script est la transposition de la classe de test Java test.xebia.management.JMXClient3
La recherche n’est pas limitée au nom d’un Mbean, il est également possible d’effectuer des recherches par type
La variable ‘mbs’ est une variable globale définie par WLST, elle correspond à la position courante dans la hiérarchie des MBeans. L’ensemble des variables est documenté sur cette page[4]

L’exécution de ce script donne le résultat suivant :
wls:/(offline)> execfile('ex3.py') Connecting to weblogic server instance running at t3://localhost:7001 as username weblogic ... Successfully connected to Admin Server 'myserver' that belongs to domain 'wlsdomain'. ObjectName : bean:name=testBean Lecture des Attributs Age et Name Age=2, Name=xebia Modification de l'attribut Name La nouvelle valeur de l'attribut Name est J2EE Disconnected from weblogic server: myserver wls:/(offline)>

L’ajout de WLST à la plateforme WebLogic est une bonne évolution vers une réelle industrialisation des serveurs d’applications de la gamme BEA. Il existe un autre mode d’interaction proposé par WLST : WLST Offline. Il permet de créer et de paramétrer des domaines WebLogic sans être connecté. Ce mode est l’équivalent de ce que propose le domaine ‘Wizard’.

Source: scripts WLST [zip]

Référence:

[1] http://www.jyton.org

[2] WLST 8.4 pour WLS 8.1

https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=S13

[3] Documentation 9.x

http://e-docs.bea.com/wls/docs90/config_scripting/using_WLST.html

[4] WLST Variable Reference

http://e-docs.bea.com/wls/docs92/config_scripting/reference.html#wp1178147

Le top 10 des problèmes de performances des applications J2EE

Benoit Moussaud — Thu, 03 May 2007 12:38:22 +0000

Depuis deux mois et demi, Vincent Partington a déroulé sur le blog de Xebia.com, les 10 principaux problèmes de performance des applications Java / J2EE. Voici le classement:

#10 – Logging excessif
#09 – Mauvaise configuration du serveur d’application
#08 – Usage incorrecte de Java EE
#07 – Utilisation abusive du XML
#06 – Mauvaise utilisation des fonctions de ‘Cache’
#05 – Consommation mémoire
#04 – Mauvaises performances des bibliothèques tierces
#03 – Mauvaise gestion de la concurrence
#02 – Utilisation abusive de la distribution
#01 – Mauvaise utilisation de la base de données

De ce classement, Vincent Partington tire les conclusions suivantes:

Tout d’abord, les architectes et développeurs Java devraient considérer la performance comme une exigence de leur application, à toutes les étapes du projet.
Ensuite, les équipes de développement ont besoin de collaborer avec des personnes qui peuvent les aider à améliorer les performances de leurs applications, en particulier les administrateurs de serveurs d’applications et les DBA.
Enfin, la performance requiert des connaissances dans un grand nombre de domaines, dont ce Top Ten met en avant les plus critiques. Pour un tour d’horizon plus complet, un bon point de départ est le site web the Java Performance Tuning

Exposer un MBean avec Spring dans WebLogic Server 8.1

Benoit Moussaud — Wed, 21 Feb 2007 12:06:57 +0000

La spécification liée aux extensions de management, plus connue sous le nom de JMX est l’un des plus ancienne du JCP. Elle porte le n°3. Cependant, elle n’a été validée qu’en Juillet 2000 et communément utilisée que très récemment. Il a fallut attendre les serveurs d’application J2EE 1.4 ou le JSE 5 pour voir cette technologie devenir massivement diffusée en version 1.2. Auparavant chaque éditeur proposait sa propre implémentation avec des versions incompatibles entre elles.

Le serveur d’application WebLogic 8.1 utilise massivement cette technologie pour permettre de configurer et monitorer les serveurs. La console d’administration n’est qu’une interface graphique à ces MBeans (Management Bean). Cependant il peut être intéressant d’exposer des MBean supplémentaires :

MBean type ‘Facade’ : Aggregation de MBeans existants pour unifier la gestion et limiter les appels
MBean type ‘Composite’ : Exposition de méthodes de haut niveau qui synthétisent un ensemble de MBean et de données techniques
MBean type ‘Applicatifs’ : Interface de gestion non plus au niveau technique (serveur d’application) mais fonctionelle

Voici donc les étapes à suivre et les pièges à éviter pour exposer un MBean avec le framework Spring 2.0 dans WebLogic 8.1. L’environnement de développement est Eclipse 3.2 avec WTP.

Créons un projet de type ‘Dynamic Web Project’ (nom WeblogicSpringMBean) avec le target runtime ‘Generic BEA WebLogic Server 8.1′
Ajoutons au répertoire WEB-INF/lib, les bibliothèque spring.jar et common-logging.jar.
Implémentons notre MBean de test (très simple): fr.xebia.management.InfoMBean

package fr.xebia.management;
public class InfoMBean {
	private String name;
	private int age;
	public int getAge() {
		return age;
	}
	public void setAge(int age) {
		this.age = age;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
}

Le framework Spring va nous permettre d’assembler et d’exposer ce MBean.

Créons dans le répertoire WEB-INF le fichier d’assemblage Spring applicationContext.xml
Déclarons le bean associé au MBean InfoMBean

Déclarons le server de MBeans de WebLogic

Déclarons le bean qui va permettre d’exposer le bean en tant que MBean (org.springframework.jmx.export.MBeanExporter)

Il reste à paramétrer le fichier web.xml pour permettre de charger cette configuration au démarrage du serveur. La servlet org.springframework.web.context.ContextLoaderServlet va se charger, au démarrage, d’assembler les beans à partir du fichier applicationContext.xml et d’exposer le MBean.



  WebLogicSpringMBean
  
	context
	org.springframework.web.context.ContextLoaderServlet
	1

Si on se base sur les différentes documentations [1] c’est terminé.
Dans l’environnement Eclipse, démarrer le serveur et deployer l’application (La commande ‘Run On Server’ se charge des deux opérations).

Première Difficulté : Lors du déploiement de l’application WeblogicSpringMBean.war, le serveur répond :

javax.servlet.ServletException: Error creating bean with name 'weblogicMBeanServer' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is org.springframework.jmx.MBeanServerNotFoundException: Could not find WebLogic's MBeanHome object in JNDI; nested exception is javax.naming.NoPermissionException: User does not have permission on weblogic.management.home to perform lookup operation.

Solution :il faut exécuter la servlet avec le rôle Admin

Editer le fichier web.xml pour déclarer le rôle admin


	WebLogicSpringMBean
	
		context
		org.springframework.web.context.ContextLoaderServlet
		1
		
			admin
		
	
	
		admin

Créer dans le répertoire WEB-INF un fichier weblogic.xml qui va associer le rôle admin avec le user weblogic


	
		admin
		weblogic

Redéployer l’application

Ecrivons un client de test pour interroger notre MBean. Pour des soucis de commodités, nous allons le coder dans le même projet que notre MBean. Le code suivant permet retrouver tous les MBean dont le nom est ‘testBean’.

public static void main(String[] args) throws Exception {
	Environment env = new Environment();
	env.setProviderUrl("t3://localhost:7001");
	env.setSecurityPrincipal("weblogic");
	env.setSecurityCredentials("weblogic");
	Context ctx = env.getInitialContext();
	System.out.println("Recherche du MBeanHome");
	MBeanHome home  = (MBeanHome) ctx.lookup(MBeanHome.LOCAL_JNDI_NAME);
	RemoteMBeanServer server = home.getMBeanServer();
	System.out.println("Recherche de tous les MBeans dont le nom est 'testBean' [*:*,name=testBean]");
	Set results = server.queryMBeans(new ObjectName("*:*,name=testBean"),
			null);
	for (Iterator iter = results.iterator(); iter.hasNext();) {
		ObjectInstance oi = (ObjectInstance) iter.next();
		ObjectName objectName = oi.getObjectName();
		System.out.println(objectName);
	}
}

Sur la sortie console on obtient :

Recherche du MBeanHome Recherche de tous les MBeans dont le nom est 'testBean' [*:*,name=testBean] bean:name=testBean

Donc notre MBean est exposé sur le serveur WebLogic.

Rajoutons une ligne de code pour obtenir la valeur de l’attribut MBean (JMXClient2.java)

for (Iterator iter = results.iterator(); iter.hasNext();) {
  ObjectInstance oi = (ObjectInstance) iter.next();
  ObjectName objectName = oi.getObjectName();
  System.out.println(objectName);
  System.out.println(server.getAttribute(objectName, "Name"));
  System.out.println(server.getAttribute(objectName, "Age"));
}

Deuxième Difficulté : Sur l’appel de la méthode server.getAttribute(), le serveur lance une Exception :

javax.management.ReflectionException: The target object class class javax.management.modelmbean.ModelMBeanOperationInfo could not be found.

Cette exception indique un problème lié au code de WebLogic géré par le classloader système qui doit accéder à une classe chargée par le classloader de l’application Web. Le classloader d’un module J2EE (jar,war,ear) dérive du classloader système, et non l’inverse.

Solution : D’après le Bug Tracker de Spring [2], il faut, pour exposer notre MBean, utiliser une bibliothèque tierce packagée dans l’application Web: Le projet Apache Common Modeler [3]

Copions le fichier commons-modeler-2.0.jar dans le répertoire WEB-INF/lib
Dérivons la classe org.springframework.jmx.export.MBeanExporter et surchargeons la méthode createModelMBean()

package fr.xebia.management;
import javax.management.MBeanException;
import javax.management.modelmbean.ModelMBean;
import org.springframework.jmx.export.MBeanExporter;
public class CommonModelerBeanExporter extends MBeanExporter {
	protected ModelMBean createModelMBean() throws MBeanException {
		return new org.apache.commons.modeler.BaseModelMBean();
	}
}

Modifions l’assemblage Spring pour utiliser cette classe à la place MBeanExporter

Apres avoir redéployé l’application, le client de test JMXClient2.java permet d’afficher la valeur de l’attribut ‘Name’ et ‘Age’ du MBean

class test.xebia.management.JMXClient2 Recherche du MBeanHome Recherche de tous les MBeans dont le nom est 'testBean' [*:*,name=testBean] bean:name=testBean 2

Les valeurs affichées sont celles indiqués dans le fichier d’assemblage Spring.

Le client de test JMXClient3 modifie la valeur des attribut du MBean.

class test.xebia.management.JMXClient3 Recherche du MBeanHome Recherche de tous les MBeans dont le nom est 'testBean' [*:*,name=testBean] bean:name=testBean Modification de l'attribut Name=J2EE Modification de l'attribut Age=4

Si on relance le client de test JMXClient2, on doit obtenir les valeur J2EE et 4: L’instance du MBean est unique sur le server WebLogic.

class test.xebia.management.JMXClient2 Recherche du MBeanHome Recherche de tous les MBeans dont le nom est 'testBean' [*:*,name=testBean] bean:name=testBean J2EE 4

Le projet Eclipse est disponible : weblogicspringmbean.zip. Il n’inclut pas le fichier spring.jar.

Avec le support en natif par la JVM, la technologie JMX va devenir de plus en plus présente dans les applications J2EE pour offrir une gestion à deux niveaux :

gestion technique : paramétrage de niveaux de log, accès à des statistiques (Pools de Connexion, Transaction, …)
gestion fonctionnelle : par exemple, l’application va pouvoir exposer elle-même des indicateurs à destinations des utilisateurs et pilotes fonctionnels. Aujourd’hui, ces indicateurs sont généralement calculés à grands coups de requêtes dans la base de données.

Un prochain post montrera comment accéder à ce bean en utilisant le langage WLST (WebLogic Scripting Tool).

Référence:

[1] Documentation Spring 2.0 JMX
[2] JIRA Spring
[3] Apache Common Modeler

Java Open Source : ce qui va changer

Benoit Moussaud — Wed, 15 Nov 2006 15:58:15 +0000

Sun l’a annoncé hier: la nouvelle license de Java (langage, compilateur) est la license GPL, la plus ouverte des licence du monde open source. Cette annonce n’est pas une révolution mais une évolution naturelle de Java. Cette nouvelle va, par exemple, permettre de placer la JVM au coeur des distributions Linux, voire même au niveau Kernel.

Guillaume Bodet, directeur technique de Xebia, répond aux questions d’Olivier Rafal (Le Monde Informatique) concernant les impacts et les conséquences de cette nouvelle licence.