Performance Degradation in getBean method after upgrade

[Srikalpana]

Hi Team,

We have a requirement where we generate java classes dynamically and register them using Spring registerBean. When we upgraded Spring framework, 4.2.3 to 4.3.18, there was a severe performance degradation while retrieving the registered bean.

To fix the issue, we are planning to use the following code instead of using getBean method. My question is: does the below API provide same initialization (like autowiring / pre & post processing capacity) or not? Will there be any repercussion with this API?

AutowireCapableBeanFactory factory = applicationContext.getAutowireCapableBeanFactory();
return ( T )factory.autowire( clazz, AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, false );

[sdeleuze]

Could be a duplicate of #22425.

[jhoeller]

Programmatically creating an autowired instance that way works in principle. However, if you want post-processors (including annotation-driven injection) to work, you should rather use the AutowireCapableBeanFactory.createBean method: simply createBean(clazz) will be sufficient, no need to pass in any autowiring constants (unless you actually want property-driven autowiring rather than annotation-driven autowiring, along the lines of the old autowire setting for an XML bean definition).

That said, any details on the performance regression in your scenario? I assume it is about getBean(Class) (which goes through a type-based resolution algorithm) rather than getBean(String) (which performs a straight map lookup by key)? Does the issue actually look like a duplicate of #22425 to you? Are you seeing the performance degradation on first retrieval or on repeated retrieval of a bean?

[Srikalpana]

Thank you for the response. Both getBean(Class) & getBean(String) methods are showing performance degradations. We badly need a work around for this issue, as it is taking more than 3 min during initialization.

[Srikalpana]

AutowireCapableBeanFactory.createBean(clazz) also did not give us any benefit , it is taking > 3 min.

[sdeleuze]

@Srikalpana Could you provide us a repro project or even a private access to the project sources in order to allow us to analyze what's going on?

[jhoeller]

Closing due to the lack of reproducibility and the EOL of the 4.3.x line. To be reopened or followed up if concrete suggestions for a refinement come in.