IntelliJ IDEA affiche des erreurs lors de l'utilisation de l'annotation @Autowired de Spring

IntelliJ IDEA affiche des erreurs lorsque j'utilise l' @Autowiredannotation de Spring dans la classe, mais la classe fonctionne sans aucun problème.

Voici ce message d'erreur:

Les membres autowired doivent être définis dans le spring bean valide (@ Component / @ Service, etc.) Less ... (Ctrl + F1) Vérifie les problèmes d'autowiring dans une classe de bean.

J'ai eu le même problème avec IntelliJ IDEA 13.1.4. Je l'ai résolu en supprimant la facette Spring (File-> Project Structure) et en la laissant juste pour afficher "Detection".

Si vous savez que le bean existe et que c'est juste un problème d'inspections, ajoutez simplement ce qui suit avant la déclaration de variable:

@SuppressWarnings("SpringJavaAutowiringInspection")
@Inject MyClass myVariable;

Parfois, IntelliJ ne peut pas résoudre si un bean a été déclaré, par exemple lorsque le bean est inclus conditionnellement et que la résolution de la condition se produit au moment de l'exécution.

Je l'ai corrigé en ajoutant l'avertissement de suppression:

 @SuppressWarnings("SpringJavaInjectionPointsAutowiringInspection")
 @Autowired
 private ....

Vous avez la même erreur ici!

Il semble qu'Intellij ne puisse pas vérifier si l'implémentation de classe est un @Service ou un @Component.

Résolvez-le simplement en changeant d'erreur en avertissement (en appuyant sur Alt + Entrée).

Supprimez le fichier .iml de tout votre module de projet et ensuite allez dans Fichier -> Invalidate Caches / Restart

Fichier -> ProjectStructure -> Modules -> + (dans la colonne centrale) -> Spring -> OK

J'ai eu le même problème. Je l'ai résolu en ajoutant la facette Spring (Fichier-> Structure du projet) pour chaque module pertinent, puis en ajoutant les fichiers de configuration. Pour certains projets (spring mvc), les fichiers de configuration ont été détectés automatiquement. Cependant, pour un projet jar, j'ai dû ajouter les fichiers de configuration manuellement.

Assurez-vous que vos définitions de Spring Bean sont correctes. Parfois, l'application fonctionne correctement, elle affiche simplement une erreur dans l'EDI, vérifiez le fichier 'iml' de votre projet si vous avez défini une facette Spring.

Résolu le problème en allant dans Fichier >> Structure du projet >> Facettes, puis en ajoutant tous les fichiers de configuration à Spring Facet. Après cela, il a commencé à détecter les fichiers dans lesquels résident les beans et a pu trier le problème. IntelliJ donnant ce chèque est très précieux et IMHO ne devrait pas être désactivé.

Cela semble être le problème de visibilité - le contrôleur parent ne voit pas le composant que vous essayez de câbler.

Essayez d'ajouter

@ComponentScan("path to respective Component") 

au contrôleur parent.

Assurez-vous que votre IntelliJ Idea (IDE) est conscient de toutes les configurations de ressort nécessaires contre lesquelles votre module est inspecté.

Vous pouvez vérifier cela sous

Fichier> Structure du projet> Modules> [nom de votre projet dans le panneau de droite]> Spring

Parfois, nous devons indiquer explicitement à l'EDI que la configuration du ressort provient d'une dépendance (un fichier jar présent dans le chemin de classe de votre projet)

J'ai le même problème. Le mien était parce que le bean contenant la référence autowired n'était pas un composant Spring (c'était un EJB), mais avait un SpringBeanAutowiringInterceptor Interceptor permettant l'utilisation de l'autowiring. Je pense qu'Intellij ne prend pas cette possibilité dans son inspection Autowiring.

J'ai eu ce problème également. Faire alt+ enterpuis demander de réexécuter ou de désactiver l'inspection des ressorts sur la ligne affectée a corrigé le problème. Cela ne semble être devenu un problème qu'après la mise à jour 13.4.

dans mon cas, il me manquait d'écrire dans web.xml:

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

    <listener>
        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
    </listener>

   <context-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>classpath*:applicationContext.xml</param-value>
   </context-param>

et dans le fichier de contexte de l'application:

<context:component-scan base-package=[your package name] />

après avoir ajouté ces balises et exécuté maven pour reconstruire le projet, l'erreur autowired dans intellj disparaît et l'icône de haricot apparaît dans la marge de gauche:

Le mien est de ne pas ajouter @Repository sur mon interface CrudRepository, le tutoriel que je regardais ne l'a pas ajouté sur STS et il ne s'est pas plaint.

Vous devriez vérifier si @Component, @Repository ou similaire a été ajouté à la classe

J'ai résolu cela en ajoutant une facette Web.

eg1:
director：Settings - Editor - Inspections - Spring - Spring Core - Code - Autowiring for Bean Class 
operate:checkout 勾去掉
eg2:
1.impl class add @service
like this:
@Service
public class CityServiceImpl implements CityService{
@Autowired
private CityDao cityDao;

like this
2.dao file class add @Repository
@Repository
public interface CityDao {

J'ai résolu ce problème de cette façon. Dans IntelliJ, tous vos packages doivent être dans un sous-package qui est le sous-package de main / java. Par exemple, j'ai mis tous mes paquets sous src / main / java / com.misisol.watchStore / et spring pourrait trouver mes beans ensuite.

Inject Bean avec @Qualifier a résolu le problème pour moi.

J'ai eu un problème similaire. Je l'ai résolu en décochant l'option "Traiter les beans explicitement annotés" (voir capture d'écran ci-dessous). Cette option est activée par défaut sur Linux. Les annotations @Service et @Configurations sont désormais visibles. capture d'écran

un peu tard mais j'espère que cela aide quelqu'un d'autre.

Assurez-vous de mettre le @Service sur la classe d'implémentation du service

@Service
public class ServiceNameImpl implements ServiceName {

    @Override
    public void method(ObjectType paramName) {
        //CODE
    }

}

C'est ainsi que j'ai corrigé l'erreur.

Je sais que c'est une vieille question, mais je n'ai trouvé aucune réponse qui a résolu ce problème pour moi donc je vais fournir ma solution.

Remarque: je pensais que le problème était peut-être celui-ci , mais mon problème n'était pas lié à la mise en œuvre de la même interface deux fois. L'utilisation a @Qualitierfait disparaître mon problème, mais c'était un pansement et pas une solution appropriée, donc je ne me suis pas contenté de cela.

CONTEXTE

Je suis chargé de maintenir un ancien projet qui a traversé différentes versions de Spring et mis à jour uniquement pour des modules séparés, donc les choses devaient être refactorisées, c'est le moins qu'on puisse dire. J'avais initialement eu le problème du bean en double et le fait de bricoler les choses a changé le problème entre le problème d'OP et le problème du bean en double, même s'il n'y avait qu'un seul bean; la navigation vers les beans dupliqués allait toujours dans la même classe.

LE PROBLÈME

Le problème était présent sur une @Repositoryclasse qui était @Autowireddans une @Serviceclasse qui avait également l' @ComponentScanannotation. J'ai remarqué que j'avais aussi un ressort application-config.xmlqui faisait un context:component-scansur le paquet de base, ce qui, je crois, était l'approche originale dans les anciennes versions de Spring. J'étais en train de créer une nouvelle branche en prenant des parties d'une ancienne branche et d'une branche plus récente dans un projet de support qui a été utilisé dans différents projets qui ont été développés sur plusieurs années et c'est pourquoi il y avait un tel mix-and-match des méthodologies.

SOLUTION SIMPLE

Étant donné que l'approche plus moderne d'utilisation @ComponentScanétait déjà mise en œuvre, je viens de supprimer le application-config.xmlet le problème a été résolu.

Ce qui suit a fonctionné pour moi:

1. Trouvez toutes les classes implémentant le service (interface) qui donne l'erreur.
2. Marquez chacune de ces classes avec l'annotation @Service, pour les indiquer en tant que classes de logique métier.
3. Reconstruisez le projet.

Je suis peut-être un peu en retard, mais après avoir passé des heures à faire des recherches sur cette question.

J'ai découvert que dans la dernière version, IntelliJ 2020 @AutoWired est facultatif et que l'injection de dépendance basée sur le constructeur est préférable.

J'ai résolu le problème en supprimant simplement l' annotation @AutoWired de la classe Service et Controller et en utilisant l'injection de dépendances basée sur le constructeur.

Ce lien pourrait vous aider.

Bon codage!

J'ai eu ce problème avec un seul service avec une injection de dépendances basée sur un constructeur avec la version 2019.2.4 d'IntelliJ. J'ai trouvé utile de changer le nom du service (shift + f6), puis d'annuler les modifications du niveau git.