Je développe un cadre et je veux que le pot soit léger et indépendant autant que possible.
Alors j'ai écrit une classe de journalisation: P>
import java.util.Date;
import java.util.Properties;
public class Logger {
private static final Logger me = new Logger();
private static boolean info = false;
private static boolean debug = false;
private static boolean error = false;
private static String className = null;
public static Logger getInstance(Class<?> clazz) {
className = clazz.getCanonicalName();
try {
Properties props = new CustProps().load(clazz);
if(props.get(CustProps.NAME_LOG_MODE) != null) {
String devMode = props.getProperty(CustProps.NAME_LOG_MODE)
.toLowerCase();
if("info".equals(devMode)) {
info = true;
debug = true;
} else if("debug".equals(devMode)) {
debug = true;
}
}
} catch (Exception e) {
// debug is error by default
}
error = true;
return me;
}
public void logError(Object msg) {
if(isError()) {
System.out.println(new Date().toString()
+ " ERROR ["+Logger.className+"] - " + msg);
}
}
public void logDebug(Object msg) {
if(isDebug()) {
System.out.println(new Date().toString()
+ " DEBUG ["+Logger.className+"] - " + msg);
}
}
public void logInfo(Object msg) {
if(isInfo()) {
System.out.println(new Date().toString()
+ " INFO ["+Logger.className+"] - " + msg);
}
}
public boolean isInfo() { return Logger.info; }
public boolean isDebug() { return Logger.debug; }
public boolean isError() { return Logger.error; }
}
log4j code>)? LI>
ul> p>7 Réponses :
Vous n'aimez pas java.util.logging.logger? Il est inclus dans JDK, vous n'avez besoin de rien d'autre.
Cela étant dit (trottoir votre enthousiasme), Java Loggings atteint ce qui était autrefois pensé physiquement impossible en ce sens qu'il suce et souffle en même temps.
@Trick, avez-vous déjà eu le plaisir de reconfigurant j.u.l journalisation?
@cletus ayant dit que (Seinfeld)
Pourquoi réinventer la roue?
Si vous utilisez la bibliothèque de journalisation Java UTIL UTIL, elle est déjà dans le JDK et vous n'avez donc aucun code supplémentaire à fournir.
Sinon, log4j est sûrement très bon.
Utilisez log4j. Ce n'est pas un cadre forfaitaire lourd de poids, que voulez-vous dire par «indépendant autant que possible»?
Ajoutez simplement le journal log4j à votre cadre et vous êtes prêt à partir.
Rien n'est plus léger que d'utiliser Java. util.logging.logger , car il est déjà disponible dans le JRE.
Je vous recommanderais vivement d'utiliser SLF4J comme API de journalisation, car il est conçu pour pouvoir commuter les backends au moment du déploiement. En d'autres termes, si vous avez déjà dépassé votre propre cadre de journalisation ou que vous devez interfacer avec d'autres personnes en utilisant autre chose, il est simple de changer d'avis.
Il vous permet également d'utiliser le {} -construction pour une insertion facile d'insertion dans vos chaînes de journal sans frais générale si cette chaîne n'est pas réellement connectée de toute façon (ce qui est vraiment agréable).
Je vais vous suggérer que vous envisagez d'adapter le revue "simple" à vos besoins car cela fournit probablement 90% de ce que vous voulez.
http://www.slf4j.org/apidocs/org/ SLF4J / Impl / SimpleLogger.html
Remarque: N'utilisez aucun backend directement (comme log4j ou java.util.logging) car il verra essentiellement votre code à ce backend. Utiliser une façade.
Étant donné que les cadres d'exploitation forestière tels que Java.Util.log * ou Log4J sont assez extensibles et configurables, cela vaut vraiment la peine d'être passée via une façade (admité une très bonne façade). Avez-vous déjà rencontré un besoin qui n'est pas rencontré par Log4J?
slf4j fournit le {} -construction. Cela seul garantit l'utilisation partout.
Merci pour la recommandation, mais toujours - pour java.util.logging.logger, je n'ai pas besoin d'importations supplémentaires.
Maintenant, 10 ans plus tard, je pense que la conception derrière SLF4J (comme l'API de Logback) est cassée dans cette journalisation ne doit pas être un peu invisible de votre application, mais un composant de première classe. Pour un nouveau projet, je recommanderais de regarder dans la version 2 de Log4J et d'utiliser l'API native. journalisation.apache.org/log4j/2.x
Je suis d'accord avec les autres commentaires - utilisez un outil de lits (enregistreur, log4j ou autre). L'écriture et la maintien de votre propre sont (généralement) ne valent pas la peine.
Un point de plus à prendre en compte: Si votre framework contient un autre logiciel tiers que vous souhaitez intégré dans un fichier journal, vous devez utiliser un outil partagé (par exemple, celui pris en charge par ce logiciel tiers). Il est souvent très utile d'avoir toutes les pièces du système consolider les journaux dans un endroit.
Vous posez trois questions:
Comme d'autres l'ont noté, la meilleure pratique consisterait à le remplacer entièrement, soit avec quelque chose comme Log4J ou SLF4J, soit pour répondre à votre objectif «Indépendance», simplement avec Java.Util.logger.
Non, sauf dans des circonstances très spécialisées, où pour une raison quelconque, les cadres existants ne répondent pas à vos besoins. Vous n'avez rien dit pour indiquer que cela pourrait être le cas.
Oui, si, sans autre raison que cela, il faudra que d'autres mainteneurs passent quelques minutes à lire votre classe de journalisation lorsqu'ils entrent dans votre codeBase. L'utilisation d'un cadre existant signifie qu'ils savent déjà ce que cela fait.
Conseil sensible. J'ai perdu le nombre de fois où je vois des gens qui écrivent leurs propres cadres (souvent assez bons), mais ils perdent leur intérêt au moment de leur document.
Très bonne réponse. Mais j'ai eu une question de suivi. Nous avons un produit avec 5 micro-services différents. Nous développons une bibliothèque commune pour cela pour gérer les préoccupations transversales. Quelles fonctionnalités de journalisation courantes pourraient être traitées? J'ai pensé à un couple comme: 1- Modèle de journalisation, 2- Logging Library Activités, 3- Configuration de la journalisation commune. Mais essayant de trouver plus de valeurs. Merci d'avance.
@Mustafamohammedi pose comme une question à sa propre question, et cela aura plus de traction. De plus, vous devrez spécifier un peu plus d'informations sur le problème. Je ne vois toujours pas pourquoi vous voulez développer une bibliothèque de journalisation commune. La roue est assez bonne car elle est.