2010-05-16 3 views
0

Dans mon programme, j'ai 2 flux d'événements de journalisation distincts (les appelant flux pour la simplicité, en réalité ses 2 appenders). Stream1 contient la journalisation client et Stream2 contient la journalisation des contrôles. Maintenant, cela peut sembler facile, sauf que certaines classes peuvent être à la fois dans la journalisation du client et la journalisation du serveur, selon la situation. Pour compliquer encore cela, le fait qu'une commande voulue par un client se fasse en 2 threads séparés (dont l'un est extrait aléatoirement à partir d'un pool de threads), donc tout type de suivi avec MDC ou NDC n'est pas possible.Hériter hérité d'une instance d'appel dans log4j ou logback

Ce qui simplifierait vraiment ceci est si l'enregistreur pouvait hériter des appenders de l'instance d'appel. De cette façon, je peux configurer 2 appenders pour 2 enregistreurs et être fait. Cependant, je n'ai aucune idée de comment le faire proprement ou facilement. Quelqu'un peut-il offrir des conseils sur la façon de le faire?

Remarque: Si quelque chose doit être transmis, j'ai un bean d'événement qui est passé à tout dans la chaîne qui peut être utilisé si nécessaire.

Répondre

1

Vous avez déjà mentionné que le traitement client se déroule dans plusieurs threads, donc une simple approche ThreadLocal peut ne pas fonctionner ... mais un ThreadGroupLocal fonctionnerait-il?

Voir [Are there thread group-local variables in Java?

Le tact que je suggère est de n'avoir un appender enregistré avec le cadre de l'exploitation forestière. Cet appender serait quelque chose que vous écrivez. L'implémentation déléguerait à l'appendeur ThreadLocal/ThreadGroupLocal. Le cet appender serait spécifique au client ou au contrôle.

Notez également que votre appender ne doit pas être configuré sous des abstractions asynchrones ou par lots.

+0

Il semble que je créerais un pool pour chaque requête client, ce qui détruirait le point de mutualisation. Sinon, alors je devrais créer un système de journalisation très complexe avec chaque thread ayant une configuration MDC. Techniquement possible, mais absolument ridicule. Et mes espoirs d'utiliser une trace de pile ont été abattu aujourd'hui car j'ai trouvé que la trace ne revenait pas à la classe d'appel, sans surprise. Pensez à son temps pour ce pool de threads personnalisé que je pensais écrire. – TheLQ

+0

En revenant, je vais donner crédit où il est dû. J'ai trouvé une classe ThreadGroupLocal sur le web et utilisé un seul appender qui vérifiait la variable locale. Cela fonctionne très bien, et je veux juste dire, merci! – TheLQ

Questions connexes