Premier application.yml profil de configuration est le suivant :
Maven Project pom.xml ajouter des packages :
Créez un nouvel objet mappé avec le code suivant :
Le type de chaîne doit nécessiter un régleur pour recevoir la valeur des propriétés ; Les cartes, collections et tableaux ne sont pas requis
Utilisez @Autowired annotations pour injecter automatiquement, comme montré sur l’image suivante :
esConfig affiche toujours la nul, j’ai cherché une solution longtemps, mais échoué, il y aura une solution ci-dessous.
Créons un nouveau contrôleur, le code est le suivant :
L’injection est réussie, et les valeurs du fichier de configuration yml sont obtenues normalement, comme suit :
Les raisons pour lesquelles EsClient ne peut pas être injecté avec succès sont les suivantes :
Appelez une fonction de cette classe dans le constructeur, et la variable de la @Autowired de cette classe est utilisée dans cette fonction.
Alors je me suis dit que ça pourrait mal tourner. Parce qu@Autowired doit attendre que la classe soit construite avant de pouvoir être définie à partir de références externes. Par conséquent, le temps d’injection de @Autowired doit être plus postérieur que le temps d’exécution du constructeur.
Spring Team recommande « Utilisez toujours l’injection de dépendance basée sur des constructeurs dans vos grains. Utilisez toujours des assertions pour les dépendances obligatoires ».
Traduction :
Spring suggère : « Établissez toujours une injection de dépendance avec des constructeurs dans votre grain. utilisez toujours des assertions pour forcer des dépendances ».
Écriture originale :
Écriture modifiée :
PS : L’ordre d’initialisation des variables Java est : variables statiques ou blocs d’instructions statiques – > variables d’instance ou blocs d’instructions d’initialisation – >méthode de construction – >@Autowired
Alors pourquoi ajouter le type final à la variable membre ?
Il existe une explication sur Internet suivante : la portée du grain par défaut dans la configuration à ressort est singleton, qui est toujours présente après le démarrage. Déclarez que l’objet du bean est créé dynamiquement en définissant la propriété de portée sur prototype. Cependant, si votre service lui-même est un singleton, l’injection n’est effectuée qu’une seule fois.
@Autowired lui-même est un mode singleton, il ne sera exécuté qu’une seule fois au début du programme, et il ne s’initialisera pas une seconde fois même s’il ne définit pas de mode final, donc ce final est dénué de sens.
Cela peut être pour empêcher que le constructeur ne soit exécuté à nouveau pendant que le programme est en cours d’exécution ;
Ou peut-être que c’est plus facile à comprendre, et en plus le final ne s’initialisera qu’une seule fois au début du programme.
|
Publié sur 07/01/2019 15:37:14
|
|
|
|
