Quelles bibliothèques de logs utilisez-vous pour vos développements avec la plateforme Java ?

Depuis des années, la journalisation des événements dans l'écosystème Java est proposée par des API de logging. On y retrouve ainsi de nombreuses bibliothèques (Java Util Logging, Log4J, SLF4J, Commons Logging, LogBack, TinyLog, etc.) et le choix est souvent difficile.

L'équipe Java vous propose ainsi un sondage sur la ou les bibliothèques que vous utilisez pour traiter les logs de vos programmes.

• Sur quel(s) critère(s) se sont portés vos choix ?
• Que vous manque-t-il comme fonctionnalité ?
• Pensez-vous qu'une spécification globale devrait être proposée pour encadrer toutes ces bibliothèques ?

Nous attendons vos remarques et contributions.

L'équipe Java

SLF4J est une facade de logging, à savoir qu'elle fait appel à un système secondaire de log derrière (du log4j, logback ou java util logging par exemple).

Donc pour toute personne répondant faire du SLF4J il serait intéressant de savoir quel moteur de log est réellement derrière.

Selon les projets, du Log4J, du Commons Logging ou du Java Util Logging, avec ou sans SLF4J.

Pour ma part, je trouve que Java Util Logging fait très bien le boulot et je ne comprends pas pourquoi on a toujours en 2015 cette pléthore de bibliothèques de log alors que le framework standard JavaSE fait très bien le job. Une dépendance de moins, c'est toujours bon à prendre. Le logging, ce n'est qu'une fonction utilitaire, ce n'est pas une fonctionnalité, et donc, pour moi, il faut que ça se fasse discret et que ça ne fasse pas ch...

:fleche: Sur quel(s) critère(s) se sont portés vos choix ?
J'ai eu la nécessité d'utiliser les logs lors de mon premier année de master, mon choix s'est alors porté vers Log4j car il est simple à mettre en place (import simple avec Maven), et mkyong a donné un bel exemple de son utilisation.

:fleche: Que vous manque-t-il comme fonctionnalité ?
Est-ce que l'API réalise mes besoins actuels ? Oui, donc je n'ai pas de manque à ce niveau.

:fleche: Pensez-vous qu'une spécification globale devrait être proposée pour encadrer toutes ces bibliothèques ?
Je pensais que Java Util Logging était là pour ça... :aie:
J'aurais bien aimé poursuivre avec cet api (après avoir connu log4j) car standard et intégré dans Java SE mais elle m'a l'air un poil compliqué... par exemple pour indiquer un fichier de sortie il faut utiliser du code (cf: FileHandler)...
L'idéal serait d'utiliser la ligne de commande (cf : -Djava.util.logging.config.file=/path/to/app.properties ) même si cela complique les choses avec les applications Java EE, mais quand je vois que Sun/Oracle n'en fait même pas référence dans sa documentation mais qu'on trouve des exemples sur internet (cf : lien) ça fait un peu peur...

Après avoir utiliser Log4J, SLF4J, Commons Logging, pendant 10 ans, je bloque les nouveaux développement sur Java Util Logging depuis 3 ans.

Marre de Log4J et des développeurs qui ajoute la lib à tous les war, ear sans regarder si le serveur d'app l'a.
Marre de SLF4J et de mettre un fichier conf spécifique ou la librairie de redirection.
Commons Logging mouai, en fait, c'est une mauvaise solution, c'est repousser le problème.
Marre de gérer le versionning des libs de log d'un nombre incalculable de veille version d'appli et de serveur d'appli qui n'évoluent BIENSUR pas la même vitesse.
Marre de gérer les environnement de (dev, recette) , (pré-prod,prod). Les ouiiin-ouiiin des développeurs : moi j'ai tomcat, moi j'ai wildfly moi j'ai glassfish, moi weblogic, (et non pas websphere, il ne faut pas être fou aussi !).

Donc le log de la JVM et point barre. Qu'est qu'on a perdu ? Rien. C'est simple à utiliser et des perf de bonheur (avec la bonne conf et sans lock de thread , à quel lib qui je pense ?).

PS : Spring a été tué pour les même raisons, full JEE7 maintenant, pareil rien perdu.

Avant j'utilise du SLF4J et puis on an passé à logback

Ce qui me gène dans le logback c'est que ca se configure en xml mais pas en fichier propertie

Citation:

---

Envoyé par squizer

SLF4J est une facade de logging, à savoir qu'elle fait appel à un système secondaire de log derrière (du log4j, logback ou java util logging par exemple).

Donc pour toute personne répondant faire du SLF4J il serait intéressant de savoir quel moteur de log est réellement derrière.

---

non
nous utilisons slf4J justement pour laisser le choix de l'implémentation à l'installation.
chaque client qui installe choisi son moteur préféré.

donc en tant que développeur choisir slf4j est choix aussi valable que les autres.
A+JYT