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

Bridged method detection leads to false positive detection of autowired annotations [SPR-8660] #13302

Closed
spring-projects-issues opened this issue Aug 31, 2011 · 4 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Aug 31, 2011

Loïc Frering opened SPR-8660 and commented

Due to changeset 4600 in AutowiredAnnotationBeanProcessor, autowired annotations are found on overrided parameterized methods where there are no @Autowired annotations!

Exemple :

public abstract class GenericServiceImpl<T, ID extends Serializable, D extends GenericDao<T, ID>> implements GenericService<T, ID> {

    protected D dao;

    public void setDao(D resourceDao) {
        this.dao = resourceDao;
    }

    // ...
}
@Service("userService")
public class UserServiceImpl extends GenericServiceImpl<User, Integer, UserDao> implements UserService {

    @Inject
    @Named("userDao")
    @Override
    public void setDao(UserDao userDao) {
        super.setDao(userDao);
    }

    // ...
}

When processing the userService bean, the findAutowiredAnnotation method in AutowiredAnnotationBeanPostProcessor finds not only the @Autowired annotation for the setDao method defined in UserServiceImpl but also for the one defined in the parent class. This because the BridgeMethodResolver.findBridgedMethod detects the child method as the bridged method of the parent one:

private Annotation findAutowiredAnnotation(AccessibleObject ao) {
    for (Class<? extends Annotation> type : this.autowiredAnnotationTypes) {
        if (ao instanceof Method) {
            ao = BridgeMethodResolver.findBridgedMethod((Method) ao);
        }
        Annotation annotation = ao.getAnnotation(type);
        if (annotation != null) {
            return annotation;
        }
    }
    return null;
}

This leads to an autowire by type for the parameterized parent setDao method which fail because there are many implementations available and @Named is not detected in the reflected method, the right one!

I think that there is a fix to do in BridgeMethodResolver to be more specific and avoid wrong bridged method detections.

By the way I think that this issue might affect SpringData which uses a lot Java generics...


Affects: 3.0.6, 3.1 M2

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

Thanks Loïc, this is resolved against RC1 now.

commit 6579b10a2494f20c45e1c957bae2b8da655224d7
Author: Chris Beams <cbeams@vmware.com>
Date:   Mon Oct 10 05:40:21 2011 +0000

    Distinguish between different bridge method types
    
    Add BridgeMethodResolver#isJava6VisibilityBridgeMethodPair to
    distinguish between (a) bridge methods introduced in Java 6 to
    compensate for inheriting public methods from non-public superclasses
    and (b) bridge methods that have existed since Java 5 to accommodate
    return type covariance and generic parameters.
    
    In the former case, annotations should be looked up from the original
    bridged method (SPR-7900).  In the latter, the annotation should be
    looked up against the bridge method itself (SPR-8660).
    
    As noted in the Javadoc for the new method, see
    http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html
    for a useful description of the various types of bridge methods, as
    well as http://bugs.sun.com/view_bug.do?bug_id=6342411, the bug fixed in
    Java 6 resulting in the introduction of 'visibility bridge methods'.
    
    Issue: SPR-8660, SPR-7900

@spring-projects-issues
Copy link
Collaborator Author

Loïc Frering commented

Hello Chris, glad to see this issue resolved: thanks a lot!

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

No problem. It would be great if you could give this fix a try in the latest 3.1 snapshot. We'll be rolling RC1 in the next day or so, which means there's a short window for feedback.

Cheers!

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Backported to 3.0.7, for release in late December.

Juergen

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) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

1 participant