(Notez qu'il est plus d'une question de Bash qu'une question Java, voir note ci-dessous)Way pour détecter automatiquement mauvais log4j initialisation statique
Lors de la configuration log4j dans chaque classe, nous faisons ce qui suit:
public class Example {
private static final Logger log = Logger.getLogger(Example.class);
Le problème est que nous avons maintenant une base de code de taille moyenne (200K LOC) contenant beaucoup de classes Java et ... Un certain nombre de loggeurs log4j mal configurés.
C'est parce que les gens (y compris moi, je l'avoue), a fait cut'n'paste stupide résultant parfois ceci:
public class Another {
private static final Logger log = Logger.getLogger(Example.class);
Et boum, au lieu d'avoir Another.class, il est l'ancien Exemple.classe qui est à gauche et apparaît donc à tort dans les journaux (causant ainsi pas mal de maux de tête). Je trouve un peu bizarre qu'un tel type de mauvaise configuration puisse se produire mais il peut et notre problème principal n'est pas que cela puisse arriver mais que nous devions réparer les enregistreurs mal configurés.
Comment pouvons-nous les détecter automatiquement? (le correctif peut être manuel mais j'aimerais trouver un moyen de trouver toutes les classes où log4j est mal configuré). Un script shell Bash, par exemple, serait le bienvenu.
- pour chaque fichier .java
- trouver tous les "classe XXX"
- analyser les lignes suivantes 'x' (disons 20)
- est là une ligne Logger.getLogger (...)?
- Si oui, correspond-il à la "classe XXX"?
- si aucun rapport
de faux positifs est pas un problème il est donc pas un problème si quelques faux « classe XXX » sont analysées etc.
NOTE: le problème est vraiment que nous maintenant avoir 200 000 lignes de code et nous aimerions détecter la violation automatiquement (le correctif peut être manuel) donc la question n'est pas similaire à:
[Existe-t-il un meilleur moyen d'obtenir la variable de classe actuelle dans Java ? 1
En fait, il est probablement plus d'une question de Bash qu'une question Java :)
Toute aide sur ce bienvenu.
+1 Votre approche est intéressante. Je n'ai pas songé à changer automagiquement le nom de la classe pour utiliser l'approche make d'usine. Ne vous inquiétez pas du code: Mercurial/hg un peu partout, une couverture de code massive, des tests unitaires etc. Pendant ce temps, j'ai écrit quelque chose de très similaire à ce que Denis a posté et ça a marché. Maintenant, je vais probablement ajouter l'usine et utiliser votre seul doublure. Encore une fois, pas de soucis c'est Mercurial :) – SyntaxT3rr0r