J'ai le problème le plus étrange où la résolution de temps en microsecondes pour la journalisation ne fonctionne pas correctement dans certains scénarios, alors que cela fonctionne bien dans d'autres.
Description de l'installation:
Voici la configuration XML de Log4j2:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="ERROR" shutdownHook="disable">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout
pattern="%d{yyyy-MM-dd'T'HH:mm:ss,nnnnnn} [%t] %level{length=5} %c{1} -%equals{ |%marker|}{ ||}{} %msg%n"/>
</Console>
</Appenders>
<Loggers>
<Root level="INFO">
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</Configuration>
Quand je lance cette configuration manuellement via ./gradlew clean bootRun je deviens parfait nous résolution.
Cependant, lorsque j'emballe les fichiers dans un pot de démarrage à ressort "fat" (via ./gradlew clean bootJar et puis l'exécuter, je n'obtiens que des fractions de seconde au niveau des millisecondes.
Bien sûr, le fichier log4j2.xml est correctement emballé dans le cadre du pot de démarrage à ressort.
J'imagine que c'est en quelque sorte lié aux problèmes de chemin de classe, mais pour l'amour de Dieu, je ne peux pas comprendre ce qui cause ce comportement.
Toute aide / suggestion sera très conseillée.
3 Réponses :
Suite à la documentation log4j
Une caractéristique 2.11 qui mérite d'être soulignée est que les horodatages des journaux peuvent désormais avoir une précision de l'ordre de la microseconde ou de la nanoseconde lorsqu'ils sont exécutés sur Java 9.
Êtes-vous sûr de ce que votre application exécute sous le même JRE dans les deux cas?
Positif. De plus, l'application est compilée pour sourceCompatibility = 1.11 , donc elle ne fonctionnerait pas si la situation était différente.
C'est plutôt un commentaire qu'une réponse.
L'API Log4j et les jars d'implémentation sont fournis sous forme de jars à plusieurs versions. Dans leur infinie sagesse, les concepteurs de JDK ignorent que si vous empaquetez les jars dans un autre jar qui n'a pas l'en-tête multi-release: true manifest. Sans cela, vous n'exécuterez aucun des supports Java 9+ intégrés à Log4j.
En bout de ligne, ajoutez l'en-tête multi-release: true au manifeste du fichier jar de l'application Spring Boot.
Oui, je l'ai déjà compris. Jamais eu le temps de l'écrire comme une réponse. Quoi qu'il en soit - vous avez raison. Merci :) Aussi, je pense que ces classes ont changé, et que ce serait différent de la prochaine version.
cela s'est avéré être un problème de démarrage de printemps. modifier le manifeste n'a pas aidé. 10x quand même.
MISE À JOUR : même si @rgoers avait techniquement raison dans son observation, l'ajout de l'indicateur multi-version au manifeste n'a pas résolu le problème. Il s'est avéré que c'était un problème de spring boot 2 dans le fonctionnement, maintenant résolu avec Spring boot 2.1.2 (peut-être même sur 2.1.1).
La journalisation se comporte désormais correctement sans modifier le manifeste.
Des informations supplémentaires peuvent être trouvées ici - https://github.com / spring-projects / spring-boot / issues / 12523
Je suis d'accord que c'est étrange. Lorsque vous définissez
status = “TRACE”dans la configuration, log4j imprimera sa journalisation interne sur la console. Pouvez-vous partager ce que vous voyez dans les deux cas?Je pense que je suis sur quelque chose. Mettra à jour rapidement