pas capable de mettre les valeurs dans le MDC
Je suis en train de journal quelques valeurs dans le onBeginRequest()
de RequestCycle()
au guichet.
Mais les valeurs ne sont pas enregistrées dans le fichier de débogage. Je suis en train de monter les valeurs dans le MDC en RequestCycleListeners()
.
Voici le code:
getRequestCycleListeners().add(new AbstractRequestCycleListener()
{
public void onBeginRequest(RequestCycle cycle)
{
if( cycle.getRequest().getContainerRequest() instanceof HttpServletRequest )
{
HttpServletRequest containerRequest =
(HttpServletRequest)cycle.getRequest().getContainerRequest();
MDC.put("serverName", containerRequest.getServerName());
MDC.put("sessionId", containerRequest.getSession().getId());
LOGGER.debug("logging from RequestCycleListeners() !!!");
WebClientInfo webClientInfo = new WebClientInfo(RequestCycle.get());
System.out.println(webClientInfo.getUserAgent());
System.out.println("webClientInfo.getProperties().getBrowserVersionMajor() " +containerRequest.getRemoteAddr());
}
};
Je suis dans l'attente d' 'serverName', 'sessionId" pour être enregistré dans le fichier de débogage.
J'ai ajouté ce listener
dans la classe qui est l'extension de la WebApplication
.
Je suis en utilisant log4j.xml le DEBUG appender
est comme ci-dessous:
<appender name="DEBUG" class="org.apache.log4j.rolling.RollingFileAppender">
<param name="Append" value="true"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="[%d{ISO8601} %t %5p] %m -- %X{serverName} -- %X{sessionId} -- %X{portNumber}%n"/>
</layout>
<filter class="org.apache.log4j.varia.LevelRangeFilter">
<param name="LevelMin" value="DEBUG"/>
<param name="LevelMax" value="WARN"/>
</filter>
</appender>
et nous sommes à la définition du champ d'action dans la balise racine :
<root>
<priority value="INFO" />
<appender-ref ref="CONSOLE" />
<appender-ref ref="DEBUG" />
<appender-ref ref="ERROR" />
</root>
Qu'est-ce que MDC ici?
Ses un mécanisme de journalisation. Vous pouvez en voir plus ici slf4j.org/api/org/slf4j/MDC.html
Quel enregistrement cadre utilisez-vous sous slf4j? log4j, logback, java.util.la journalisation, commons logging?
pour l'instant, log4j
Pourriez-vous ajouter votre
Ses un mécanisme de journalisation. Vous pouvez en voir plus ici slf4j.org/api/org/slf4j/MDC.html
Quel enregistrement cadre utilisez-vous sous slf4j? log4j, logback, java.util.la journalisation, commons logging?
pour l'instant, log4j
Pourriez-vous ajouter votre
log4j
de configuration et quelques exemples de journalisation à partir de votre application à la question s'il vous plaît? Il peut aider. Merci.OriginalL'auteur Ram Dutt Shukla | 2013-05-29
Vous devez vous connecter pour publier un commentaire.
Généralement, MDC valeurs ne sont de sortie pour les journaux, si vous incluez MDC clés dans votre modèle grâce à la journalisation de la configuration. Depuis slf4j est juste une façade, vous devez disposer d'un cadre spécifique de support et de configuration sous slf4j de faire usage de la MDC. Lire slf4j notes que ici.
Ainsi, par exemple, si vous utilisez log4j que l'impl sous slf4j, alors vous devez log4j config (ConversionPattern) comme:
Où
%X{serverName} %X{sessionId}
est la partie pertinente qui tire les valeurs de la MDC.Iciest un assez bon exemple d'utilisation de log4j sans sl4j. Voir les notes sur
X
Caractère de Conversion en log4j javadoc ici.Noter que la syntaxe des masques pour logback est identique. Voir les détails de la logback ici.
Également noter que la meilleure pratique pour les MDC (qui utilise un
ThreadLocal
sous le capot) est de vider le contexte (supprimer les valeurs que vous mettez dans la map) lorsque le contexte n'est plus dans la portée. Que signifie, en général, l'appel deremove
ouclear
dans unfinally
bloc, comme:Ceci est particulièrement important si le fil qui tient le MDC appartient à une piscine pour les réutiliser ultérieurement. Vous ne voulez certainement pas involontaire de journal non valide contexte de valeurs, car cela ne fera que causer de la confusion.
MODIFIER
Votre configuration log4j semble un peu bizarre, pour les raisons suivantes:
RollingFileAppender
ne permet pas de définir un fichier deroot
enregistreur de journal à 3 appenders, dont l'un est nomméDEBUG
, mais il est configuré pour se connecter uniquementINFO
niveau et plus (basé sur lepriority
tag), de sorte que des instructions de débogage ne sera pas connectéSauf si vous avez certaines catégories spécifiques configuré séparément qui ne sont pas affichés, je suppose que aucun de votre
LOGGER.debug
consolidés sont enregistrés, quel que soit votre tentative d'utilisation de la MDC.J'ai essayé la même manière que vous le suggérez dans votre réponse en citant la veera-sundar du blog, Mais le problème est un peu différent
Je suis d'accepter cette réponse parce que l'explication est tout à fait utile. Si elle n'est pas d'avoir la bonne réponse mais il m'aide à trouver la réponse.
J'ai remarqué que vous unaccepted ma réponse. Veuillez voir les ajouts que j'ai fait pour la section d'ÉDITION. Il peut vous aider avec votre journalisation des problèmes.
Oui, la raison de l'exploitation forestière a été le <root> tag. Vous êtes de droite. Maintenant, je vais à nouveau accepter la réponse merci.
OriginalL'auteur superEb
Notez que si vous utilisez AsyncAppender, la compensation MDC à partir de votre fil ne sera pas vous protéger, depuis le journal des événements et le MDC de la manipulation qui se passe dans le AsyncAppender du fil. Voir aussi ce bug
Malheureusement, dans v1.2.17 la dernière version de la EOLed log4j-1.x, le AsyncAppender du Répartiteur du Thread n'est pas clair que le MDC à l'arrêt.
Depuis, le AsyncAppender/Répartiteur est assez simple, il est facile de le patcher en mettant
à l'essayer à bloc org.apache.log4j.AsyncAppender.Répartiteur.run() méthode.
Bien sûr, on peut également contourner ce problème en n'utilisant pas AsyncAppender lors de l'exécution dans un ServletContainer.
OriginalL'auteur Jörg