Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AutowiredAnnotationBeanPostProcessor should ignore bridge methods when looking for annotations [SPR-8434] #13080

Closed
spring-projects-issues opened this issue Jun 10, 2011 · 1 comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: duplicate A duplicate of another issue

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 10, 2011

Stefan Gybas opened SPR-8434 and commented

We are migrating a project from Java 5 to Java 6 and noticed that one integration test was failing because a dependency was not injected any longer.

The problem can be reproduced with a simple scenario: We have a package-visible base class for some services with an autowired dependency and a public getter and setter:

abstract class AbstractService {

    private Dependency dependency;

    public Dependency getDependency() {
        return dependency;
    }

    @Autowired
    public void setDependency(Dependency dependency) {
        this.dependency = dependency;
    }
}

Then he have a public sub class that gets component-scanned:

@Component
public class Service extends AbstractService {
}

Our test basically looks like this:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "/applicationContext.xml" })
public class DependencyInjectionTest {

    @Autowired
    private Service underTest;

    @Test
    public void testDependencyInjected() {
        // this test passes when Service.java was compiled with Java 5
        // but fails when compiled with Java 6
        assertNotNull(underTest.getDependency());
    }
}

with a very simple application context that just enables annotation-config and does a package scan (see the attachment for a complete Maven/Eclipse project).

When we compile the project with Java 5 the test passes when run with Java 5 or Java 6. But when we compile the project with Java 6 ("-source 1.5 -target 1.5") the test fails both under Java 5 and Java 6.

After investigating the byte code in Service.class we noticed that two bridge methods are generated by the Java 6 compiler. These methods are not generated by the Java 5 compiler:

public com.example.Dependency com.example.Service.getDependency() (bridge: true)
public void com.example.Service.setDependency(com.example.Dependency) (bridge: true)

AutowiredAnnotationBeanPostProcessor.buildAutowiringMetadata(Class clazz) uses ClassUtils.getMostSpecificMethod() in line 346 (current SVN) to determine if the method is defined in the class that is investigated (AbstractService in the example). The most specific method is the bridge method in Service.class when compiled with Java 6 but this method does not have the @Autowired annotation so the setter is never called.

A fix would be to replace ClassUtils.getMostSpecificMethod() with AopUtils.getMostSpecificMethod() to get the same results on Java 5 and Java 6. But this would cause a circular dependency between spring-aop and spring-beans and is probably not a high-performance solution.

We will change the visibility of AbstractService to public in our project to work around the problem. But I suggest to change Spring to deliver the same results on Java 5 and Java 6.


Affects: 3.0.5, 3.1 M2

Attachments:

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jun 10, 2011

Stefan Gybas commented

This is the same as #12555. Sorry, I did not find this issue in my first search.

@spring-projects-issues spring-projects-issues added type: bug A general bug in: core Issues in core modules (aop, beans, core, context, expression) status: duplicate A duplicate of another issue labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: bug A general bug label Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

1 participant