[Commons-Logging]Une classe entre le message et l'API de log

Bonjour à tous !

Je voudrait créer une classe "LogAdapter" permettant de faire la liaison entre les appels de message de log dans l'application et l'api de log utilisé (dans mon cas actuel c'est log4j).

L'utilité de la classe "LogAdapter" est qu'elle permet :
- de changer l'api de log utilisé sans modifier chaque classe de mon application une a une.
- de faire des methodes de log personnalisés permettant l'ajout d'autre parametres à ajouter aux messages etc...

J'ai donc crée cette classe, et je n'ai pas de probleme majeur.
Le seul problème est que la classe et le numéro de ligne du message de log correspondent à ma classe "LogAdapter" et non à la classe et la ligne appelant la méthode de log (Ce qui est logique j'en convient puisque la veritable méthode de log (celle de log4j) est appelée dans la méthode de log de ma classe "LogAdapter").

Quelqu'un aurait-il une solution pour palier à ce probleme ?

Merci

trop fort tu viens de refaire le commons logging d'Apache !!
Tu peux le trouver
Ici

:oops: effectivement ! Ce type de classe a déja été mise au point !

Le pire c'est que je l'avait deja (avec struts) mais que je savais pas trop à quoi elle servait !

Bon bah je m'y met alors ...

merci jcarre !

:? Après concertation il m'est apparu que l'utilisation du package common-logging n'est peut etre pas la solution que je recherche.

Effectivement j'essaye de mettre en place une structure de logging qui me permettra d'y adapter n'importe quel API de log que je souhaite. Et de plus de me permettre d'y inserer n'importe quel méthode de log.

Or common-logging permet-elle l'adaptation de n'importe quel API de log ou juste des plus repandus? Par exemple, si je met au point ma propre API de log, est ce qu'elle sera adaptable à common-logging?

Tandis que si je met au point une petite classe tampon. Elle restera, de par sa simplicite, facilement adaptable a n'importe quel API de log. Je n'aurais pas à me trimballer avec un gros jar que je ne peut que difficilement retoucher au besoin.

Alors retour à la case départ, il faudrait juste que je puisse recuperer les informations relatives à l'emplacement ou est appelée la méthode de log de ma classe tampon

Hmmm ! Apparemment common-logging permet d'effectuer l'interface entre l'api de log et l'application mais ne le ferait que pour Avalon, Log4J et JDK13LumberJackLogger !

Si quelqu'un pouvait me le confirmer (ou inversement)! Parceque je trouve pas le site de jakarta très explicite en ce qui concerne les possibilités de ce package (pis en plus c en anglais ce qui ne m'aide pas non plus).

Merci !

Bon !
J'avance petit à petit mais y a pas des masses de doc sur commons-logging (en fait y a que le site de Jakarta). Alors je met mes "trouvailles" ici si cela peut interesser quelqu'un.

Ce que j'ai compris c'est que common logging s'utilise par le biais de 2 classes : Log et LogFactory.
La classe LogFactory permet d'obtenir un logger (classe Log) pour la classe en cours :

Code:

---

Log MonLog=LogFactory.getLog("NomDuLogger");

---

La classe Log permet d'effectuer les messages de log :

Code:

---

Log MonLog.debug("monmessage");

---

Pour regler l'API de Log que doit utiliser commons-logging y a 2 facons de faire :
Soit on laisse faire et il prend Log4J si le jar est présent, sinon le logger de JDK1.4 si c'est JDK1.4 qui est utilisé sinon SimpleLog un logger interne à commons-logging.
Sinon on peut choisir dynamiquement l'API à utiliser mais j'ai pas trop compris la façon de faire (à partir de org.apache.commons.logging.Log apparement.

En fait la classe Log n'est qu'une interface. Derriere il y a 7 classes qui l'implemente, une pour chaque API de log (excepté avalon qui en à droit à 2 "AvalonLogger" et "LogKitLogger" ... 'pas compris pourquoi)
:idea: Alors peut être que pour adapter sa propre API de log il "suffit" de creer une classe implementant l'interface Log ! A voir !

Par contre j'ai toujours pas trouvé comment régler le niveau et la sortie(sortie fichier ou autre) du log par le biais de commons-Logging.

Bon je continue à chercher :roll: !

Autre chose encore :

Avec commons-logging, il est apparement preferable, en terme de performance, d'effectuer une verification du niveau de log avant de faire un appel de log :

Code:

---

1 2 3

if(MonLogger.isDebugEnabled()){ MonLogger.debug("MonMessage"); }

---

Youpi !!! Enfin du concret (enfin si on veut).

Alors, effectivement une implementation de l'interface log permet de creer un pont avec n'importe quel API de log. Sachant qu'il existe déja des implementations fournies pour Log4J, Avalon, et JDK1.4(1.3).

De plus on peut modifier la façon de choisir l'API de log en créant une implementation de LogFactory.

Bon, pour finir :

Commons-Logging ne permet QUE de choisir l'API à utiliser et d'effectuer des messages de log avec celle-ci.

Elle ne permet donc pas de définir le niveau de log, la sortie de log et le format de log. Pour cela il faut utiliser directement les outils de l'API utilisée.
En y pensant, c'est logique puisque cette partie de configuration est vraiment propre à chaque API de Log. Ce serait un vrai casse-tête de reussir à les mettre en commun.