C'est ainsi que vous faites une nouvelle application. Vous rencontrerez divers problèmes. Hier, je viens de résoudre le problème de la classe n'est pas visible du chargeur de classe lors du chargement d'une certaine classe. Aujourd'hui, j'ai rencontré le problème de ne pas trouver le fichier journal, qui est lié à la bibliothèque secondaire. Parlons-en un par un.
Dans des circonstances normales, réduisez le fichier de configuration logback-pring.xml dans le répertoire SRC / Main / Resources (en utilisant le système de journal de journal de journal), comme indiqué dans la figure ci-dessous
Set Spring.Application.Name = Spring-Boot-Demo-Application in Application.Properties
Un package bipartite a un logback.xml dedans
Selon la configuration ci-dessus, après l'exécution, dans des circonstances normales, nous espérons que le fichier journal Application.log devrait être inclus dans le répertoire User.Home / Spring-Boot-Demo-Application / Logs, mais ce n'est pas le cas. Même le dossier Spring-Boot-Demo-Application n'a pas été généré.
Voyons donc comment le système de journal trouve et analyse le fichier de configuration du journal. Springboot utilise la classe LoggingApplicationListener pour initialiser le système de journal. LoggingApplicationListener implémente l'interface applicationListener. Ensuite, nous pouvons voir ce que fait la méthode LoggingApplicationListener sur ONApplicationEvent via le tableau de synchronisation:
Code (8) Recherchez le fichier de configuration du journal standard. Quelle est la norme? Regardez ensuite le code du code (9):
String protégé [] getStandardConfigLocations () {return new String [] {"Logback-Test.Groovy", "Logback-Test.xml", "logback.groovy", "logback.xml"}; }Comme "Logback-Test.Groovy", "Logback-Test.xml", "Logback.Groovy", "Logback.xml" Ce sont des standard.
Alors, comment trouver cela dépend du code (10):
String privé findConfig (String [] Locations) {for (String Location: Locations) {ClassPathResource Resource = new ClassPathResource (emplacement, this.classloader); if (ressource.exists ()) {return "classPath:" + location; }} return null; }On peut voir que l'utilisation de la classe ClassPathResource pour rechercher, voyons la méthode existant de ClassPathResource:
Public Boolean existe () {return (résolveUrl ()! = null); } URL protégé ResolveUrl () {if (this.clazz! = null) {return this.clazz.getResource (this.path); } else if (this.classloader! = null) {return this.classloader.getResource (this.path); } else {return classloadher.getSystemResource (this.path); }}On peut voir que this.classloader.getResource (this.path); Pour trouver le Classloader en tant qu'AppClassloader.
Si le code (8) ne trouve pas la configuration, alors le point d'exécution (12). La logique et le code (8) sont similaires, mais le nom du fichier est différent. Jetons un coup d'œil:
String protégé [] GetSpringConfigLocations () {String [] Locations = GetStandardConFigLocations (); for (int i = 0; i <locations.length; i ++) {string extension = stringUtils.getFileNameExtension (Locations [i]); emplacements [i] = emplacements [i] .substring (0, emplacements [i] .length () - extension.length () - 1) + "-spring." + extension; } Emplacements de retour; }On peut voir que le printemps est épissé sur le nom de fichier de GetStandardConfiglocations, et le nom de fichier épissé est:
«« Logback-Test-Spring.groovy »,« Logback-Test-Spring.xml »,« Logback-Spring.groovy »,« Logback-Spring.xml »
Pour résumer, Springboot recherche d'abord le fichier de configuration du journal standard. Si vous ne trouvez pas le fichier qui épisse la configuration de ressort.
Donc, ci-dessus, nous avons dit qu'un package JAR contenant Logback.xml avait été introduit dans l'application, et ce package JAR est également chargé à l'aide d'AppClassloader. Par conséquent, lors de l'exécution de l'étape (8), le logback.xml dans le package JAR a été trouvé, nous n'exécuterons plus l'étape (12) pour trouver notre logback-spring.xml personnalisé.
Solution 1: Modifiez notre fichier de configuration sur logback.xml, de sorte qu'à l'étape (8), vous rechercherez d'abord Logback.xml, qui devrait être trouvé.
Solution 2: Évitez les packages bipartites contenant du logback.xml. Dans ce cas, il n'y aura aucun problème, que notre propre configuration soit logback-spring.xml ou logback.xml.
Dans le développement quotidien, le package secondaire ne doit pas contenir de fichiers de configuration de journal. Les journaux utilisés dans la bibliothèque secondaire sont généralement créés à l'aide du code.
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.