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

@EventListener does not work if put it at method in class that implements interface [SPR-13650] #18226

Closed
spring-issuemaster opened this issue Nov 6, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Nov 6, 2015

Nazar Vishka opened SPR-13650 and commented

Simple example:

public interface Service{
      @org.springframework.context.event.EventListener
      void processEventA(EventA event);
      
      void processEventB(EventB event);
}

@Service
public class ServiceImpl implements Service{
     @Override
     public void void processEventA(EventA event){ 
          //do something 
     }

     @Override
     @org.springframework.context.event.EventListener
     public void void processEventB(EventB event){ 
          //do something 
     }

     @org.springframework.context.event.EventListener
     public void void processEventC(EventC event){ 
          //do something 
     }
}

@Service
public class EventPublisher{
       @Autowired
       ApplicationEventPublisher eventPublisher;

       public void publishEvents(){
             eventPublisher.publishEvent(new EventA());
             eventPublisher.publishEvent(new EventB());
             eventPublisher.publishEvent(new EventC());
       }
}

When I call EventPublisher.publishEvents() only one method in ServiceImpl is triggered: processEventA(EventA event). But I expected that all three methods will be triggered.


Affects: 4.2.2

Issue Links:

  • #18114 Spring incorrectly interprets a bean to be a spring eventlistener
  • #18153 Incorrect @JmsListener parameter matching when the listener is a JDK proxy
  • #18488 Scheduled method is not invoked via proxy
  • #18230 Consistent method selection for listeners and endpoint mappings
  • #18231 AbstractAutoProxyCreator.getCacheKey generate lots of String garbage

Referenced from: commits 90c9d96, d5efe4f

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 6, 2015

Juergen Hoeller commented

We're currently only looking at the proxy for @EventListener detection. There is a related issue with @JmsListener (#18153); I'll try to address both ASAP.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 6, 2015

Nazar Vishka commented

Thank you Juergen for such quick reaction. Looking forward for improvement.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 9, 2015

Juergen Hoeller commented

This was not as straightforward as with @JmsListener and co, since EventListenerMethodProcessor introspects top-level beans by type and carefully avoids early initialization of those beans on startup, therefore not being able to take the actual AOP proxy (and its target class) into account. Instead, we're checking a new bean definition attribute now which stores the original target class for auto-proxied beans. This new attribute is being exposed by AbstractAutoProxyCreator and AbstractBeanFactoryAwareAdvisingPostProcessor through the common AutoProxyUtils delegate, like we do fo the preserve-target-class hint already. That hint is also take into account by AbstractBeanFactoryAwareAdvisingPostProcessor (previously just by AbstractAutoProxyCreator), which means that AsyncAnnotationBeanPostProcessor and co also participate in an enforced target-class proxy scenario for specific beans now.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.