Lors de la vérification de la Javadoc pour modèleLayout, j'ai remarqué qu'il recommande d'utiliser AméliorerPatternlayout à la place. Cependant, il semble faire à peu près la même chose.
Quelles sont les principales différences, en particulier celles que je dois savoir?
Je me demande également pourquoi ils ont fait une classe distincte plutôt que d'améliorer la classe d'origine. Toute différence de syntaxe?
4 Réponses :
vérifier le Documentation , tout est expliqué. modèleLayout contient des problèmes qui sont pas présent dans EnhancedPatternlayout surtout avec la synchronisation. EnhancoDeDPatternlayout est une version améliorée de modèleLayout . Il devrait être utilisé de préférence à motiflayout (à l'exception de la raison de la compatibilité avec motifLayout ).
J'ai posé cette question exactement parce que j'avais déjà vérifié la documentation et rien n'est expliqué. Oui, il est amélioré, je peux voir cela de son nom aussi, mais amélioré Comment ?
Donc, cela signifie que AméliorerPatternlayout n'a que des changements internes, mais il est utilisé exactement de la même manière?
Presque, il y a des caractères de conversion supplémentaires dans améliorépatternlayout qui ne sont pas disponibles dans motifLayout. Sinon, il semble être le même. Je ne suis pas un expert Java, vous pouvez donc vérifier vous-même en comparant les deux pages de documentation et / ou des sources.
EnhancedPatternlayout forme le résultat en tant que Stringbuffer, tandis que le modèleLayout achève le résultat en tant que chaîne.
La principale différence entre modèleLayout et EnhancedPatternlayout est dans la méthode Format (). MotifLayout repose sur un champ de membre nommé SBUF qu'il modifie alors que AméliorerPatternLayout utilise une instance privée de Stringbuffer. Cela signifie que les appels de motifLayout.Format () sont sensibles aux races de données lors d'appels simultanés, tandis que les appels simultanés d'amélioration de Patternlayout.Format () ne sont pas.
Oui. Il s'agit d'un peu de mystère que dans quelles conditions le champ SB de modèle de modèle SB de modèle peut causer des problèmes réels - car les appels sont des synchronisé de toute façon - au appendererskeleton .Doappend () méthode (voir par exemple des sources de log4J 1.2.17). Donc, le améliorépatternlayout semble pour apporter une utilisation accrue inutile de GC. Et je n'ai jamais vu de sortie cassée / mixte dans les journaux tout en utilisant modèleLayout ...
Si les appels sont toujours synchronisés, il est potentiellement avantageux d'être avantages en convertissant la Stringbuffer en StressBuilder dans les deux classes de mise en page. Je suppose que les appels d'annexe ne sont pas garantis pour être synchronisés dans tous les scénarios?
Eh bien, c'est exactement la question - lorsque les appels ne sont pas garantis pour être synchronisés ... concernant StringBuilder, la bibliothèque Log4J ne peut pas utiliser cette classe en raison de la compatibilité avec les anciennes versions de Java qu'elles soutiennent ...
Je l'ai fait un diff sur les deux pages HTML.
Et voici les principales différences par rapport à moi: L'intro et deux nouveaux "caractère de conversion" s: J'ai reformaté le texte pour faciliter la lecture.
Cette classe est une version améliorée de Cette calepinage doit être utilisé de préférence à
Utilisé pour la sortie des propriétés associées
avec l'événement d'enregistrement.
Propriétés
mot de conversion peut être suivie par la clé de la
map placé entre accolades, comme dans (reformatée pour une meilleure lisibilité.)
Utilisé pour la sortie de la trace Throwable qui a été lié au % propriétés et % throwable
1. Intro
org.apache.log4j.PatternLayout
qui a été développé à l'origine dans le cadre de l'log4j abandonnée 1.3
effort et a été disponible dans le compagnon de figurants.
org.apache.log4j.PatternLayout sauf si la compatibilité
où PatternLayout a été étendu soit par subclassing
ou analyseurs de motif alternatif.
2.
Propriétés%
Propriétés% {application} où
application est la clé. La valeur dans le faisceau Propriétés
correspondant à la clé sera sortie. Si aucun sous-option supplémentaire
est spécifiée, le contenu de la valeur des propriétés paire de clés jeu
est sortie en utilisant un format {{key1, val1}, {key2, val2}}
3.
% throwable
LoggingEvent , par défaut, cette sortie la trace complète que l'on devrait normalement trouver par un appel à Throwable.printStackTrace () < / code>.
% throwable {short} ou % throwable {1} va afficher la première ligne de trace de la pile.
{throwable none} ou throwable {0} supprimer la trace de la pile.
% throwable {n} sortie n lignes de trace de pile si un nombre entier positif ou omettre le dernier -n lignes, si un négatif entier.
% throwable , le appender prendra en charge à la sortie de la trace de la pile comme il l'entend.
Au moins une différence majeure est le support des fuseaux horaires - voir Stackoverflow.com/Questtions/1785725/... .