Surveiller ce forum | Commencer une nouvelle discussion

Hiérarchisé À plat Fils de discussion Ultime

Montrer 25 Montrer 50 Montrer 75 Montrer 100

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Xavier PRINCE on 2007-02-19 03:32

[forum:52504]

Ne serait-il pas utile de profiter de la mise en place de StrustACube pour passer sur une gestion standard des logs basé sur un unique fichier log4j.properties (qui est plus standard). En effet, le second fichier n’avait de sens que dans le cadre de StrustCx puisque initialement prévu pour gérer le niveau de log lier à ce composant. Je profite de ce post pour aborder aussi le sujet de la mise en place d’un système de trace équivalant à log4j au sein du Framework Ergonomique. Ce système permettra aussi de gérer différents niveau de traces (dans un souci de simplification, les mêmes que pour la partie serveur), ainsi que différents appender pouvant être : - une fenêtre spéciale ouverte par le navigateur, - l’alimentation des consoles d’erreur des navigateurs (uniquement Mozilla, et Firefox), - l’appel à un servlet spécifique sur le serveur Tomcat permettant de transformer cette log client en log4j.

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Xavier PRINCE on 2007-02-19 03:16

[forum:52503]

Une solution envisageable et déjà évoqué est de créer deux appender : - un appender standard contenant l'ensemble des logs sans contenu nominatif, - un appender "security" contenant l'ensemble des logs avec un contenu nominatif. L’appender "security" contiendrait en environnement de production, l'ensemble des logs de niveau "Security" mais aussi les logs de niveaux pouvant contenir des donnés utilisateurs. La gestion du second type se faisant par la création d'un nouveau niveau de log.

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Steve PEGUET on 2007-02-13 14:50

[forum:52489]

Pour mieux clarifier le sujet de la CNIL, logs et piste d'audit, le problème n'est pas dans le fait de tracer l'activité des utilisateurs mais d'y ajouter dans ces traces des attributs nominatifs comme le nom et le prénom pouvant alors s'apparenter à un fichier nominatif. La CNIL préfère qu'un identifiant soit tracé et que c'est seulement lors d'un besoin de piste d'audit que les attributs nom et prénom sont reconstitués à partir de cet identifiant. Ceci est juste une contrainte supplémentaire à intégrer dans le besoin de traçabilité surtout pour level SECURITY.

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Arnaud MAZIER on 2007-02-10 13:06

[forum:52484]

Des discussions internes au ministère des Affaires étrangères, il ressort que nous souhaiterions améliorer et simplifier la gestion des logs du fwk J2EE au plus tôt. Cela nous semble également fondamental de trouver une solution qui corresponde aux besoins de la communauté. Nous vous proposons d'échanger dans ce forum et d'y recueillir toutes les propositions ou orientations afin que nous revenions vers la communauté avec une proposition de spécifications début mars 2007 suivie d'un appel à commentaires pendant 15j. Qu'en pensez-vous ?

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Arnaud MAZIER on 2007-02-10 12:13

[forum:52483]

Le point concernant la CNIL me semble être un faux problème. En effet, tout en respectant la règlementation, il est tout à fait possible de tracer ce que l'on souhaite à condition d'en informer les usagers, que les données collectées sont proportionnelles à la nature de l'applicartion à tracer, d'assurer une sécurité d'accès aux informations collectées (ici les logs) et de prendre en compte le droit à l'oubli. Sauf dispense règlementée, la déclaration doit préciser tous ces éléments et notamment l'usage des logs que l'on peut faire (pistes d'audit, amélioration du produit...). L'application (voire le portail d'accès ou la charte en vigueur dans la structure) doit dans tous nles cas informer les usagers de la conformité à la loi et permettre les droits fondamentaux de l'usager (rectification, accès et oubli notamment). Dans ce cadre, il me semble que l'audit est possible.

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Steve PEGUET on 2007-02-09 15:37

[forum:52482]

Pour avancer dans le débat je rappelle initialment le besoin tel qu'il avait été exprimé au début de ACube ;-) LA TRAÇABILITE UTILITE DE LA TRAÇABILITE La gestion des logs est un enjeu majeur de la réalisation de tout projet fonctionnel sous cette architecture. Effectivement, ceux-ci permettent de résoudre et de corriger un grand nombre de problèmes aussi bien lors de la phase de développement, que dans la phase de maintenance de l'application ou durant le fonctionnement de l’applicatif. A ce titre, l’utilisation d'un framework de gestion des logs (Log4J) couplé à une récupération systématique de toutes les exceptions Java permettent d'obtenir un code fiable et facilitent la maintenance future de l'application. Les données contenues dans ces logs sont une source d’informations très importante pour de nombreux acteurs (Chef de projet, maîtrise d’ouvrage, exploitant, auditeur de sécurité, support technique…) METHODOLOGIE Quel que soit l'outil utilisé pour enregistrer des messages de logs, le point fondamental pour l’exploitabilité d’un applicatif est la pertinence du libellé des messages des traces. Un message d'erreur doit permettre un diagnostic précis de la raison du dysfonctionnement par une personne qui ne connaît pas le code source. Le libellé doit donc être clair et contenir l'ensemble des informations nécessaires à la compréhension de ce qui s’est réellement passé. Exemple : Si une application échoue dans l'ouverture de son fichier de configuration, le message ne doit pas être du style "erreur d'ouverture du fichier de configuration" mais "erreur d'ouverture du fichier de configuration <le nom complet du fichier> (<libellé de l'erreur système x>)" en ayant eu le soin de préciser le code et le type de l’événement tracé Enfin, le code retour de toute fonction et appel système doit être testé, et en cas d'échec l'application doit envoyer à l’utilisateur un message correspondant à l'erreur. L’utilisation d’un code événement systématique et standardisé pour tous les logs est très importante. Elle permet de créer un manuel de suivi de l’application qui peut être distribué au support technique et au service chargé de l’administration. Ce dernier permet de faire la relation entre les erreurs relayées et la marche à suivre lorsqu’on les rencontre. Cette procédure permet d’optimiser les démarches et de gagner un temps précieux lors d’un problème grave pour détecter l’origine exacte de l’erreur. Il ne faut jamais oublier que même les cas les plus improbables ou jamais constatés sur les plates-formes de développement peuvent se produire en production. Il est donc fondamental de tout tester afin d'éviter la propagation d'erreurs et d'alerter l'opérateur d’administration avec le diagnostic de la première erreur (traçabilité système). Il existe plusieurs niveaux de traçabilité qui se complètent les uns les autres : - La traçabilité applicative, elle permet de suivre le cheminement d’un utilisateur dans l’applicatif, de lister précisément les opérations réalisées par l’application, de déboguer l’application en développement, etc… - La traçabilité système, elle permet d’effectuer un suivi et une surveillance des erreurs et des dysfonctionnements par le pilotage métier. - La traçabilité des outils utilisés, elle permet de compléter les traces précédentes en utilisant la traçabilité intégrée dans les outils propres à l’architecture. Remarque : La traçabilité applicative fait partie intégrante du développement des applicatifs. Elle doit être intégrée dans le code des composants par l’équipe de développement. FORMAT GÉNÉRAL DES LOGS Le format général des logs lié à la traçabilité applicative est le suivant : <date>|<applicatif>|<site>|<type>|<code_evenement>|<utilisateur>|<commentaires> Date : correspond à la date aaaa:MM:jj:hh:mm:ss de l’évènement tracé Applicatif : code de l’applicatif (chaîne de 5 caractères) Site : code du site Type : type de l’événement tracé (ERROR, SECURITY, DEBUG, CRITIQUE, PERF ou INFO) Code évènement : code de l’évènement tracé (code sur 4 chiffres) Utilisateur : identifiant de l’utilisateur Commentaires : description de l’événement tracé L'idée de base au niveau de la typologie des événements tracés éuqivalents aux levels : - ERROR, DEBUG, CRITIQUE : classiques à Log4j - SECURITY : utiles pour une piste d'audit dédiée - PERF : utiles lors des tests de performances pour savoir le temps passé dans chaque traitement (début et fin). - INFO : utiles pour ajouter des statistiques destinés à la MO. La question est : est-ce réalisable d'ajouter des levels supplémentaires à log4j? Comment faire pour que les traces SECURITY soient isolés tout en respectant la CNIL dans le cadre d'une piste d'audits? + Les questions soulevées en sachant qu'il est préférable de normaliser tout celà dans le cadre de StrutsACube.

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Thierry RIGAL on 2007-02-08 20:00

[forum:52480]

Dans les projets ACube en développement la configuration des loggueurs Log4J a essentiellement consisté à configurer le fichier strutscx-log4j-config.xml malgré la présence d'un fichier de propriétés log4j.properties. L'opportunité de recourir à un fichier de propriétés n'a pas été assez commentée dans le passé au niveau de la documentation. Aujourd'hui le fichier de propriétés semble faire doublon. Pour rappel l'implémentation d'un Logger Log4J (entité de base pour effectuer la journalisation des logs) repose principalement sur : # Configuration des Appenders (en faisant appel aux objets Appender, Layout, Level) ; # Configuration des Loggers (configuration de son nom, son niveau de log, son type d'appender); # Configuration du Logger racine (configuration de son niveau de log, son type d'appender). La gestion de la configuration des logs Log4J dans un projet ACube peut s'effectuer de deux façons différentes : - via un fichier de propriétés (log4j.properties), - via un fichier XML (strutscx-log4j-config.xml). A première vue il semble difficile de choisir entre les deux types de configuration ce qui peut conduire à une certaine confusion lors du développement. Le fichier de configuration /WEB-INF/strutscx-log4j-config.xml est utilisé par l'objet StrutsCXLog4jInitPlugIn de StrutsCX (au démarrage de la servlet), il est donc nécessaire de conserver ce fichier et d'y inclure au minimum : - la configuration d'un appender - la configuration du logger nommé com.cappuccinonet.strutscx - la configuration d'un rootLogger Il sera donc difficile de se passer du fichier de configuration /WEB-INF/strutscx-log4j-config.xml si l'on souhaite récupérer les logs de StrutsCX. Dans l'application ACube nous devons récupérer les logs de plusieurs loggers définis dans le code : - acube.framework - acube.framework.technical.log Quelque soit la méthode choisie (par fichier de propriétés ou par fichier XML) il est important d'éviter le doublon de la configuration pour un logger donné. L'exemple de configuration ci-après montre l'utilisation du fichier de propriétés pour récupérer les logs du logger acube.framework dans la console (STDOUT) et l'utilisation du fichier XML pour les logs de Struts. Il aurait été possible cependant de ne configurer que le fichier XML (en décommentant la balise <logger name="acube.framework"> et son contenu) et en commentant la ligne log4j.logger.acube.framework=DEBUG, A2 dans le fichier de propriétés pour produire les mêmes résultats (à l'exception des premières lignes de logs de la servlet StrutsCX si l'on configure le logger de StrutsCX dans le fichier de propriétés semble-t-il). Remarques : 1/ dans chacun des deux fichiers il est possible de configurer des appenders et des layout "prêts à l'emploi". Leur utilisation n'intervient que lorsque des loggers déclarés y font référence. 2/ on obtient les mêmes résultats que l'on configure les loggers dans l'un ou l'autre fichier, 3/ La structure XML du fichier strutscx-log4j-config.xml est plus évidente que celle d'un fichier de propriétés à plat. De plus Log4J cherche par défaut un fichier XML de configuration : log4J.xml, pourquoi dans ce cas ne pas envisager à terme de se séparer du fichier de propriétés ? exemples de configuration : exemple de fichier log4j.properties : # name: log4j.properties, author: MAE, version: 2.0 #fichier de configuration de log4j # set the threshold for log4J log4j.threshold=DEBUG # definition de l'appender A1 log4j.appender.A1=org.apache.log4j.DailyRollingFileAppender log4j.appender.A1.File=c:/mon_appli_logFromLog4JProperties.log # definition du format de sortie de l'appender A1 log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d{yyyy:MM:dd:HH:mm:ss}|MAE|TestLogs|%p|%X{user}|%m%n # definition de l'appender A2 log4j.appender.A2=org.apache.log4j.ConsoleAppender # definition du format de sortie de l'appender A2 log4j.appender.A2.layout=org.apache.log4j.PatternLayout log4j.appender.A2.layout.ConversionPattern=%d{yyyy:MM:dd:HH:mm:ss}|MAE|TestLogs|%p|%X{user}|%m%n # definition du loggeur racine, utilisant l'appender A1 log4j.rootLogger=DEBUG, A2 # definition d'un loggeur pour le projet log4j.logger.acube.framework=DEBUG, A2 log4j.logger.acube.framework.technical.log=DEBUG, A2 exemple de fichier strutscx-log4j-config.xml : <?xml version="1.0" encoding="UTF-8" ?> <!-- name: strutscx-log4j-config.xml author : MAE version 2.0 --> <!-- STRUTSCX LOG4J CONFIGURATION - XML style --> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";> <!-- DAILY: Outputs log information to a file --> <appender name="DAILY" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="c:/mon_appli_logFromStrutsCXLog4J.log"/> <param name="DatePattern" value=".yyyy-MM-dd"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p - [%C{1}] %m%n"/> </layout> </appender> <!-- STDOUT: Outputs log information to the standard output/console --> <!-- <appender name="STDOUT" class="org.apache.log4j.ConsoleAppender"> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p - [%C{1}] %m%n"/> <param name="ConversionPattern" value="%d{yyyy:MM:dd:HH:mm:ss}|ACUBE|TestLogs|%p|STRUSTCX|%m%n"/> </layout> </appender> --> <!-- HTML: Outputs log information to a HTML file --> <!-- <appender name="HTML" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="/log/pulp-log.html"/> <param name="DatePattern" value=".yyyy-MM-dd"/> <layout class="org.apache.log4j.HTMLLayout"> <param name="Title" value="StrutsCX Log"/> <param name="LocationInfo" value="true"/> </layout> </appender> --> <!-- ne pas utiliser ce logger si l'on souhaite diriger les flux vers le fichier de log défini dans l'appender DAILY, HTML ou STDOUT --> <!-- <logger name="acube.framework"> <level value="DEBUG"/> <appender-ref ref="DAILY"/> </logger> --> <logger name="com.cappuccinonet.strutscx"> <level value="INFO"/> <appender-ref ref="DAILY"/> </logger> <root> <level value="DEBUG"/> <appender-ref ref="DAILY"/> </root> </log4j:configuration>

RE: Logs dans le gabarit projet J2EE [ Répondre ] Par : Thierry RIGAL on 2007-02-08 19:57

[forum:52479]

sur la question précise de placer les valeurs des paramètres de configuration dans le fichier build.project plutôt que dans le fichier build.properties : les seuls fichiers de propriétés qui se retrouvent dans l'application web dynamique déployée sont les fichiers de propriétés génériques situés dans les sources. Le build.project a pour tâche de fournir des valeurs au projet en construction. Le fichier build.properties du gabarit projet J2EE n'a d'autre but que de fournir des valeurs utiles à la gestion du projet sous eclipse et non dans le projet déployé. Il n'est donc pas choquant de lister les valeurs des paramètres à remplacer dans context.xml, les fichiers jsp, les fichiers de propriétés dans build.project qui reste l'unique fichier ayant ce rôle et sert de référence quelque soit la nature du fichier transformé.

Logs dans le gabarit projet J2EE [ Répondre ] Par : Benjamin Leperchey on 2007-02-05 20:53

[forum:52469]

La gestion des logs n'est pas très claire dans le gabarit J2EE : il y a une trentaine de propriétés à renseigner, et le build.project fourni est vide. D'expérience, ça va plus vite de refaire le sien... De plus (mais c'est peut-être corrigé aujourd'hui), le strutscx-log4j-config.xml mettait le bazar dans l'ensemble. Plusieurs questions : - généralement, pourquoi vouloir mettre toutes les valeurs des .properties dans un autre fichier de propriétés (build.project) ? C'est franchement tordu, et ça ne se justifie que pour les valeurs qui changent entre le dev et la prod. - pourquoi deux appenders dans le gabarit ? il faudrait au moins leur donner des noms plus parlants que A1 et A2. - dans le code de BuildLogger, il est fait référence en dur au package "acube.framework.technical", ce qui me semble curieux. - pourquoi avoir abandonné la configuration de Log4J en XML ? Je la trouvais plus parlante que celle en .properties (mais c'est sans doute une question d'habitude) Ca me semblerait plus pratique pour démarrer un projet de proposer un fichier log4j.properties minimal, avec un minimum de variables à remplacer : - le niveau de log pour le projet (les niveaux par défaut et pour le fw ACube seraient fixés à WARN, par exemple) - le type d'apppender (console ou fichier) - le chemin du fichier - le nom du fichier Ce sont les seules valeurs qui ont de bonnes raisons de changer lors du passage du dev à la prod. Tout le reste est à mon avis à sa place dans le fichier log4j.properties. Qu'en pensez-vous ?