Noodle opened SPR-9215 and commented

When use Java Configuration, aspectj weaver cannot see spring beans with @Component, @Service @Repository annotations.

Affects: 3.1 GA

Reference URL: http://forum.springsource.org/showthread.php?124055-XML-vs-Java-Config-for-aspectj-transaction

Referenced from: commits https://github.com/spring-projects/spring-framework-issues/commit/55ed933a53d007662883bf8a63c27570165507ef, https://github.com/spring-projects/spring-framework-issues/commit/8a412ec9fa1ef7de87a7ec697fc80cc56c466077

7 votes, 13 watchers

Comment From: spring-projects-issues

Noodle commented

Something really wired. If I launch XmlConfigTests.java from Eclipse environment, it pass the test. But if I use "mvn test", it failed. Is this class loader issue? Please check spring-framework-issues/SPR-9215 for test project.

Comment From: spring-projects-issues

Noodle commented

Sorry for misleading comments. XmlConfigTests passed from command line as well. It failed only if run both test cases. Guess it's because JavaConfigTests get run first, and it initialized environment already. Use following command to run XmlConfigTests only, and it pass test: mvn -Dtest=XmlConfigTests test Use following command to run JavaConfigTests only, and it failed: mvn -Dtest=JavaConfigTests test If use following command, it will run JavaConfigTests and then run XmlConfigTests, both failed: mvn test

Comment From: spring-projects-issues

Prakash Rao commented

I too am facing the same issue . I have a couple of beans loaded by @bean in an @Configuration annotated file. The aspectj weaver cannot see the beans loaded by @Configuration and hence the aspects are not woven around these beans.

i am using transaction with mode=aspectj , everything works fine except for the beans which are loaded by @configuration since they are not woven.

Any idea in which release this would be fixed or is there a workaround

Comment From: spring-projects-issues

Juergen Hoeller commented

This is indeed a limitation at this point. Note that the limitation only applies to load-time weaving; compile-time-weaved bean classes defined by Configuration classes should work fine.

Class loading for configuration classes is quite different from class loading for metadata-defined beans (such as XML bean definitions), so I'm not sure we'll be able to open them up for load-time weaving at all. Nevertheless, I'll put this issue into the 4.0 backlog, trying to reach a definitive conclusion in that timeframe - and to properly document the limitations there.

Juergen

Comment From: spring-projects-issues

Nicolas Labrot commented

If the configuration bean contains dependencies, the issue applies to their too. In this case I think it is more a bug than an improvment.

In the following example, myDependency will not be weave:

@Configuration
public class MyConfiguration {

    @Inject
    private Dependency myDependency;


    @Bean
    public Bean create(){...}

}

Comment From: spring-projects-issues

Nicolas Labrot commented

I have take some time to investigate. I'm using Tomcat with the TomcatInstrumentableClassLoader classLoader.

@Configuration uses cglib and cglib loads the classes to do is stuff with the class loader (TomcatInstrumentableClassLoader). But when cglib loads the class the weaver transformers of TomcatInstrumentableClassLoader is not set. So the class is loaded and cached (by WebappClassLoader) but not weaved.

Hope it will help

Comment From: spring-projects-issues

Nick Vaidyanathan commented

Any update on this? My team is running into this issue 1 year later, and I know Spring 4.0 GA recently dropped.

Comment From: spring-projects-issues

Seamus McMorrow commented

Nothing happening on this? It would be fantastic if this could be fixed. I just stumbled across this defect, and found the reason why LTW is not applied to java config defined beans.

We like to avoid compile time weaving, as it adds to STS project builders compile time (maven plugin bugs, etc), and makes things a little more complex. With LTW everything works pretty well, even with JRebel.

Comment From: spring-projects-issues

Justin McCartney commented

+1 on getting this fixed.

We had the same problem after moving from XML based component scanning to instantiating our beans in Java config classes. No matter how we configured the web application and Spring, the process of identifying the config classes caused the loading our own bean classes before the load time weaver had been added to the classloader.

In the end we got around the problem by creating our own ApplicationContextInitializer that basically copied the code from org.springframework.context.annotation.LoadTimeWeavingConfiguration. This ensured that the class transformer was in place before the refresh of the application context.

Comment From: ImperviousPanda

Are there any updates for this? This issue was created 9 years ago. I am disappointed that this is still a problem. It is blocking our move to java config.