Actualización 5: He descargado el último Spring ToolsSuite IDE basado en el último Eclipse. Cuando importo mi proyecto como proyecto de Maven, parece que Eclipse/STS usa los objetivos de Maven para construir mi proyecto. Esto significa que AspectJ finalmente funciona correctamente en Eclipse.¿Por qué el diseño en tiempo de compilación AspectJ del trabajo @Configurable de Spring?
Actualización 4: He terminado utilizando el plugin Maven + AspectJ para el tejido en tiempo de compilación, eludiendo de manera efectiva el mecanismo de Eclipse.
Actualización 3: Parece que el complemento Eclipse de AspectJ rompe la capacidad de Eclipse para publicar correctamente en Tomcat. Solo eliminando la capacidad de AspectJ en un proyecto, puedo volver a publicarlo correctamente. Muy molesto.
Actualización 2: Tengo esto ahora trabajando en Eclipse. Me resulta muy incómodo decir esto, pero no tengo idea de cómo lo conseguí trabajando desde las versiones de Eclipse o Maven. Parece ser un problema de compilación en lugar de un problema de tiempo de ejecución.
Actualización 1: Parece que he conseguido que esto funcione a través de compilaciones Maven, pero no tengo idea de cómo. Eclipse todavía no funciona. Lo único que ha cambiado en el pom.xml estaba añadiendo estos parámetros de configuración (no significativos?):
<source>1.6</source>
<complianceLevel>1.6</complianceLevel>
<verbose>true</verbose>
<showWeaveInfo>true</showWeaveInfo>
<outxml>true</outxml>
estoy realmente preocupado de que tengo una repetición de this problem, donde todo funciona de manera inconsistente. Mantendré esta pregunta actualizada mientras aprendo más.
Con respecto a Eclipse, hice algunos progresos tomando los aspectos binarios que deseo tejer - en este caso spring-aspects.jar - y copiándolo fuera de mi classpath. Luego agrego este jar externo ahora a mi Aspect Path. Después de hacer esto, Eclipse me muestra correctamente los marcadores AspectJ en mi código. Es molesto que no puedo simplemente dejar spring-aspects.jar en mi ruta de compilación de Java que es mantenida por Maven para mí a través del plug-in Maven. Sin embargo, por algún motivo, el complemento AspectJ no ve los aspectos binarios a menos que se agreguen explícitamente a la ruta Aspect Path.
Post original: @Configurable es una anotación de resorte que permite a las dependencias que se inyecta en los objetos instanciados externa a la primavera (por ejemplo, mediante Hibernate o alguna clase de fábrica).
Estaba usando esta anotación anteriormente con el tejido en tiempo de carga y en su mayoría trabajado. De vez en cuando, arrancaba y nada se inyectaba. Este problema engendró this StackOverflow question. No hubo muchas respuestas, pero la mayoría sugirió que intente tejer en tiempo de compilación debido a una mayor fiabilidad.
Instalé el plug-in AspectJ para Eclipse y Maven. Ambos producen lo que parecen ser clases compiladas correctamente. Abrí una de las clases en un editor de texto antes de la compilación de AspectJ y no encontré referencias a AspectJ. Lo abrí después de la compilación de AspectJ y las versiones generadas de Eclipse y Maven tienen una referencia a org.aspectj.weaver.MethodDeclarationLineNumber. Es por eso que supongo que está siendo compilado correctamente.El problema es que una vez desplegado, no se inyectan dependencias.
Mi Primavera applicationContext.xml no se incluyen los siguientes:
<context:spring-configured />
<context:component-scan base-package="com.myapp" />
¿El por encima de todo lo que se necesita para las clases marcadas @Configurable haber hecho DI? Durante la conversión de la carga en tiempo tejiendo a tiempo de compilación tejer, quité META-INF/aop.xml, < contexto: en tiempo de carga-tejedor /> de mi applicationContext.xml y tejedora Tomcat de primavera desde mi context.xml.
¿Cómo puedo investigar más este problema? ¿Cuáles son las posibles causas?
necesita agregar 1.6 complianceLevel> a la configuración aspectj-maven-plugin, de lo contrario termina con un error (configure.incompatibleComplianceForSource) según mensaje de error probablemente porque complianceLevel es por defecto 1.4 y difiere de la configuración de origen que es 1.6 en su caso –
después de aplicar este consejo me enfrenté con el problema de que mis pruebas no funcionan porque se invocan los aspectos aspecto y el aspecto interior no existen campos inicializados, así veo NPE – gstackoverflow