Así es como haces una nueva aplicación. Encontrarás varios problemas. Ayer, acabo de resolver el problema de la clase no es visible desde el cargador de clase al cargar una determinada clase. Hoy, encontré el problema de no encontrar el archivo de registro, que está relacionado con la biblioteca de segunda parte. Hablemos de ello uno por uno.
En circunstancias normales, coloque el archivo de configuración logback-spring.xml en el directorio src/main/recursos (usando el sistema de registro logback), como se muestra en la figura a continuación
Establecer spring.application.name = spring-boot-demo-aplicaciones en la aplicación.properties
Un paquete bipartidista tiene logback.xml en él
De acuerdo con la configuración anterior, después de ejecutar, en circunstancias normales, esperamos que el archivo de registro Application.log se incluya en el directorio user.home/spring-boot-demo-application/logs, pero no lo hace. Incluso no se ha generado la carpeta Spring-Boot-Demo-Application.
Así que echemos un vistazo a cómo el sistema de registro encuentra y analiza el archivo de configuración de registro. SpringBoot utiliza la clase LoggingApplicationListener para inicializar el sistema de registro. LoggingApplicationListener implementa la interfaz ApplicationListener. Entonces podemos ver lo que hace el método OnApplicationEvent de LoggingApplicationListener a través de la tabla de sincronización:
Código (8) Encuentre el archivo de configuración de registro estándar. ¿Cuál es el estándar? Luego mire el código de código (9):
Cadena protegida [] getStandardConfigLocations () {return new String [] {"logback-test.groovy", "logback-test.xml", "logback.groovy", "logback.xml"}; }Como "logback-test.groovy", "logback-test.xml", "logback.groovy", "logback.xml" son estándar.
Entonces, cómo encontrar eso depende del código (10):
String private findconfig (string [] ubicaciones) {for (ubicación de cadena: ubicaciones) {classpathResource recursce = new classpathResource (ubicación, this.classLoader); if (resource.exists ()) {return "classpath:" + ubicación; }} return null; }Se puede ver que utilizando la clase ClassPathResource para buscar, veamos el método Exists de ClassPathResource:
public boolean exists () {return (resolveUrl ()! = null); } url protegido resolveUrl () {if (this.clazz! = null) {return this.clazz.getResource (this.path); } else if (this.classLoader! = null) {return this.classLoader.getResource (this.path); } else {return classLoader.getSymitSresurce (this.path); }}Se puede ver que esto.classloader.getResource (this.path); Para encontrar el cargador de clases como AppClassLoader.
Si el código (8) no encuentra la configuración, entonces el punto de ejecución (12). La lógica y el código (8) son similares, pero el nombre del archivo es diferente. Echemos un vistazo a:
Cadena protegida [] GetSpringConfigLocations () {String [] ubicaciones = getStandardConfigLocations (); for (int i = 0; i <ubicación.length; i ++) {string extension = stringUtils.getFileNameExtension (ubicaciones [i]); ubicaciones [i] = ubicaciones [i] .substring (0, ubicaciones [i] .length () - extension.length () - 1) + "-spring". + extensión; } ubicaciones de retorno; }Se puede ver que la primavera está empalmada en el nombre del archivo de getStandardConfiglocations, y el nombre del archivo empalmado es:
"` "Logback-test-spring.groovy", "logback-test-spring.xml", "logback-spring.groovy", "logback-spring.xml"
Para resumir, SpringBoot primero busca el archivo de configuración de registro estándar. Si no puede encontrar el archivo que empalma la configuración de Spring.
Entonces, arriba dijimos que se introdujo un paquete JAR que contiene logback.xml, y este paquete JAR también se carga utilizando AppClassLoader. Por lo tanto, al ejecutar el paso (8), se encontró logback.xml en el paquete JAR, por lo que ya no ejecutaremos el paso (12) para encontrar nuestro logback-spring.xml personalizado.
Solución 1: Modifique nuestro archivo de configuración a logback.xml, de modo que en el paso (8) primero buscará logback.xml, que debe encontrarse.
Solución 2: Evite los paquetes de dos partes que contienen logback.xml. En este caso, no habrá ningún problema si nuestra propia configuración es logback-spring.xml o logback.xml.
En el desarrollo diario, el paquete de segunda parte no debe contener archivos de configuración de registro. Los registros utilizados en la biblioteca de segunda parte generalmente se crean utilizando el código.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.