14 prises de notes à Devoxx France 2014

Wed, 23 Apr 2014 15:28:37 +0000

En attendant que les vidéos des différentes conférences de l’édition 2014 de Devoxx France soient mises en ligne sur Parleys et en complément des supports déjà mis en ligne par certains Speakers, je mets librement à votre disposition les différentes notes que j’ai pu prendre sur mon laptop. Les sujets sont variés : de Docker à Angular JS, en passant par Java 8. Certaines pourront être lues de manière autonome ; je pense par exemple au quickie Outils pour manager une équipe et à la conférence 33 things your want to do better. Pour être exploitables en l’état, d’autres notes demanderont à ce que vous ayez assisté à la conférence ou que vous ayez pu récupérer les supports de présentation.

Isoler le classloader de son EAR sous JBoss

Sat, 05 Jan 2013 09:41:40 +0000

Lors de la migration d’une application d’un serveur d’application vers un autre, il est fréquent d’être confronté à des problématiques de conflits de librairies. C’est par exemple le cas lorsqu’une application initialement déployée sur un Websphere Application Server 6.1 doit migrer sur JBoss 5.1 EAP (version commerciale de JBoss AS). Pour rappel, WAS 6.1 implémente J2EE 1.4 et s’exécute donc sur Java 5. Quant à JBoss 5.1 EAP, il implémente la norme Java EE 5, embarque donc de nombreuses implémentations des standards tels que JPA 1, JSF 1.2 et JAX-WS 1, et tourne sur Java 6.

Pour illustration, prenons une application s’appuyant sur Hibernate 3.6 pour sa couche de persistance et JAXB 2.2 pour le marshalling lors d’appel de web services. Ces 2 librairies sont embarquées dans le répertoire lib de son EAR et ne posent pas de problèmes particuliers à WAS 6.1. Par contre, sur JBoss 5.1 EAP, c’est un tout autre problème. En effet, son implémentation JPA repose sur la version 3.3 d’Hibernate. Qui plus est, JAXB 2.1 a été intégrée dans Java 6. Si vous tentez de déployer une telle application sur un JBoss installé avec la configuration par défaut, il y’a de fortes chances que vous tombiez sur l’une ou l’autre des exceptions suivantes : ClassCastException, NoSuchMethodException, IllegalAccessErrors, VerifyError. A ce que j’ai compris en parcourant la documentation mais également déduis de mes tests, différents mécanismes permettent d’expliquer ces comportements :

Par défaut, lors du chargement d’une classe, le classloader de l’EAR va commencer par demander à son classloader parent (en l’occurrence celui de JBoss) de trouver la classe. Ainsi, c’est par exemple la classe Session d’Hibernate 3.3 qui sera chargée et non celle de la version 3.6 comme attendu. Il s’agit du comportement standard d’un classloader. Et c’est ce qu’on appelle communément le « j2se classloading compliance ». Sous WAS, cette stratégie de chargement peut être changée en paramétrant le classloader en PARENT_LAST.
Les classes chargées par d’autres applications déployées sur la même instance de JBoss peuvent être partagées par votre application. Par exemple, la console d’admin JBoss admin-console.war embarque sa propre version de Richfaces et de Seam et peut, malgré elle, vous en faire bénéficier.

Solutions étudiées

Pour mener à bien la migration, plusieurs pistes ont été étudiées : SolutionsInconvénientsAvantages1Downgrader les versions des frameworks pour utiliser celles embarquées dans JBoss 5.1Important travail de refactoring pour combler les fonctionnalités manquantes. Bugs existants récupérés.Respect de la norme Java EE 5. Support éditeur maximal.2Configurer sur mesure le répertoire d’installation de JBoss (ex : supprimer le support des EJB 3 et de JPA)Mutualisation du répertoire d’installation rendue caduque. Main sur la production _._Un JBoss qui démarre plus vite. Pas d’impact sur le code.3Isoler le déploiement de l’applicationLire la documentation JBoss. Augmentation possible de la PermGen.Risque nul. Simple configuration. Configuration embarquée dans l’EAR.

Configurer le classloader de l’application

Pour mettre en œuvre la solution n°3 concernant à « scoper » l’application, il est nécessaire de configurer le chargement des classes de JBoss . Une description détaillée de son fonctionnement est disponible sur la page JBossClassLoadingUseCases du wiki de JBoss. Dans notre cas, La configuration des classes loaders nécessaire est deployment scoped et Java2ParentDelegation désactivé. Cette configuration est représentée par la figure ci-contre.

Cette configuration présente les 2 avantages suivants :

Les JARs embarqués dans l’EAR priment sur celles fournies par JBoss 5.1 et le JRE.
Chaque application déployée sur le même serveur possède son propre UnifiedLoaderRepository (ULR). Le chargement des classes est isolé et n’interfère pas. Elles sont également isolées du chargement des applications tierces (ex: jmx-console et admin-console).

La configuration du fichier jboss-app.xml à déposer dans le répertoire META-INF de l’EAR est décrite sur la page ClassLoadingConfiguration du wiki JBoss. En voici un exemple : Lors de la migration d’une application d’un serveur d’application vers un autre, il est fréquent d’être confronté à des problématiques de conflits de librairies. C’est par exemple le cas lorsqu’une application initialement déployée sur un Websphere Application Server 6.1 doit migrer sur JBoss 5.1 EAP (version commerciale de JBoss AS). Pour rappel, WAS 6.1 implémente J2EE 1.4 et s’exécute donc sur Java 5. Quant à JBoss 5.1 EAP, il implémente la norme Java EE 5, embarque donc de nombreuses implémentations des standards tels que JPA 1, JSF 1.2 et JAX-WS 1, et tourne sur Java 6.

Classloader on Java & Moi

14 prises de notes à Devoxx France 2014

Isoler le classloader de son EAR sous JBoss

Solutions étudiées

Configurer le classloader de l’application