هذه هي الطريقة التي تقوم بها بتطبيق جديد. سوف تواجه مشاكل مختلفة. بالأمس ، لقد حللت مشكلة الفصل ليست مرئية من Loader Class عند تحميل فئة معينة. واجهت اليوم مشكلة عدم العثور على ملف السجل ، الذي يرتبط بمكتبة الطرف الثاني. دعنا نتحدث عن ذلك واحدًا تلو الآخر.
في ظل الظروف العادية ، قم بإخماد ملف تكوين Logback-spring.xml في دليل SRC/Main/Resources (باستخدام نظام سجل الظهور) ، كما هو موضح في الشكل أدناه
set spring.application.name = spring-boot-demo-application in application.properties
تحتوي حزمة من حفلتين على logback.xml فيه
وفقًا للتكوين أعلاه ، بعد التشغيل ، في ظل الظروف العادية ، نأمل أن يتم تضمين ملف سجل التطبيق. حتى مجلد Application الربيعي-Boot-Demo لم يتم إنشاؤه.
لذلك دعونا نلقي نظرة على كيفية العثور على نظام السجل وتوصيف ملف تكوين السجل. يستخدم Springboot فئة LoggingAppLicationLicationListener لتهيئة نظام السجل. يقوم LoggingApplicationLicationListener بتنفيذ واجهة ApplicationListener. ثم يمكننا أن نرى ما هي طريقة onapplicationEvent التي تقوم بها تسجيل الدخول من خلال مخطط التوقيت:
الكود (8) ابحث عن ملف تكوين السجل القياسي. ما هو المعيار؟ ثم انظر إلى رمز الكود (9):
سلسلة محمية [] getStandardConfigLocations () {return new string [] {"Logback-test.groovy" ، "Logback-test.xml" ، "logback.groovy" ، "logback.xml"} ؛ }مثل "Logback-test.groovy" ، "Logback-test.xml" ، "Logback.groovy" ، "Logback.xml" هذه قياسية.
إذن كيف تجد ذلك يعتمد على الكود (10):
سلسلة خاصة FindConfig (String [] SOCATIONS) {for (سلسلة الموقع: المواقع) {classPathResource Resource = new ClassPathResource (الموقع ، this.classloader) ؛ if (resource.exists ()) {return "classpath:" + location ؛ }} الإرجاع null ؛ }يمكن ملاحظة أن استخدام فئة ClassPathResource للبحث ، دعنا نرى الطريقة الموجودة في ClassPathResource:
يوجد منطقي عام () {return (solveUrl ()! = null) ؛ } URL المحمي ResolveUrl () {if (this.clazz! = null) {return this.clazz.getResource (this.path) ؛ } آخر إذا (this.classloader! = null) {return this.classloader.getResource (this.path) ؛ } آخر {return classLoader.getSystemResource (this.path) ؛ }}يمكن ملاحظة أن this.classloader.getResource (this.path) ؛ للعثور على classloader كـ AppClassloader.
إذا لم يجد الرمز (8) التكوين ، فإن نقطة التنفيذ (12). المنطق والرمز (8) متشابهان ، لكن اسم الملف مختلف. دعونا نلقي نظرة على:
سلسلة محمية [] getPringConfigLocations () {string [] المواقع = getStandardConfigLocations () ؛ لـ (int i = 0 ؛ i <socations.length ؛ i ++) {string extension = stringUtils.getFilenameExtense (المواقع [i]) ؛ المواقع [i] = المواقع [i] .substring (0 ، المواقع [i] .length () - extension.length () - 1) + "-Spring." + تمديد ؛ } مواقع الإرجاع ؛ }يمكن ملاحظة أن الربيع يتم تقطيعه على اسم ملف GetStandardConfigLocations ، واسم الملف المربع هو:
"` `“ Logback-test-spring.groovy "،" logback-test-spring.xml "،" Logback-spring.groovy "،" Logback-spring.xml "
لتلخيص ، يبحث Springboot أولاً عن ملف تكوين السجل القياسي. إذا لم تتمكن من العثور على الملف الذي يربط تكوين الربيع.
لذلك ، قلنا أنه تم تقديم حزمة JAR التي تحتوي على logback.xml في التطبيق ، ويتم تحميل حزمة JAR هذه أيضًا باستخدام AppClassLoader. لذلك ، عند تنفيذ الخطوة (8) ، تم العثور على logback.xml في حزمة JAR ، لذلك لن ننفذ الخطوة (12) للعثور على نسخ التسجيل الخاص بنا.
الحل 1: تعديل ملف التكوين الخاص بنا إلى logback.xml ، بحيث في الخطوة (8) ، ستبحث أولاً عن logback.xml ، والتي يجب العثور عليها.
الحل 2: تجنب الحزم ثنائية الحزبين التي تحتوي على logback.xml. في هذه الحالة ، لن تكون هناك مشكلة فيما إذا كان التكوين الخاص بنا هو التسجيل spring.xml أو logback.xml.
في التطوير اليومي ، يجب ألا تحتوي حزمة الطرف الثاني على ملفات تكوين السجل. يتم إنشاء السجلات المستخدمة في مكتبة الطرف الثانية بشكل عام باستخدام الكود.
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.