Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-13650

@EventListener does not work if put it at method in class that implements interface

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: 4.2.2
    • Fix Version/s: 4.2.3
    • Component/s: None
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      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.

        Issue Links

          Activity

          Hide
          juergen.hoeller Juergen Hoeller added a comment -

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

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - We're currently only looking at the proxy for @EventListener detection. There is a related issue with @JmsListener ( SPR-13576 ); I'll try to address both ASAP. Juergen
          Hide
          Nazar Vishka Nazar Vishka added a comment -

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

          Show
          Nazar Vishka Nazar Vishka added a comment - Thank you Juergen for such quick reaction. Looking forward for improvement.
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          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

          Show
          juergen.hoeller Juergen Hoeller added a comment - 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

            People

            • Assignee:
              juergen.hoeller Juergen Hoeller
              Reporter:
              Nazar Vishka Nazar Vishka
              Last updater:
              Juergen Hoeller
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 15 weeks, 5 days ago