É assim que você faz um novo aplicativo. Você encontrará vários problemas. Ontem, acabei de resolver o problema da classe não é visível do carregador de classe ao carregar uma determinada classe. Hoje, encontrei o problema de não encontrar o arquivo de log, que está relacionado à biblioteca de segunda parte. Vamos falar sobre isso um por um.
Em circunstâncias normais, abaixe o arquivo de configuração logback-spring.xml no diretório SRC/Main/Recursos (usando o sistema de logback de log), como mostrado na figura abaixo
Definir spring.application.name = spring-boot-deno-application in Application.properties
Um pacote de duas partes tem logback.xml
De acordo com a configuração acima, após a execução, em circunstâncias normais, esperamos que o arquivo de log do Application.log seja incluído no diretório User.Home/Spring-Boot-Demo-Application/Logs, mas não. Mesmo a pasta Spring-Boot-demo-aplicação não foi gerada.
Então, vamos dar uma olhada em como o sistema de log encontra e analisa o arquivo de configuração de log. O Springboot usa a classe LoggingApplicationListener para inicializar o sistema de log. LoggingApplicationListener implementa a interface ApplicationListener. Então podemos ver o que o método OnApplicationEvent do LoggingApplicationListener faz através do gráfico de tempo:
Código (8) Encontre o arquivo de configuração de log padrão. Qual é o padrão? Em seguida, observe o código do código (9):
String protegido [] 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" estes são padrão.
Então, como encontrar isso depende do código (10):
private string findconfig (string [] locations) {for (string localização: locations) {classPathResource Resource = new ClassPathResource (localização, this.classloader); if (Resource.Exists ()) {return "ClassPath:" + Location; }} retornar nulo; }Pode -se observar que, usando a classe ClassPathResource para pesquisar, vamos ver o método de classe de classe de classe:
public boolean exist () {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.getSystemResource (this.path); }}Pode -se observar que this.classloader.getResource (this.path); Para encontrar o carregador de classe como AppClassLoader.
Se o código (8) não encontrar a configuração, o ponto de execução (12). A lógica e o código (8) são semelhantes, mas o nome do arquivo é diferente. Vamos dar uma olhada em:
String protegido [] getspringConfiglocations () {string [] locations = getStandardConfiglocations (); for (int i = 0; i <locations.length; i ++) {string extension = stringUtils.getFileNameExtension (locais [i]); Locais [i] = Locais [i] .Substring (0, Locais [i] .Length () - Extension.Length () - 1) + "-Spring." + extensão; } retornar locais; }Pode -se ver que a mola é emendada no nome do arquivo de getStandardConfiglocations, e o nome do arquivo emendado é:
"" Logback-test-spring.groovy "," logback-test-spring.xml "," logback-spring.groovy "," logback-spring.xml "
Para resumir, o Springboot primeiro pesquisa o arquivo de configuração de log padrão. Se você não conseguir encontrar o arquivo que emenda a configuração da mola.
Acima, dissemos que um pacote JAR contendo logback.xml foi introduzido no aplicativo, e esse pacote JAR também é carregado usando o AppClassLoader. Portanto, ao executar a etapa (8), o logback.xml no pacote JAR foi encontrado, portanto, não executaremos mais a etapa (12) para encontrar nosso Logback-spring.xml personalizado.
Solução 1: Modifique nosso arquivo de configuração para logback.xml, para que, na etapa (8), você primeiro procure logback.xml, que deve ser encontrado.
Solução 2: Evite os pacotes de duas partes que contêm logback.xml. Nesse caso, não haverá problema se nossa própria configuração é logback-spring.xml ou logback.xml.
No desenvolvimento diário, o pacote de segunda parte não deve conter arquivos de configuração de log. Os logs usados na biblioteca de segunda parte são geralmente criados usando o código.
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.