You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The mechanism of using a BeanPostProcessor to populate the job registry is problematic as it introduces a dependency (the JobRegistry bean) in the JobRegistryBeanPostProcessor. Having dependencies in BPPs is not recommended and might cause issues like #4519 and #4489. Here is an excerpt from the SF docs:
If you have beans wired into your BeanPostProcessor by using autowiring or @Resource (which may
fall back to autowiring), Spring might access unexpected beans when searching for type-matching
dependency candidates and, therefore, make them ineligible for auto-proxying or other kinds of
bean post-processing
It turns out this has always been problematic in Spring Batch, and only made visible after the log level change in SF #24092. This issue is to deprecate the JobRegistryBeanPostProcessor in favor of a SmartInitializingSingleton (like suggested in #4521) or another mechanism that is not prone to trigger early initializations of beans.
The text was updated successfully, but these errors were encountered:
The mechanism of using a BeanPostProcessor to populate the job registry is problematic as it introduces a dependency (the
JobRegistry
bean) in theJobRegistryBeanPostProcessor
. Having dependencies in BPPs is not recommended and might cause issues like #4519 and #4489. Here is an excerpt from the SF docs:It turns out this has always been problematic in Spring Batch, and only made visible after the log level change in SF #24092. This issue is to deprecate the
JobRegistryBeanPostProcessor
in favor of aSmartInitializingSingleton
(like suggested in #4521) or another mechanism that is not prone to trigger early initializations of beans.The text was updated successfully, but these errors were encountered: