EventListenerMethodProcessor resolves classes of lazy beans causing NoClassDefFoundError [SPR-13712]

[spring-projects-issues]

Fabian Schlier opened SPR-13712 and commented

After upgrading from 4.1.x to 4.2.3 we are encountering problems regarding the processing of the @EventListener annotations.

Our Spring configurations (XML) contain a whole lot of beans defined for lazy init. These bean definitions are some times pre-configurations used by other projects (and could be overriden or replaced) and sometimes stage dependent beans, where the matching implementation is selected by aliases and/or <beans profile=".."> (and a more powerful self implemented equivalent) mechanism. Within the default configuration files, it is not possible to wrap the beans with <beans profile="..."> tags. We just do not know how the environments of our customers look like. Therefor the beans need to be directly defined with the lazy flag.

With 4.2.3 the org.springframework.context.event.EventListenerMethodProcessor introspects all beans defined, including the lazy defined ones. This loads the class (which up to 4.1.x did not happen!), causing NoClassDefFoundErrors if the class could not be loaded completely. I attached a minimal example, which instantiates the org.springframework.scheduling.commonj.TimerManagerTaskScheduler refering to the commonj.timers.TimerListener, which is not available outside the application server. This breaks spring context bootstrap in unit tests as well as when running in local tomcat, etc.

Is it possible to exclude lazy beans from processing?

---

Affects: 4.2.3

Attachments:

• example-lazy.xml (439 bytes)
• TestEventlistener.java (470 bytes)

Issue Links:

• EventListener in a Request scoped bean fails context initialization [SPR-13681] #18256 EventListener in a Request scoped bean fails context initialization
• EventListenerMethodProcessor unconditionally instantiates certain beans, leading to BeanCreationException during deployment [SPR-13526] #18103 EventListenerMethodProcessor unconditionally instantiates certain beans, leading to BeanCreationException during deployment
• EventListenerMethodProcessor resolves classes (by MethodIntrospector) of lazy beans causing NoClassDefFoundError [SPR-14330] #18902 EventListenerMethodProcessor resolves classes (by MethodIntrospector) of lazy beans causing NoClassDefFoundError
• Consistent bean type checking for endpoint handlers [SPR-13725] #18298 Consistent bean type checking for endpoint handlers

[spring-projects-issues]

Stéphane Nicoll commented

It's not that easy I am afraid. Excluding them means we don't support @EventListener on lazy beans. That sounds a bit harsh.

[spring-projects-issues]

Juergen Hoeller commented

Hmm, we indeed allow lazy beans to have unloadable classes. Our event listener detection algorithm should leniently accept that they are not loadable. I'll see what we can do there.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

We're catching and logging such type resolution exceptions at debug level now, effectively ignoring such beans for event listener detection purposes.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

This is available in the latest 4.2.4.BUILD-SNAPSHOT in the meantime. Please give it a try and let me know whether it works for you...

Juergen