• 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
<Jul 25, 2008 4:03:48 PM MEST> <Info> <Store> <BEA-280050> <Persistent store "FileStore_auto_1" opened: directory="FileStore_auto_1" writePolicy="Cache-Flush" blockSize=512 direc tIO=false driver="NIO">
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.

<PersistentStore Name="FileStore_auto_1" Open="true">
  <IOLayer>
    <FileStore Directory="FileStore_auto_1" WritePolicy="Cache-Flush" BlockSize="452" SupportOSDirectIO="false" HeapVersion="2"></FileStore>
  </IOLayer>
  <Statistics>
    <NumObjects>36737</NumObjects>
    <Creates>0</Creates>
    <Reads>0</Reads>
    <Updates>0</Updates>
    <Deletes>0</Deletes>
    <PhysicalWrites>0</PhysicalWrites>
    <PhysicalReads>0</PhysicalReads>
  </Statistics>
....
</PersistentStore>

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 !

<Connection Name="weblogic.messaging.wlsbJMSServer_auto_1.header" Kind="normal" Typecode="3">
  <Statistics>
    <NumObjects>0</NumObjects>
    <Creates>0</Creates>
    <Reads>0</Reads>
    <Updates>0</Updates>
    <Deletes>0</Deletes>
  </Statistics>
  <Records>
    <Record TypeCode="3" SlotNum="1798" HandleNum="2490510606351" FileNum="0" BlockNum="148446" NumBlocks="15">
      <RecordContents>    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/
<Jul 25, 2008 4:26:16 PM MEST> <Info> <Store> <BEA-280050> <Persistent store "FILESTORE_AUTO_1" opened: directory="/var/weblogic/STOREADMIN_46757" writePolicy="Cache-Flush" blockSize=512 directIO=false driver="NIO">
INFO: Original FileStore_auto_1 moved to /var/weblogic/STOREADMIN_46757
INFO: Compacting store ... FILESTORE_AUTO_1
INFO: Store FILESTORE_AUTO_1 opened successfully
<Jul 25, 2008 4:26:21 PM MEST> <Info> <Store> <BEA-280050> <Persistent store "STOREADMIN_FILESTORE_AUTO_1" opened: directory="FileStore_auto_1" writePolicy="Cache-Flush" blockSize=512 directIO=false driver="NIO">
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

(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> <Info> <J2EE Deployment SPI> <BEA-260072> <Saved configuration for application, MyWebApplicationEAR.ear>
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)

<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-deployment-plan.xsd"
 global-variables="false">
  <application-name>MyWebApplicationEAR.ear</application-name>
  <!-- Descripteurs portés par l'EAR -->
  <module-override>
    <module-name>MyWebApplicationEAR.ear</module-name>
    <module-type>ear</module-type>
    <module-descriptor external="false">
      <root-element>weblogic-application</root-element>
      <uri>META-INF/weblogic-application.xml</uri>
    </module-descriptor>
    <module-descriptor external="false">
      <root-element>application</root-element>
      <uri>META-INF/application.xml</uri>
    </module-descriptor>
    <module-descriptor external="false">
      <root-element>jdbc-data-source</root-element>
      <uri>META-INF/ds-jdbc.xml</uri>
    </module-descriptor>
  </module-override>
  <!-- Descripteurs portés par le WAR-->
  <module-override>
    <module-name>MyWebApplication.war</module-name>
    <module-type>war</module-type>
    <module-descriptor external="false">
      <root-element>weblogic-web-app</root-element>
      <uri>WEB-INF/weblogic.xml</uri>
    </module-descriptor>
    <module-descriptor external="false">
      <root-element>web-app</root-element>
      <uri>WEB-INF/web.xml</uri>
    </module-descriptor>
  </module-override>
  <config-root xsi:nil="true"></config-root>
</deployment-plan>

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.

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

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

Paramétrage pour un environnement de Recette.

1. Sélectionner le module MyWebApplicationDS
2. 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.
3. 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 <variable-definition/>. Il contient un ensemble de couples de variables (name, value) qui correspondent aux paramètres modifiés

<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ...>
  <application-name>MyWebApplicationEAR</application-name>
  <!-- Bloc Variable Definition -->
  <variable-definition>
    <variable>
      <name>JDBCDriverParams_PasswordEncrypted_12040376123280</name>
      <value>{3DES}QZJ2MfqOliA=</value>
    </variable>
    <variable>
      <name>JDBCConnectionPoolParams_MaxCapacity_12040378132185</name>
      <value>10</value>
    </variable>
    <variable>
      <name>JDBCProperty_user_Value_12040378358436</name>
      <value>recette</value>
    </variable>
    <variable>
      <name>SessionDescriptor_timeoutSecs_12040384414060</name>
      <value>360</value>
    </variable>
  </variable-definition>
  .....
</deployment-plan>

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

<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ...>
....
   <module-descriptor external="false">
      <root-element>jdbc-data-source</root-element>
      <uri>META-INF/ds-jdbc.xml</uri>
      <variable-assignment>
        <name>JDBCDriverParams_PasswordEncrypted_12040376123280</name>
        <xpath>/jdbc-data-source/jdbc-driver-params/password-encrypted</xpath>
      </variable-assignment>
      <variable-assignment>
        <name>JDBCConnectionPoolParams_MaxCapacity_12040378132185</name>
        <xpath>/jdbc-data-source/jdbc-connection-pool-params/max-capacity</xpath>
      </variable-assignment>
      <variable-assignment>
        <name>JDBCProperty_user_Value_12040378358436</name>
        <xpath>/jdbc-data-source/jdbc-driver-params/properties/property/[name="user"]/value</xpath>
      </variable-assignment>
    </module-descriptor>
....
</deployment-plan>

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

Actualité éditeurs / SSII

• GlassFish et MySQL, premiers signes d’intégration
• IBM investit dans EnterpriseDB
• DomainHealth : Un outil de monitoring pour les serveurs Weblogic (9 & 10)

Agilité

• Certification ScrumMaster, on en parle

Le coin de la technique

• Spring WS 1.5 : un fort potentiel à concrétiser
• Milestone 3 pour Spring Java Configuration

Actualité éditeurs / SSII

GlassFish et MySQL, premiers signes d’intégration

L’intégration de MySQL au groupe Sun Microsystem n’a pas tardé. Alexis Moussine-Pouchkine nous présente dans MySQL et GlassFish dans un bateau l’intégration du serveur Open Source Glassfish à la célèbre base de données. On y découvre notamment les tarifs des contrats de support et de maintenance, des éléments décisifs pour les équipes d’exploitation.

IBM investit dans EnterpriseDB

EnterpriseDB vient d’annoncer une levée de fonds de 10 millions de dollars, dont l’un des principaux investisseurs n’est autre que IBM. L’éditeur de DB2 justifie ce choix en rappellant ses investissements dans le monde open source sur des projets tels que Linux, Eclipse et Apache.

Ce choix peut peut-être aussi s’expliquer par le fait qu’EnterpriseDB édite Postgres Plus Advanced Server, qui se veut être un concurrent direct des bases de données Oracle. Produit commercial s’appuyant sur la base de données open source Postgresql (sous license BSD), Postgres Plus Advanced Server fournit entre autres des outils de migration pour Oracle.

Quelques liens :

• http://ostatic.com/158698-blog/enterprisedb-a-new-stake-from-ibm-and-its-novel-approach
• http://news.dzone.com/news/ibm-buys-enterprisedb
• http://developers.slashdot.org/article.pl?sid=08/03/25/207211&from=rss
• http://www.lemondeinformatique.fr/actualites/lire-ibm-injecte-de-l-argent-dans-enterprisedb-25697.html
• http://www.01net.com/editorial/375401/ibm-investit-dans-les-bases-de-donnees-open-source-d-enterprisedb/?rss

DomainHealth : Un outil de monitoring pour les serveurs Weblogic (9 & 10)

Dans cet article disponible sur le blog dev2dev de BEa, j’apprend l’existence d’un produit Open Source permettant de surveiller la bonne santé des serveurs Weblogic. Il permet entre autres de consulter la taille et l’utilisation de la Heap de la JVM, l’utilisation des pool de threads d’exécution, les datasources, les destinations JMS, les WorkManagers et beaucoup autres choses. Bea fournit déjà un outil similaire, une extension de la console d’administration qui permet d’obtenir ce type d’information basé sur le framework de diagnostiques de Weblogic (WLDF). Cependant, cette extension a quelques défaut que comble ‘DomainHealtn’:

• elle n’est pas activée par défaut, il faut ajouter un jar complémentaire dans un répertoire et redémmarer le serveur (DomainHealth se compose d’un simple war à déployer)
• elle ne propose pas de vue d’ensemble sur une page.

DomainHealth offre de parcourir les données collectées pendant toute la vie du domaine, quid de la consommation mémoire sur un domaine qui ne redémarre jamais ou très rarement ?

Bref un outil à tester et à surveiller ici !

Agilité

Certification ScrumMaster, on en parle

Xebia a organisé les 25 et 26 Mars 2008 une formation ScrumMaster certifiante, dispensée par Jeff Sutherland.
Premiers retours:

• http://www.touilleur-express.fr/2008/03/26/im-now-a-scrum-master/
• http://jefute.blogspot.com/2008/03/formation-scrum-master-la-dfense.html

Le coin de la technique

Spring WS 1.5 : un fort potentiel à concrétiser

Spring WS, arrivé bien après les leaders CXF (ex XFire), Axis2 et Metro (JAXWS-RI par Sun), se démarque par une approche originale qui préfère le Plain Old Xml à SOAP et cherche à s’affranchir des WSDL. Cette démarche en fait un bon candidat pour traiter les communications non-soap encore très nombreuses dans nos applications.
Arjen Poutsma nous présente dans What’s New in Spring Web Services 1.5? les nouvelles fonctionnalités du framework. On notera en particulier le support de JMS, de WS-Security et WS-Adressing.
Les points que nous avons aimé dans Spring-WS :

• L’ouverture aux communications non-SOAP (situation particulièrement fréquente pour les communications sur JMS)
• L’intégration à la stack Spring plus poussée que celle de CXF ou d’Axis2.
• La qualité de l’intégration à JAXB 2 avec le Jaxb2Marshaller qui est un modèle d’utilisation de cette API.

Les points que nous espérons pour les prochaines versions de Spring-WS :

• Un support naturel et documenté de l’approche wsdl2java avec un plugin maven similaire au cxf-codegen-plugin.
• Des points d’extension dans l’API pour enrichir les messages échangés (ajout du header JMS_IBM_Character_Set avec Websphere MQ, appel à Tibjms.setEncoding(Message, String) pout Tibco EMS, etc).
• Une documentation plus étoffée.

Milestone 3 pour Spring Java Configuration

Google avait défrayé la chronique en révélant Google Guice, le framework d’injection de dépendances d’Adwords dont la configuration est gérée avec du code Java plutôt qu’avec des fichiers XML.
SpringSource a répondu avec l’utilisation élargie des annotations dans Spring 2.5 (@Autowired, etc) et le lancement de Spring Java Configuration Project. Ce deuxième chantier avance plus lentement, probablement parce que le concurrent Google Guice reste peu utilisé et parce que la tâche s’avère très délicate.
Chris Beams nous présente les dernières évolutions dans Spring Java Configuration – What’s New in M3.
Nous avons été sensibles à :

• L’externalisation des variables (@ExternalValue) équivalent au PropertyPlaceholderConfigurer des configurations XML. Ce mécanisme, incomplet dans Google guice, est particulièrement important pour gérer les paramètres de configuration dont la valeur change suivant les environnements (développement, intégration, production, etc).
• L’étoffement de la documentation qui accorde notamment une place à l’intégration à Maven2.

Si l’utilisation de Spring JavaConfig n’est pas encore d’actualité, voici une bonne occasion de se pencher sur le XML Schema-based configuration introduite en version 2.5 qui allège avantageusement la gestion des configurations XML.

Ressource complémentaire : Spring Dependency Injection & Java 5 par Alef Arendsen ( slides, exemple source).

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.

<wls:module>
  <wls:name>MyWebApplicationDS</wls:name>
  <wls:type>JDBC</wls:type>
  <wls:path>META-INF/ds-jdbc.xml</wls:path>
</wls:module>

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:

<?xml version="1.0" encoding="UTF-8"?>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/90"
    xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls"
    xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/domain.xsd">
    <name>MyDevDataBase</name>
    <jdbc-driver-params>
        <url>jdbc:oracle:thin:@localhost:1521:xe</url>
        <driver-name>oracle.jdbc.OracleDriver</driver-name>
        <properties>
            <property>
                <name>user</name>
                <value>weblogic</value>
            </property>
        </properties>
        <password-encrypted>weblogic</password-encrypted>
    </jdbc-driver-params>
    <jdbc-connection-pool-params>
        <initial-capacity>1</initial-capacity>
        <max-capacity>5</max-capacity>
        <capacity-increment>1</capacity-increment>
        <shrink-frequency-seconds>900</shrink-frequency-seconds>
        <test-connections-on-reserve>true</test-connections-on-reserve>
        <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
    </jdbc-connection-pool-params>
    <jdbc-data-source-params>
        <jndi-name>MyDataSource</jndi-name>
        <scope>Global</scope>
    </jdbc-data-source-params>
</jdbc-data-source>

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)

  <resource-ref>
      <res-ref-name>MyDataSource</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
  </resource-ref>
  

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

  <jdbc-data-source>
    .....
    <jdbc-data-source-params>
          <jndi-name>MyDataSource</jndi-name>
          <scope>Application</scope>
      </jdbc-data-source-params>
  </jdbc-data-source>
  

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.

<password-encrypted>{3DES}QdEw5GGOy4GM/8QwBmTEbg==</password-encrypted>

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> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating distribute task for application 'MyWebApplicationEAR'.>
<26 févr. 2008 12 h 11 CET> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException:
at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:289)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:360)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:56)
Truncated. see log file for complete stacktrace
weblogic.common.ResourceException: weblogic.common.ResourceException: Could not create pool connection.
The DBMS driver exception was: Exception d'E/S: The Network Adapter could not establish the connection
at weblogic.jdbc.common.internal.ConnectionEnvFactory.createResource(ConnectionEnvFactory.java:236)
at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1073)
at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:995)
at weblogic.common.resourcepool.ResourcePoolImpl.start(ResourcePoolImpl.java:214)
at weblogic.jdbc.common.internal.ConnectionPool.doStart(ConnectionPool.java:1042)
Truncated. see log file for complete stacktrace
>

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

Actualité éditeurs / SSII

• Weblogic Server 10.3

Le coin de la technique

• Release de Seam 2.0
• Un vent de Websphere 7 chez IBM
• Apache Wicket 1.3.0-rc1 is released!

Actualité éditeurs / SSII

Weblogic Server 10.3

Cette nouvelle mouture du serveur d’application de BEA reste conforme aux spécifications J2EE 5 tout en ajoutant le support de Java SE 6. Donc peu de nouveautés technico-fonctionnelles, l’accent a été mis sur les performances. Cette version vient de sortir en mode ‘Tech Preview‘. La version 10.3 deviendrat-elle une version aussi performante et stable qu’est (ou fût) la version 8.1SP5+ ?

Le coin de la technique

Release de Seam 2.0

Pour rappel, Seam permet de mettre en des applications par le biais des technologies JSF, EJB 3, AJAX, BPM… Sa nouvelle version arrive avec ses lots de corrections et d’améliorations parmi lesquelles :

• possibilité d’écrire des composants Seam en Groovy
• intégration de GWT pour le rendering de page ou bien encore inclure des composants GWT dans une page JSF
• les composants Seam peuvent faire l’office de Web Service
• intégration de Hibernate Search
• syntaxe des EL améliorée

Un vent de Websphere 7 chez IBM

IBM nous prépare à Websphere 7, ses EJB3, sa persistance JPA et ses web services JAX-WS 2.0 en publiant le redbook Designing and Coding Applications for Performance and Scalability in WebSphere Application Server et en annonçant Rational Application Developer 7.5 Open Beta.

RAD 7.5, dont la beta sera disponible mi-décembre, apporte le support de support de Java EE 5 (EJB 3, JPA, JAX-WS, etc). La sortie de cette version, en avance sur Websphere 7, rassurera les clients RAD qui avaient été déçus par le décalage de plusieurs mois entre la sortie de WAS 6.1 et celle de RAD 7 (la v7 de RAD apportait le support de Java 5 et le WAS 6.1 runtime environment).

Designing and Coding Applications for Performance and Scalability in WebSphere Application Server est un RedBook de transition de l’ère des EJB 2.1 vers les nouveaux EJB 3.0 qui seront supportés par le futur Websphere 7 :

On y retrouve hélas quelques exemples légèrement défraîchis qui font penser à des copier/coller des redbooks précédents :

• Le chapitre sur l’utilisation des mécanismes de synchronisation (p99) mériteraient d’être réécrit en s’inspirant du très intéressant Google Tech Talk Advanced Topics in Programming Languages: The Java Memory Model de Jeremy Manson qui nous expliquent comment les blocs synchronized devraient être remplacé par les verrous introduis avec la librairie java.util.concurrent.locks
• Les exemples qui utilisent Vector et Hashtable pourraient avantageusement être mis à jour pour parler de List/ArrayList et de Map/HashMap
• Le paragraphe sur Struts et ses ActionForm pourrait être remplacé par son équivalent avec Struts2 ou être supprimé si IBM ne souhaite pas mettre en avant Struts2.

A côté de ces anachronismes mineurs, IBM nous livre les grands axes de la stratégie Websphere :

• SCA/SDO sont toujours des technologies clefs. Ce redbook nous explique avec clarté et raison leur rôle et leur position par rapport à EJB3/JPA : If you are developing a traditional (non SOA) application and only have relational data and are only developing in Java, then EJB 3.0 is a good choice. (p 449).
• Java Connector Architecture (JCA) est désormais la technologie standard et unifiée pour accéder aux Enterprise Information Systems (EIS) comme CICS et IMS dont les connecteurs Java propriétaires ont été remplacés par des Resources Adapter JCA [1]. Le support de l’API JCA permet une intégration élégante à SpringFramework [2].
• EJB3, JPA et JAX-WS sont les successeurs respectifs d’EJB 2.1, d’EJB CMP et de JAX-RPC ; ils sont disponibles avec WAS 6.1 sous forme de feature pack additionnels [3] ; Websphere 7 les embarquera en standard. Ce redbook sera une bonne introduction pour ceux qui n’ont pas encore eu le temps de découvrir ces nouvelles technologies.

Pour conclure, RAD 7.5 et ce redbook sont principalement des previews des technologies JavaEE 5 (EJB3, JPA, JAX-WS, etc) que nous attendons avec impatience et qui seront disponible avec Websphere 7.

D’ici à y voir les prémices d’une grande opération de teasing pour préparer l’imminente arrivée de Websphere 7 …

[1] Voir IMS TM Resource Adapter et CICS Transaction Gateway.
[2] Voir Access CICS applications with Spring par Thierry Templier pour JavaWorld.
[3] Voir WebSphere® Application Server Version 6.1 Feature Pack for EJB 3.0 et Feature Pack for Web Services for WebSphere Application Server V6.1

Apache Wicket 1.3.0-rc1 is released!

Le projet Wicket avance et entre en release candidates. Cela signifie que seulement des corrections de bugs seront faites jusque la sortie finale de la version 1.3.
Au programme de cette release :

• un guide de migration à partir de la version 1.2 : l’API a évolué/changé et donc pas mal de changements sont à prévoir.
• beaucoup de bugs ont été corrigés, et les évolutions sont nombreuses. Voici la liste.

• 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 <JAVA_HOME>/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 <Java_Home>/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 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 :

1. Télécharger wlst_v64.zip
2. Extraire l’archive dans un répertoire (ex c:\wlst)
3. 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 %*


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

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN"
     "http://www.springframework.org/dtd/spring-beans-2.0.dtd">
<beans>
 <bean id="infombean" class="fr.xebia.management.InfoMBean">
   <property name="name" value="xebia"></property>
   <property name="age" value="2"></property>
 </bean>
</beans> 

• Déclarons le server de MBeans de WebLogic

<bean id="weblogicMBeanServer"
   class="org.springframework.jmx.support.WebLogicJndiMBeanServerFactoryBean"/>

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

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
	<property name="beans">
		<map>
			<entry key="bean:name=testBean" value-ref="infombean" />
		</map>
	</property>
	<property name="server" ref="weblogicMBeanServer" />
</bean>

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.

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app id="WebApp_ID">
  <display-name>WebLogicSpringMBean</display-name>
  <servlet>
	<servlet-name>context</servlet-name>
	<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
	<load-on-startup>1</load-on-startup>
  </servlet>
</web-app>

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

<web-app id="WebApp_ID">
	<display-name>WebLogicSpringMBean</display-name>
	<servlet>
		<servlet-name>context</servlet-name>
		<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
		<run-as>
			<role-name>admin</role-name>
		</run-as>
	</servlet>
	<security-role>
		<role-name>admin</role-name>
	</security-role>
</web-app>

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

<weblogic-web-app>
	<security-role-assignment>
		<role-name>admin</role-name>
		<principal-name>weblogic</principal-name>
	</security-role-assignment>
</weblogic-web-app>

• 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

<bean id="exporter" class="fr.xebia.management.CommonModelerBeanExporter">
	<property name="beans">
		<map>
			<entry key="bean:name=testBean" value-ref="infombean" />
		</map>
	</property>
	<property name="server" ref="weblogicMBeanServer" />
</bean>

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