Discussion :

[dobfatch]

Hello,

Je souhaite écrire une classe de logging utilitaire pour écrire des logs Log4J. Quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public class Logger {
 
  public static void info (String message) {
    LogFactory.getLog(getCallingClassName()).info(getHeader() + message);
  }
  ...

Le but est de pouvoir, à n'importe quel endroit dans mon projet, faire un simple appel à cette classe utilitaire en lui passant un message, et que celle-ci se charge de logger l'information tout en lui ajoutant un peu de "déco" (en-tête, quelques données contextuelles, etc.).

Mais là où ça se complique c'est que j'aimerais pouvoir utiliser ces logs dans un contexte de débogage, et donc bénéficier du nom de la classe et du numéro de ligne où le log a été écrit. Or en procédant comme ci-dessus, le log affiche (forcément) le n° de ligne de ma classe utilitaire, ce qui n'est pas d'une très grande utilité.

Existe-t-il donc un moyen de biaiser Log4J pour qu'il lise ses informations 2 ou 3 lignes plus haut dans la pile d'exécution ? Je vois bien comment récupérer le nom de la classe appelante, mais il ne s'agit a priori pas que de ça ....

Merci pour vos lumières !

[tchize_]

Non, l'appelant, c'est l'appelant, et donc ta classe utilitaire. Si tu veux plus d'infos, faudra logguer le stacktrace complet, mais c'est plus très lisible. La classe appelante, apparement, tu l'as déjà. Personellement, les numéros de lignes, c'est pas très utile. Quand tu prend un message de log dans une classe donnée, il est rare que ce message apparaisse à plus de deux endroits différents de la classe -> la ligne est facile à retrouver juste avec le message.

Je dois ajouter que, récupérer systématiquement à chaque appel la classe de l'appelant c'est très mauvais pour les performances.

Et devoir dans ton code mettre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Logger.info(message)

plutot que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
private static Logger log = Logger.getLogger(MaClass.class);
log.info(message);

j'ai pas vraiment l'impression que le gain en valle la chandelle.

[dobfatch]

Tout à fait d'accord pour l'argument de performance. Mais la problématique que je visais à régler se situe plutôt au niveau du contenu du message utile transmis au logger.

Celui-ci respecte un format assez particulier et j'ai envie de fournir une classe utilitaire pour centraliser les détails de cosmétique, nettement plus pratique en cas de modification dudit format, et plus pratique à l'utilisation.

On ne va pas sortir 15'000 logs à la minute, donc je ne suis pas à un ou deux appel près !

Sinon, j'ai pu trouver mon bonheur, dans l'API Log4J,sur la classe Logger il existe ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public void log(java.lang.String callerFQCN,
                Priority level,
                java.lang.Object message,
                java.lang.Throwable t)
 
    This is the most generic printing method. It is intended to be invoked by wrapper classes.
 
    Parameters:
        callerFQCN - The wrapper class fully qualified class name.
        level - The level of the logging request.
        message - The message of the logging request.
        t - The throwable of the logging request, may be null.

[tchize_]

c'est un peu réinventer la roue. Le formattage est déjà géré par les layouts

[dobfatch]

Bien d'accord pour le formatage des données non-business .

Pour ce qui est du contenu du message de log, pour peu que tu veuilles qu'il soit standardisé (donc parsable, par exemple), tu ne peux pas te reposer sur Log4J ...

[tchize_]

Et en quoi ce ne serait pas possible avec soit le patternlayout soit, au pire, avec un custom layout? Le seul role des appel log en log4j est de localiser le logger et de lui filer le messge avec eventuellement un test du niveau (debug, info, etc). Le logger lui va déterminer où envoyer le log (appender fichier, console, email, base de donnée) et comment l'envoyer (patternlayout, email layouyt, etc..). Donc pour le formattage, le layout me semble le meilleur endroit. J'ai ici des logger en production, certains utilisent des format bien précis. Par exemple on a une logger qui utilise le format de log de apache httpd afin de s'assurer que le fichier de logs soit lisible par les outils de traffic destinés au serveur web.

Quand à la surcharge de temps, consulter la pile d'appel est une opération lente. Si t'as cinq log par seconde ok, mais si tu veux aussi un jour mettre des logs de debug, les appels vont se multiplier, et tu va consommer plein de temps cpu à consulter la pile d'appel tout ca pour que, plus bas, on décide de ne pas utiliser le message.

[dobfatch]

Re (et navré pour le délai de réponse),

Je t'avoue ne pas avoir creusé les possibilités de Log4J dans les moindres détails, et je m'étais arrêté (peut-être naïvement) au fait que celui-ci permettait, notamment au travers de son PatternLayout, de définir "comment habiller" le message envoyé. Je partais du principe que le message transmis au logger était une chaîne de caractère. Il semblerait en effet que celui-ci puisse être un objet quelconque ... c'est ça ?

Bref, si tu me dis que c'est possible de spécifier le format d'affichage d'un message (non pas en lui collant l'heure du log, la classe appelante etc. devant, mais bien au niveau du contenu "utile" du message, lié au code métier de ton application) je suis assez curieux de savoir comment, si tu as le temps de donner un exemple (ou de me guider vers un exemple). J'imagine que c'est possible, puisque qu'a priori dans tes logs au format apache, le contenu doit bel et bien être formaté.

Toujours est-il que dans mon cas, j'ai fait au plus simple (et ai effectivement abandonné le coup malsain d'appel à la pile d'exécution) et la solution retenue convient très bien à mes besoins. J'ai fait un simple wrapper du logger Log4J, qui fournit les méthodes habituelles (debug, info, ...), mais celles-ci requièrent quelques données en plus du message (je n'entrerai pas dans le détail, mais il s'agit en gros de données liées au contexte d'appel du log). Ces données sont formatées convenablement et loggées avec le message transmis.

C'est relativement peut coûteux, très pratique à l'usage, et plutôt élégant....

Merci pour tes feedbacks en tous les cas !

[tchize_]

JE comprend ce que tu veux dire, ton exemple ne passait aucune information supplémentaire. En gros ta classe sert juste à réunir plein de truc ensemble avant de faire un appel log. En faisant gaffe aux performances c'est jouable. Pour info, cependant, il existe d'autre moyens de passer des arguments supplémentaires au logger:

les appel l7dlog, par exemple, utilisent une clé, un ressource bundle et des paramètres, de la meme manier que messageformat.

Le layout prend en paramètre un Object, il n'est pas limité à String

Log4J a la notion de mdc, qui est une map associée au thread courant et qui contient un tas d'informations que les appels logs peuvent utiliser. Tu y stocke ce que tu veux, par exemple l'utilisateur courant, la quote bourse courante que t'es occupée de traiter, le fichier que tu traite, etc. On utilise ici ça pour les logs d'erreur, ca inclue systématiquement le user concerné et le thread concerné, ca permet d'y voir beaucoup plus clair.

Pour ce qui est des logs à la apache, j'utilise la configuration de tomcat, qui utilise le log4j, je suis pas sur que ce soit enièrment log4j qui fasse le rendu.