IntelliJ IDEA muestra errores al usar la anotación @Autowired de Spring

IntelliJ IDEA muestra errores cuando uso la @Autowiredanotación de Spring en la clase, pero la clase funciona sin ningún problema.

Aquí está este mensaje de error:

Los miembros con cableado automático deben definirse en el bean de primavera válido (@ Componente / @ Servicio, etc.) menos ... (Ctrl + F1) Comprueba los problemas de cableado automático en una clase de bean.

Tuve el mismo problema con IntelliJ IDEA 13.1.4. Lo resolví eliminando la faceta Spring (Archivo-> Estructura del proyecto) y dejé que solo mostrara "Detección".

Si sabe que el bean existe y es solo un problema de las inspecciones, simplemente agregue lo siguiente antes de la declaración de la variable:

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

A veces, IntelliJ no puede resolver si se ha declarado un bean, por ejemplo, cuando el bean se incluye condicionalmente y la resolución de la condición ocurre en tiempo de ejecución.

Lo arreglé agregando la advertencia de supresión:

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

¡Tengo el mismo error aquí!

Parece que Intellij no puede verificar si la implementación de la clase es @Service o @Component.

Resuélvalo simplemente cambiando de Error a Advertencia (presionando Alt + Enter).

Elimine el archivo .iml de todo el módulo de su proyecto y luego vaya a Archivo -> Invalidar cachés / Reiniciar

Archivo -> Estructura del proyecto -> Módulos -> + (en la columna central) -> Primavera -> Aceptar

Yo tuve el mismo problema. Lo resolví agregando la faceta Spring (Archivo-> Estructura del proyecto) para cada módulo relevante, y luego agregué los archivos de configuración. Para algunos proyectos (spring mvc), los archivos de configuración se detectaron automáticamente. Sin embargo, para un proyecto jar, tuve que agregar los archivos de configuración manualmente.

Asegúrese de que sus definiciones de frijoles Spring sean correctas. A veces, la aplicación funciona bien, solo muestra un error en el IDE, verifique el archivo 'iml' de su proyecto si tiene definida una faceta de Spring.

Resolvió el problema yendo a Archivo >> Estructura del proyecto >> Facetas y luego agregando todos los archivos de configuración a Spring Facet. Después de eso, comenzó a detectar archivos en los que residen los beans y pudo solucionar el problema. IntelliJ dando este cheque es bastante valioso y en mi humilde opinión no debería deshabilitarse.

Parece que el problema de la visibilidad es que el controlador principal no ve el componente que está intentando conectar.

Intenta agregar

@ComponentScan("path to respective Component") 

al controlador principal.

Asegúrese de que su IntelliJ Idea (IDE) conozca todas las configuraciones de resorte necesarias contra las que se está inspeccionando su módulo.

Puedes comprobar esto en

Archivo> Estructura del proyecto> Módulos> [nombre de su proyecto en el panel derecho]> Spring

A veces, necesitamos decirle explícitamente al IDE que la configuración de primavera proviene de una dependencia (un jar presente en la ruta de clase de su proyecto)

Tengo el mismo problema. El mío fue porque el bean que contenía la referencia autowired no era un componente Spring (era un EJB), pero obtuvo un SpringBeanAutowiringInterceptor Interceptor que permitía el uso de autowiring. Creo que Intellij no toma esta posibilidad en su inspección de Autowiring.

Yo tuve este problema también. Haciendo alt+ entery luego pidiendo volver a ejecutar o deshabilitar la inspección de Spring en la línea afectada lo solucionó. Esto solo parece haberse convertido en un problema después de la actualización 13.4.

en mi caso me faltaba escribir en 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>

y en el archivo de contexto de la aplicación:

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

después de agregar estas etiquetas y ejecutar maven para reconstruir el proyecto, el error autowired en intellj desaparece y el icono de frijol aparece en el margen izquierdo:

El mío es por no agregar @Repository en mi interfaz CrudRepository, el tutorial que estaba viendo no lo agregó en STS y no se quejó.

Debe verificar si tiene @Component, @Repository o similar agregado en la clase

Resolví eso agregando una faceta 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 {

He resuelto este problema de esta manera. En IntelliJ, todos sus paquetes deben estar en un subpaquete que es el subpaquete de main / java. Por ejemplo, puse todos mis paquetes en src / main / java / com.misisol.watchStore / y Spring pudo encontrar mis beans luego.

Inject Bean with @Qualifier resolvió el problema por mí.

Tuve un problema similar. Lo resolví desmarcando la opción "Procesar frijoles anotados explícitamente" (ver captura de pantalla a continuación). Esta opción está habilitada de forma predeterminada en Linux. Ahora las anotaciones @Service y @Configurations son visibles. captura de pantalla

un poco tarde pero espero que ayude a alguien más.

Asegúrese de poner @Service en la clase de implementación para el servicio

@Service
public class ServiceNameImpl implements ServiceName {

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

}

Así es como solucioné el error.

Sé que esta es una pregunta antigua, pero no he encontrado ninguna respuesta que me haya resuelto este problema, así que daré mi solución.

Nota: pensé que el problema podría haber sido este , pero mi problema no estaba relacionado con la implementación de la misma interfaz dos veces. El uso @Qualitierhizo que mi problema desapareciera, pero era un vendaje y no una solución adecuada, así que no me conformé con eso.

ANTECEDENTES

Tengo la tarea de mantener un proyecto antiguo que ha pasado por diferentes versiones de Spring y solo se actualizó para módulos separados, por lo que las cosas necesitaban refactorización, por decir lo menos. Inicialmente obtuve el problema de los frijoles duplicados y jugar con las cosas cambiaba el problema de un lado a otro entre el problema de OP y el problema del frijol duplicado a pesar de que solo había un frijol; la navegación a los beans duplicados siempre fue a la misma clase.

LA CUESTIÓN

El problema estaba presente en una @Repositoryclase que estaba @Autowireden una @Serviceclase que también tenía la @ComponentScananotación. Noté que también tenía un resorte application-config.xmlque estaba haciendo un context:component-scanen el paquete base, que creo que era el enfoque original en versiones anteriores de Spring. Estaba en el proceso de hacer una nueva sucursal al tomar partes de una sucursal vieja y una sucursal más nueva en un proyecto de apoyo que se usó en diferentes proyectos que se desarrollaron durante varios años y es por eso que hubo tal combinación de metodologías.

SOLUCIÓN SIMPLE

Como @ComponentScanya se implementó el enfoque más moderno de uso , simplemente eliminé el application-config.xmly el problema se resolvió.

Lo siguiente funcionó para mí:

1. Busque todas las clases que implementan el servicio (interfaz) que está dando el error.
2. Marque cada una de esas clases con la anotación @Service, para indicarlas como clases de lógica empresarial.
3. Reconstruye el proyecto.

Puede que llegue un poco tarde, pero después de pasar horas investigando sobre este tema.

Descubrí que en la última versión IntelliJ 2020 @AutoWired es opcional y es preferible la inyección de dependencia basada en el constructor.

Resolví el problema simplemente eliminando la anotación @AutoWired de la clase de servicio y controlador y usando la inyección de dependencia basada en constructor.

Este enlace puede ayudar.

¡Feliz codificación!

Tuve este problema con solo un servicio con inyección de dependencia basada en constructor con la versión 2019.2.4 de IntelliJ. Encontré útil cambiar el nombre del servicio (shift + f6) y luego descartar los cambios del nivel de git.