« 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.
Lire la suite de cet article »
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.
Lire la suite de cet article »
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.
Lire la suite de cet article »
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).
Lire la suite de cet article »
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 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 :
Lire la suite de cet article »
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.
Lire la suite de cet article »
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:
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
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
Lire la suite de cet article »
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.
Complet
Twitter
