IntelliJ IDEA mostra erros ao usar a anotação @Autowired do Spring

O IntelliJ IDEA mostra erros quando uso a @Autowiredanotação do Spring na classe, mas a classe está funcionando sem problemas.

Aqui está esta mensagem de erro:

Membros autowired devem ser definidos no spring bean válido (@ Component / @ Service, etc.) Less ... (Ctrl + F1) Verifica problemas de autowiring em uma classe de bean.

Tive o mesmo problema com o IntelliJ IDEA 13.1.4. Resolvi removendo a faceta Spring (Arquivo-> Estrutura do Projeto) e deixando apenas mostrar "Detecção".

Se você sabe que o bean existe e é apenas um problema das inspeções, basta adicionar o seguinte antes da declaração da variável:

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

Às vezes, o IntelliJ não pode resolver se um bean foi declarado, por exemplo, quando o bean é incluído condicionalmente e a resolução da condição ocorre no tempo de execução.

Corrigi-o adicionando o aviso supress:

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

Tenho o mesmo erro aqui!

Parece que o Intellij não pode verificar se a implementação da classe é um @Service ou @Component.

Resolva apenas mudando de Erro para Aviso (pressionando Alt + Enter).

Remova o arquivo .iml de todo o módulo do seu projeto e, em seguida, vá para Arquivo -> Invalidar Caches / Reiniciar

Arquivo -> Estrutura do Projeto -> Módulos -> + (na coluna central) -> Primavera -> OK

Eu tive o mesmo problema. Resolvi isso adicionando a faceta Spring (Arquivo-> Estrutura do Projeto) para cada módulo relevante e, em seguida, adicionando os arquivos de configuração. Para alguns projetos (spring mvc), os arquivos de configuração foram detectados automaticamente. No entanto, para um projeto jar, tive que adicionar os arquivos de configuração manualmente.

Certifique-se de ter suas definições de bean Spring corretas. Às vezes, o aplicativo funciona bem, ele apenas exibe um erro no IDE, verifique o arquivo 'iml' do seu projeto se você tiver uma faceta Spring definida.

Resolvido o problema acessando Arquivo >> Estrutura do Projeto >> Facetas e, em seguida, adicionando todos os arquivos de configuração ao Spring Facet. Depois disso, ele começou a detectar arquivos nos quais os beans residiam e foi capaz de resolver o problema. Essa verificação é muito valiosa pelo IntelliJ e o IMHO não deve ser desativado.

Parece que é o problema de visibilidade - o controlador pai não vê o componente que você está tentando conectar.

Tente adicionar

@ComponentScan("path to respective Component") 

para o controlador pai.

Certifique-se de que seu IntelliJ Idea (IDE) está ciente de todas as configurações de mola necessárias em relação às quais seu módulo está sendo inspecionado.

Você pode verificar isso em

Arquivo> Estrutura do projeto> Módulos> [nome do seu projeto no painel direito]> Spring

Às vezes, precisamos informar explicitamente ao IDE que a configuração do spring vem de uma dependência (um jar presente no classpath do seu projeto)

Eu tenho o mesmo problema. O meu foi porque o bean contendo a referência autowired não era um componente Spring (era um EJB), mas tinha um Interceptor SpringBeanAutowiringInterceptor permitindo o uso de autowiring. Acho que a Intellij não leva essa possibilidade em sua inspeção de Autowiring.

Eu tive esse problema também. Fazer alt+ entere, em seguida, pedir para executar novamente ou desativar a inspeção da mola na linha afetada consertou-a. Isso só parece ter se tornado um problema após a atualização 13.4.

no meu caso faltava escrever no 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>

e no arquivo de contexto do aplicativo:

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

depois de adicionar essas tags e executar o maven para reconstruir o projeto, o erro autowired no intellj desaparece e o ícone do bean aparece na margem esquerda:

O meu é para não adicionar @Repository na minha interface do CrudRepository, o tutorial que eu estava assistindo não adicionou no STS e não reclamou.

Você deve verificar se tem @Component, @Repository ou similar adicionado à classe

Resolvi isso adicionando uma faceta da 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 {

Resolvi este problema desta forma. No IntelliJ, todos os seus pacotes devem estar em um subpacote, que é o subpacote de main / java. Por exemplo, coloquei todos os meus pacotes em src / main / java / com.misisol.watchStore / e o spring pôde encontrar meus grãos depois.

Injetar Bean com @Qualifier resolveu o problema para mim.

Eu tive um problema semelhante. Resolvi desmarcando a opção "Processar beans explicitamente anotados" (veja a imagem abaixo). Esta opção é habilitada por padrão no Linux. Agora as anotações @Service e @Configurations estão visíveis. captura de tela

um pouco tarde, mas espero que ajude outra pessoa.

Certifique-se de colocar @Service na classe de implementação do serviço

@Service
public class ServiceNameImpl implements ServiceName {

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

}

Foi assim que consertei o erro.

Sei que essa é uma pergunta antiga, mas não encontrei nenhuma resposta que resolvesse esse problema para mim, então vou fornecer minha solução.

Observação: achei que o problema fosse esse , mas meu problema não estava relacionado à implementação da mesma interface duas vezes. O uso @Qualitierfez meu problema desaparecer, mas era um curativo e não uma solução adequada, então não resolvi com isso.

FUNDO

Tenho a tarefa de manter um projeto antigo que passou por diferentes versões do spring e só foi atualizado para módulos separados, então as coisas precisavam de refatoração, para dizer o mínimo. Eu tinha inicialmente obtido o problema do bean duplicado e mexer nas coisas mudou o problema entre o problema do OP e o problema do bean duplicado, embora houvesse apenas um bean; navegar para os beans duplicados sempre foi para a mesma classe.

O PROBLEMA

O problema estava presente em uma @Repositoryaula que estava @Autowiredem uma @Serviceaula que também contava com a @ComponentScananotação. Percebi que também tinha um spring application-config.xmlque estava fazendo um context:component-scanno pacote básico, que acredito ser a abordagem original nas versões mais antigas do Spring. Eu estava no processo de fazer um novo ramo, pegando partes de um ramo antigo e um ramo mais novo em um projeto de suporte que foi usado em diferentes projetos que foram desenvolvidos ao longo de vários anos e é por isso que houve tal combinação de metodologias.

SOLUÇÃO SIMPLES

Como a abordagem mais moderna de uso @ComponentScanjá estava implementada, apenas removi o application-config.xmle o problema foi resolvido.

O seguinte funcionou para mim:

1. Encontre todas as classes que implementam o serviço (interface) que está apresentando o erro.
2. Marque cada uma dessas classes com a anotação @Service, para indicá-las como classes de lógica de negócios.
3. Reconstrua o projeto.

Posso chegar um pouco atrasado, mas depois de passar horas pesquisando sobre esse assunto.

Eu descobri que na versão mais recente do IntelliJ 2020 @AutoWired é opcional e a injeção de dependência baseada no construtor é preferível.

Resolvi o problema simplesmente removendo a anotação @AutoWired da classe Service and Controller e usando injeção de dependência baseada no construtor.

Este link pode ajudar.

Happy Coding!

Tive esse problema com apenas um serviço com injeção de dependência baseada no construtor com a versão 2.0.19.2.4 do IntelliJ. Achei útil alterar o nome do serviço (shift + f6) e, em seguida, descartar as alterações do nível git.