Primeiro application.yml perfil de configuração é o seguinte:
Maven projeta pom.xml adicionar pacotes:
Crie um novo objeto mapeado com o seguinte código:
O tipo de string deve precisar de um setter para receber valores de propriedade; Mapas, coleções e arrays não são necessários
Use @Autowired anotações para injetar automaticamente, como mostrado na imagem a seguir:
O esConfig sempre gera null, procurei uma solução por muito tempo, mas falhou, haverá uma solução abaixo.
Vamos criar um novo controlador, o código é o seguinte:
A injeção é bem-sucedida, e os valores do arquivo de configuração yml são obtidos normalmente, da seguinte forma:
As razões pelas quais o EsClient não pode ser injetado com sucesso são as seguintes:
Chame uma função dessa classe no construtor, e a variável do @Autowired dessa classe é usada nessa função.
Então achei que poderia dar errado. Porque @Autowired precisa esperar a classe ser construída antes de poder ser definida a partir de referências externas. Portanto, o tempo de injeção de @Autowired deve ser posterior ao tempo de execução do construtor.
A Spring Team recomenda: "Sempre use injeção de dependência baseada em construtores nos seus grãos. Sempre use asserções para dependências obrigatórias".
Tradução:
Spring sugere: "Sempre estabeleça injeção de dependência com construtores no seu grão. sempre use asserções para forçar dependências".
Escrita original:
Escrita modificada:
PS: A ordem de inicialização das variáveis Java é: variáveis estáticas ou blocos de instruções estáticas – variáveis de instância > ou blocos de instruções de inicialização – >método de construção – >@Autowired
Então, por que adicionar o tipo final à variável membro?
Existe uma explicação na Internet da seguinte forma: O escopo do grão padrão na configuração de mola é singleton, que está sempre presente após a inicialização. Declare que o objeto do bean foi criado dinamicamente definindo a propriedade do escopo para prototipo. No entanto, se o seu serviço for um singleton, a injeção é executada apenas uma vez.
@Autowired em si é um modo singleton, ele só será executado uma vez quando o programa iniciar, e não será inicializado uma segunda vez mesmo que não defina um modo final, então esse final é sem sentido.
Pode ser para impedir que o construtor seja executado novamente enquanto o programa está em execução;
Ou talvez seja mais fácil de entender, além de que o final só será inicializado uma vez, quando o programa começar.
|
Publicado em 07/01/2019 15:37:14
|
|
|
|
