Log4j ne connecte rien

Voir cette réponse: Comment initialiser le log4J correctement?

-dlog4j.debug est très utile pour des problèmes tels que celui-ci

Je me rends compte que ce n'est pas votre même symptôme, mais il existe des problèmes connus avec Log4J si votre application (ou tout ce qu'elle utilise) utilise la journalisation des communes. Voir si Cette question / réponse est pertinente.

La chose la plus récente que j'ai changée qui a finalement eu la journalisation fonctionnant correctement modifiait le mode ClassLoader en "Parent_first" et la stratégie de classeur de guerre à "Application". La configuration par défaut initiale était "parent_first" / "module". Je l'ai changé à "Parent_last" / "Application" sur les conseils d'un collègue qui dit que la journalisation fonctionne correctement pour eux et c'est le seul changement qu'ils doivent faire lors de la création d'une nouvelle boîte à sable pour cette application. Je ne sais pas pourquoi je devais aller avec "parent_first" / "application", mais au moins cela fonctionne maintenant.

mise à jour:

J'ai essayé de mettre en place un nouvel espace de travail et j'ai eu le même problème. Il s'avère que vous avez besoin de "parent_first" / "application" et d'un fichier nommé org.apache.commons.logging.logging.logfactory dans les méta-inf / services avec une ligne contenant: "org.apache.commons.logging.impl.log4jfactory" . Ne pas avoir le fichier provoque l'échec de l'enregistrement (généralement avec un message indiquant qu'un log4j introuvable).

Ne pas capable de créer un fichier journal, j'ai utilisé le fichier logback.xml dans l'application Springservice et déployé dans WebSphere Server ... mais lorsque j'ai utilisé le fichier log4j.properties, il crée un fichier journal. J'ai donné une dépendance appropriée appropriée pour log4J et slf4j .. logback.xml fichier
xxx pré>

` p>

Dépendance: P>

<dependency>
    <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>${slf4j.version}</version>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>${logback.version}</version>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-core</artifactId>
      <version>${logback.version}</version>
    </dependency>

J'ai eu un problème où Log4j n'était rien montrant dans l'un de mes projets. SÇi J'avais ajouté un espace de tête dans le nom de classe dans le fichier log4j2.xml. Log4J fait un dictionnaire de dictionnaire par nom de classe. Donc, tout espace de tête ou de fuite dans le nom de classe rendrait cette entrée particulière invalide.

Juste mes deux cents - j'avais quelque chose comme ça se produisant - mais dans mon cas, je pouvais voir certaines sorties de mes appels de journalisation. Il était évident que la configuration a été reprise d'ailleurs et celle que j'avais changée n'avait aucun impact.

Après avoir tourné -dlog4j.debug = true comme suggéré ici, il était évident que Log4J ramassait un fichier nommé log4j.xml situé dans le répertoire de travail de mon Tomcat. Soit c'était un reste d'autres choses que je faisais, soit il a été généré en quelque sorte à partir d'une certaine configuration log4j dans l'une de mes bibliothèques mal configurées.

Je n'ai pas pensé à effacer le contenu du répertoire de travail (aurait pu essayer .. [Modifier: J'ai essayé et ça n'a pas fonctionné]) - La seule chose que je pense que je devais transmettre une référence codée à mon fichier de propriétés via -dlog4j.configuration = log4j.properties (ne voulait pas utiliser le chemin absolu) (c'est arrivé que j'utilisais un fichier de propriétés et non un XML) - et cela fonctionnait.

[EDIT: Eh bien, cela n'a pas fonctionné pour la configuration du serveur. J'ai enfin trouvé ce qui n'allait pas - certaines bibliothèques cuits à la maison que j'avais incluses comme des pots dans mon projet, avaient leurs propres fichiers log4j.xml et log4j.properties, qui ont apparemment été lus / trouvés plus tôt que mon propre fichier de propriétés - la chose la plus droite était de supprimer ces fichiers de propriété redondants de JARS]