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.
Lire la suite de cet article »
« 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 »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
Le coin de la technique
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 »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Lire la suite de cet article »
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 »
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 »
Complet
Twitter
