Documentation utilisateur
Nous essayons de simplifier les modifications requises dans votre projet
pour activer CorbaTrace. Nous utilisons uniquement les m�thodes de l'OMG
pour l'installer. Ce fichier peut ne pas �tre parfaitement synchronis�
avec les derniers fichiers sources. Voir dans le CVS le fichier INSTALL et
dans l'API JavaDoc pour les nouvelles instructions.
Installation dans votre projet
Vous avez un exemple du serveur et un du client dans ./src/java/corbatrace/hello.
Inclure uniquement CorbaTrace.jar dans votre CLASSPATH.
set CLASSPATH=$CLASSPATH:mypath/CorbaTrace.jar
Ajouter au d�but de vos fichiers sources :
import corbaTrace.Interceptor;
Client
Dans vos sources, avant la cr�ation de l'orb, initialisez l'intercepteur en cr�ant une instance d'InterceptorClient .
Apr�s l'initialisation de l'orb, et avant les appels distants, ajoutez :
obj = interceptorClient.active_interception(obj, orb);
o� obj est cr�� de la fa�on suivante :
org.omg.CORBA.Object obj = orb.string_to_object(myIOR);
Vous pouvez obtenir votre propre objet en utilisant la fonction standard suivante :
Hello hello = HelloHelper.narrow(obj);
Une fois tous les objets cr��s, ajoutez :
interceptorClient.activate_log(orb, "My Name");
"My Name" est utilis� pour identifier votre composant. Tous les objets client sur le m�me orb font partis du m�me composant.
Si vous voulez changer la strat�gie d'interception, appelez la methode suivante :
interceptorClient.change_level_interception(obj, orb, int); (Se r�f�rer au site OMG specification pour plus de d�tails).
Voici un exemple :
import corbatrace.InterceptorClient;
...
class MyClass {
...
interceptorClient = new InterceptorClient();
...
ORB orb = ORB.init(args, props);
...
obj = orb.string_to_object(ref);
obj = interceptorClient.active_interception(obj, orb);
interceptorClient.activate_log(orb, "My Component");
...
Hello hello = HelloHelper.narrow(obj);
...
}
Vous pouvez t�l�charger le code de cet exemple Client sur votre CVS : Cliquez ici.
Server
Dans vos sources, avant la creation de l'orb, initialisez l'intercepteur en cr�ant une instance d'InterceptorServer .
Apr�s l'initialisation de l'orb, appelez la m�thode ci-dessous pour obtenir les r�f�rences sur le RootPOA :
obj = orb.resolve_initial_references("RootPOA");
o� obj est un org.omg.CORBA.Object.
Obtenez votre propre rootPOA en utilisant la m�thode standard suivante :
POA rootPOA = org.omg.PortableServer.POAHelper.narrow(obj);
Puis cr�ez le POA en utilisant la m�thode "create_poa" de la classe InterceptorServer :
poa_interceptor = interceptorServer.create_poa(orb, rootPOA, "myHelloPOA");
o� "myHelloPOA" est le nom du nouveau POA cr�� dynamiquement, et rootPOA votre propre POA.
Activez l'objet sur ce POA :
obj = interceptorServer.activate_object(poa, helloImpl, "My Component");
Cette m�thode enregistre et active l'objet sur le POA qui vient d'�tre cr��.
Ce POA permettra aux applications clientes d'y acc�der. Cette
m�thode active aussi le POAManager qui contr�le la mani�re avec laquelle
le POA g�re les requ�tes des diff�rents clients.
Obtenez votre propre objet en utilisant la m�thode standard suivante :
Hello hello = HelloHelper.narrow(obj);
Enregistrez votre objet "hello" dans un fichier (ou dans le CosNaming) :
writeObjectToFile(orb, hello, filename);
Mise en attente du serveur :
Celui-ci �coute les demandes des diff�rents clients et y r�pond
en appelant les m�thodes correspondantes sur l'objet serveur :
orb.run();
Destruction du serveur avant de quitter le programme :
orb.destroy();
Voici un exemple :
import corbaTrace.InterceptorServer;
...
class MyClass {
...
interceptorServer= new InterceptorServer();
...
ORB orb = org.omg.CORBA.ORB.init(args,props);
obj = orb.resolve_initial_references("RootPOA");
POA rootPOA = org.omg.PortableServer.POAHelper.narrow(obj);
poa_interceptor = interceptorServer.create_poa(orb, rootPOA, "myHelloPOA");
...
obj = interceptorServer.activate_object(poa, helloImpl,"My Component");
Hello hello = HelloHelper.narrow(obj);
writeObjectToFile(orb, hello, "My File");
...
orb.run();
orb.destroy();
}
Vous pouvez t�l�chargez tout le code de cet exemple Serveur sur votre CVS :
- Server.java
- Hello.idl
- Hello_impl.java
R�sultat
Compilez votre projet et ex�cutez-le.
Des fichiers log sont g�n�r�s ( *_Ctrace.xml pour les objets client et *_Strace.xml pour les objets serveur).
Leur compr�hension est facile.
Vous pouvez les convertir en XMI et utilisez d'autres filtres (pas encore impl�ment�).
Vous pouvez voir XMI dans tous les outils UML qui lisent les fichiers XMI
standards. Vous pouvez aussi utiliser notre outil appel� : xmi2latex.
Captures d'�cran
Lors de l'ex�cution de notre exemple vous obtenez les deux captures d'�cran ci-dessous :
Server

Client

Apr�s l'interception, deux logs sont g�n�r�s (fichiers joints) :
Generer un Diagramme de Sequence UML
Apr�s la cr�ation des logs des messages intercept�s, vous pouvez les utiliser avec notre outil (Log2xmi) pour g�n�rer un diagramme de s�quence UML au format XMI.
Cet outil a quatre objectifs :
- parser vos fichiers de log, et fusionner les messages partiels pour obtenir des messages complets.
- synchroniser toutes les horloges locales des objects � une horloge commune (puisque souvent distribu�s sur diff�rentes machines � travers le monde).
- appliquer quelques filtres personnels pour obtenir des informations plus pertinentes.
- generer un fichier XMI que vous pouvez directement visualiser sur des outils courants comme MagicDraw et Rational Rose.
La ligne de commande pour Log2xmi est la suivante:
java corbaTrace.log2xmi.Main [options] <XML logs>
Les logs XML sont les logs que vous avez g�n�r� � l'�tape pr�c�dente. Ils peuvent �tre donn�s sous la forme d'un chemin vers un fichier ou d'une URL.
N'oubliez pas de placer le fichier log.dtd dans le m�me r�pertoire que vos logs (de m�me pour les filtres).
Voici un r�sum� des options :
-o est le fichier xmi dans lequel log2xmi sauve tous les messages lus.
Par d�faut, log2xmi utilise le nom de fichier "out.xml".
-f donne un fichier de filtre pour restreindre les messages g�n�r�s (voir plus bas).
-x definit pour quelle application vous souhaitez g�n�rer le fichier XMI.
-xr signifie pour Rational Rose, -xm pour Magic Draw, et -xrm (ou -xmr) pour les deux.
-v indique de ne pas valider les logs XML avec leur DTD (lors du parsage).
Cela ne devrait rien changer comme les logs g�n�r�s sont valid�s, mais vous pouvez l'utiliser si vous voulez toujours g�n�rer le fichier xmi m�me si les logs sont un peu corrompus.
note : cette option s'applique aussi au fichier de filtres (car celui-ci est aussi bas� sur log.dtd).
Nous vous recommandons d'utiliser cette option aussi rarement que possible.
-s indique de passer l'�tape de synchronisation.
Cela peut �tre utilis� seulement si vous savez que tous vos objets fonctionnent d�j� avec la m�me horloge (dans le m�me fuseau horaire), et ainsi l'�tape de synchronisation n'est pas n�cessaire.
Cela peur acc�l�rer un peu l'ensemble du traitement des logs.
-d affiche plus d'informations � chaque �tape.
Elle est inutile dans la plupart des cas et ne devrait �tre consid�r�e qu'� des fins de d�buggage.
Les filtres sont �crits dans un fichier XML, comme d�fini dans la DTD (log.dtd)
Il fonctionne � deux niveaux :
- de mani�re globale
- au niveau d'un objet
Au niveau global, vous pouvez restreindre les messages � :
- vos types de messages donn�s :
les types sont : REQUEST, REPLY, EXCEPTION, BROKEN_REQUEST, BROKEN_REPLY, et BROKEN_EXCEPTION.
- vos dates donn�es (ou intervalles) :
Il y a trois types de filtres de date : apr�s une date, avant une date, entre eux dates.
Les dates utilisent le m�me format que les logs : annee-mois-jourTheures-minutes-secondes-millisecondes (par ex: 2002-03-09T17:00:00.000)
- vos op�rations donn�es, independamment des objets.
pour chaque operation vous donnez son nom, et pouvez la restreindre plus pr�cisemment avec les valeurs des arguments de l'op�ration.
Les arguments d�finis sont de deux types
- un type de donn�es et une valeur
- une position d'argument dans l'op�ration (de 1 � n) et une valeur
- vos objets donn�s avec leur ID (nom de l'objet)
Pour des objets donn�s, vous pouvez aussi restreindre vos messages plus pr�cisemment � des types de messages donn�s, des dates, et des op�rations, avec les m�me principes qu'au niveau global.
Chaque filtre diff�rent (date - type - objet - methode) fonctionne comme un "ET" avec les autres.
Chaque composant de filtre (les dates pour un filtre de date, les arguments pour un filtre de m�thode, etc.) fonctionne comme un "OU" avec les autres.
Par exemple : (filters.xml)
<filter>
<message_types>
<type value="BROKEN_REQUEST"/>
<type value="BROKEN_REPLY"/>
<type value="BROKEN_EXCEPTION"/>
</message_types>
<dates>
<after date="2002-03-09T17:00:00.000"/>
<before date="2002-03-09T15:00:00.000"/>
<between from="2002-03-09T15:30:00.000" to="2002-03-09T16:30:00.000"/>
</dates>
<methods>
<method name="anOperation1">
<argumentAt position="3" value="ddd"/>
<typedArgument type="string" value="ccc"/>
</method>
<method name="anOperation2">
</method>
</methods>
<objects>
<object id="anObjectID1">
<message_types>
<type value="BROKEN_REQUEST"/>
<type value="BROKEN_REPLY"/>
<type value="BROKEN_EXCEPTION"/>
</message_types>
<methods>
<method name="anOperation">
<argumentAt position="1" value="aaa"/>
<argumentAt position="2" value="bbb"/>
</method>
</methods>
</object>
<object id="anObjectID2">
</object>
</objects>
</filter>
Ces filtres de messages conservent les messages qui :
sont de type incomplets (n'importe lequel)
ET sont apr�s 17H (le 9/3/2002)
OU avant 15H
OU entre 15H30 et 16H30
ET sont des operations nomm�es "anOperation1"
avec (un argument � la position 3 �gal � "ddd"
OU un argument de type string �gal � "ccc")
OU une operation nomm�e "anOperation2"
ET concerne un objet "anObject1"
avec un message de type incomplet
ET concernant l'operation "anOperation"
avec un argument � la position 1 �gal � "aaa"
OU un argument � la position 2 �gal � "bbb"
OU concerne un object "anObjectID2"
Bien s�r, ce n'est qu'un exemple. Ici, donner les types de messages comme "incomplets" pour l'objet "anObject1" n'est pas utile comme il est d�j� d�fini de mani�re globale pour le m�me type de messages.
Documentation compl�te
Si vous voulez une explication compl�te sur le projet CorbaTrace, vous pouvez lire notre rapport et notre pr�sentation. Le rapport parle de l'architecture de CorbaTrace et de sa cr�ation, des intercepteurs portables de Corba, de XMI et de beaucou d'autres choses.
La documentation sur les nouveaut�s de la version 2.0 et la nouvelle IHM n'a pas �t� traduite (honte � nous). Regardez donc la version anglaise
Contactez-nous en cas d'erreurs ou pour nous soumettre vos corrections.
http://corbatrace.tuxfamily.org
|