Primero, application.yml perfil de configuración es el siguiente:
Maven Project pom.xml añadir paquetes:
Crea un nuevo objeto mapeado con el siguiente código:
El tipo de cadena debe necesitar un setter para recibir los valores de propiedad; No se requieren mapas, colecciones ni arrays
Utiliza @Autowired anotaciones para inyectar automáticamente, como se muestra en la siguiente imagen:
esConfig siempre da la salida nula, busqué una solución durante mucho tiempo pero falló, habrá una solución abajo.
Creemos un nuevo controlador, el código es el siguiente:
La inyección es exitosa y los valores del archivo de configuración yml se obtienen normalmente, de la siguiente manera:
Las razones por las que EsClient no puede ser inyectado con éxito son las siguientes:
Llama a una función de esta clase en el constructor, y la variable de la @Autowired de esta clase se utiliza en esta función.
Así que pensé que podría salir mal. Porque @Autowired debe esperar a que la clase se construya antes de poder establecerse a partir de referencias externas. Por lo tanto, el tiempo de inyección de @Autowired debe ser posterior al tiempo de ejecución del constructor. Solución:
Spring Team recomienda "Siempre usa inyección de dependencia basada en constructores en tus granos. Siempre usar aserciones para dependencias obligatorias".
Traducción:
Spring sugiere: "Establece siempre la inyección de dependencia con constructores en tu grano. siempre usar aserciones para forzar dependencias".
Escritura original:
Escritura modificada:
PD: El orden de inicialización de las variables Java es: variables estáticas o bloques de sentencias estáticas – > variables de instancia o bloques de sentencia de inicialización – >método de construcción – >@Autowired
Entonces, ¿por qué añadir el tipo final a la variable miembro?
Hay una explicación en Internet de la siguiente manera: El alcance del grano por defecto en la configuración de resorte es singleton, que siempre está ahí tras el arranque. Declara que el objeto del bean ha sido creado dinámicamente estableciendo la propiedad de alcance como prototipo. Sin embargo, si tu servicio en sí es un singleton, la inyección solo se ejecuta una vez.
@Autowired en sí es un modo singleton, solo se ejecutará una vez cuando inicie el programa, y no se inicializará una segunda vez aunque no defina una final, por lo que esta final carece de sentido.
Puede ser para evitar que el constructor se ejecute de nuevo mientras el programa está en ejecución;
O quizá sea más fácil de entender, además el examen final solo se inicializará una vez cuando empiece el programa.
|