Fichiers de configuration

La configuration des traces (définition des composants "logger", "appender" et "layout") s'appuie sur un fichier.

Dans un contexte d'exécution Adélia Cloud, cette configuration peut également être mise en place - de façon dynamique – à partir du gestionnaire de traces accessible depuis le Desktop Adélia.

 

• C/Windows : log4c.xml
  
  Le fichier de configuration est nommé log4c.xml.
  Le fichier est recherché en priorité dans le chemin renseigné par la variable d'environnement LOG4C_PATH, puis dans le répertoire courant, et enfin dans le répertoire d'installation du Runtime Adélia C/Windows (variable d'environnement ADELIWS).
  
  Un fichier exemple de référence log4c.xml.new est fourni lors de l'installation du produit ou du Runtime Adélia Studio comme base potentielle de configuration.
  
  En l'absence d'un fichier de configuration il est possible de recourir aux variables d'environnement LOG4C_PRIORITY et LOG4C_APPENDER pour déclarer un niveau de gravité et un "appender" au "logger" de plus haut niveau ("root").
  
  Il est possible de fixer les variables d'environnement SD_DEBUG et/ou SD_ERROR pour tracer la phase d'initialisation de Log4c dans un fichier nommé : "%temp%/ log4c_debug_file_<usr>_<pid>.log".

 

• AS/400 : *DTAARA LOG4AS | log4c.xml
  
  L'activation des traces sur la plateforme AS/400 s'appuie sur la présence d'une DTAARA (TYPE (*CHAR) LEN (128) ) nommée LOG4AS dans le contexte d'exécution.
  
  La DTAARA peut être utilisée sous deux formes :

 

A/

 

NIV[:JLOG[:format]]

NIV => 3 caractères exprimant le niveau de gravité :

FAT : FATAL

ERR : ERROR

WRN : WARNING

INF : INFO

DBG : DEBUG

TRC : TRACE

OFF : Désactivation

 

Exemple : DBG

 

L'initialisation de la gestion des traces redirige automatiquement la sortie stdout vers le fichier spool nommé LOG4STDOUT.

Dans ce cas de configuration simplifiée, les traces sont toutes produites dans le fichier spool LOG4STDOUT.

 

Il est également possible de produire les traces dans l'historique du travail. Pour ce faire il faut ajouter, après le niveau de gravité, le terme JLOG.

 

Exemple : DBG:JLOG

 

La trace produite est alors formatée par défaut avec le motif suivant : [%-5p][%-30c][%m] où p est le niveau de gravité, c le nom du logger, et m le message.

Il est possible de modifier le formatage en précisant un motif à la suite de JLOG.

 

Exemple : DBG:JLOG:%p-%m

 

Remarque : la définition des motifs est donnée dans le fichier de référence log4c.xml.

 

B/

La chaîne fait référence au fichier de configuration log4c.xml situé dans l'IFS.

Exemple : '/conf_log/log4c.xml'

 

Dans ce cas, la configuration est identique à celle de la plateforme C/Windows.

Il est à noter que la sortie standard stdout est automatiquement redirigée vers le fichier spool nommé LOG4STDOUT.

Les erreurs détectées lors de la phase d'initialisation de Log4c sont systématiquement tracées dans ce fichier spool.

 

• Java – Adélia Web – Cloud
  • Java – Adélia Web
    Le fichier de configuration est nommé log4j.properties ou log4j.xml.
    Le fichier de configuration lu est le premier fichier rencontré au regard de la variable d'environnement CLASSPATH.
    Il est possible de charger un fichier spécifique en ajoutant la directive –Dlog4j.configuration=<NomFichierCfg> au démarrage de la JVM.
    
    Un fichier exemple de référence log4j.properties.new est fourni lors de l'installation du produit ou du Runtime Adélia Studio comme base potentielle de configuration.
    
    Il est possible d'ajouter la variable d'environnement log4j.debug au démarrage de la JVM pour tracer la phase d'initialisation de log4J.
    
    Exemple : java –Dlog4j.debug <package>.<monpgm>
    
    
  • Cloud
    Le fichier de configuration est nommé log4j.lcf.
    Le fichier est lu dans le répertoire WEB-INF/conf de l'application ou est externalisé via une ressource jndi nommée url/adeliaLog4jConfig.

 

↑ Haut de page

 

Espaces de configuration

Requêtes BD / Performances

Les traces dédiées à la couche base de données s'appuient sur les "logger" spécifiques suivants :

 

• hasqllogger.func : permet de tracer les erreurs SQL (niveau ERROR) ou les erreurs SQL et les erreurs internes aux APIs (niveau WARN).

 

• hasqllogger.dump : le niveau INFO, en conjonction avec la clé EnableLog4SessionDump positionnée à la valeur 1 du fichier de configuration du Runtime BD, permet de tracer en temps réel l'ensemble de l'activité SQL (requêtes, valeurs des paramètres, données lues).

 

• hasqllogger.counters : le niveau INFO, en conjonction avec la clé PerformanceInfoLevel positionnée à une valeur > 0 du fichier de configuration du Runtime BD, permet, au moment de la déconnexion, de tracer des informations statistiques et de performances générales.

 

Note : les traces (Performance générale et SessionDump) de la couche BD peuvent également être activées – de façon  totalement déconnectée du mode de gestion unifiée des traces - via le fichier de configuration du Runtime BD (apiva.properties pour la plateforme Java et apiconf.ini pour la plateforme C/Windows).

 

Exemple:

 

Les traces (performance des requêtes ; PerformanceInfoLevel=2), produisant en fin de session un fichier ASCII délimité avec des informations détaillées pour chaque requête exécutée, peuvent être activées uniquement par le fichier de configuration du Runtime BD.

 

Exemple:

 

↑ Haut de page

 

Middleware

Les informations en lien avec le Middleware peuvent être recueillies à l'aide du "logger" nommé com.hardis.middleware et des niveaux de gravité :

• • ERROR : erreurs détectées lors de la connexion au service ou lors de l'échange de trames entre la partie cliente et la partie serveur.
  • INFO : informations sur la connexion et les échanges de données avec le service.
  • DEBUG : détail des trames échangées entre la partie cliente et le service.

 

Les informations en lien avec :

• • le préparateur de sessions Middleware sont traçables à l'aide du "logger" nommé com.hardis.adelia.sessionPrep.
  • le pool de sessions Middleware sont traçables à l'aide du "logger" nommé com.hardis.adelia.pool.

 

↑ Haut de page

 

Services Web

• SOAP
  • Consommation : les composants "logger" nommés com.hardis.adelia.webservice (Java – Web – Cloud ) et com.hardis.adelia.varuntme.vrtcwebservice2 (C/Windows) permettent de tracer la surcouche Adélia de la consommation d'un service Web SOAP.
    Il est possible d'activer des traces de la couche Axis2 sous-jacente via les composants "logger" nommés :

Plateforme java – Web – Cloud :

• org.apache.axis2

• org.apache.axiom

• org.apache.commons.http

Plateforme C/Windows :  org.apache.axis2c

 

• Production : les prérequis à la génération de traces pour un service Web SOAP sont les suivants :

Déploiement du module LoggingModule.mar dans le sous-répertoire WEB-INF/modules

Ajout de <module ref="LoggingModule"/>  dans le fichier WEB-INF/conf/Axis2.xml

Ajout de <phase name="loggingPhase"/> dans le fichier WEB-INF/conf/Axis2.xml comme dernier sous-élément des quatre éléments <phaseOrder>.

 

Une fois les prérequis remplis, les composants "logger" de niveau DEBUG nommés org.apache.axis2.soap.request et org.apache.axis2.soap.request_response permettent de tracer la requête adressée au service et, dans le cas favorable, la réponse retournée au client.

 

• REST (production) : la génération de traces d'exécution d'un service Web REST peut être activée dans le fichier WEB-INF/beans.xml en enlevant les commentaires des lignes suivantes :

<!--cxf:bus>

      <cxf:features>

      <cxf:logging />

      </cxf:features>

</cxf:bus-->

↑ Haut de page

 

 

 

Etats Crystal Reports

Les informations en lien avec la production d'états Crystal Reports peuvent être recueillies à l'aide du composant "logger" nommé com.hardis.adelia.vacrysrt.vacrysrtgen (ou com.hardis.adelia.svcgenrap pour le service d'impression) et des niveaux de gravité :

• ERROR : erreurs détectées lors du chargement, de la traduction, de la génération, de la prévisualisation, de l'export ou de l'impression de l'état.
• INFO : informations sur les différentes étapes du processus de production des états.
• DEBUG : détail des données alimentant les états.

↑ Haut de page

 

 

 

Autres

De façon plus générale, tous les composants "logger" :

• • du Runtime Adélia héritent du "logger" nommé com.hardis.adelia,
  • du Middleware Adélia héritent du "logger" nommé com.hardis.middleware,
  • des VaToolBx Adélia héritent du "logger" nommé com.hardis.vatoolbx (et com.hardis.adelia.cloud.vatoolbx dans un contexte Cloud).

 

Plateforme C/Windows

• • Le source C généré d'un programme de visibilité privée déclare le "logger" : pgm.<NomDomaine>.<NomObjet>.<NomModule>
  • Le source C généré d'un programme de visibilité publique déclare le "logger" : pgm.env.<NomObjet>.<NomModule>

 

Plateforme AS/400

• Le source RPG généré d'un programme de visibilité privée déclare le "logger" : pgm.<NomDomaine>.<NomObjet>.<NomModule>

• Le source RPG généré d'un programme de visibilité publique déclare le "logger" : pgm.env.<NomObjet>.<NomModule>

 

Plateformes Java/Web/Cloud

• Le source java généré d'un programme déclare le "logger" : <package>.<NomObjet>.<NomClasse>

 

↑ Haut de page