Fix non-root namespace bean injection timing issue (#2579)
Fixes timing issue where non-root namespace beans were created too late in the Spring lifecycle as described in 2579. This is fixed by modifying NonRootBeanPostProcessor to trigger bean creation when the root namespace template is actually ready as opposed to triggering on any bean initialization
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
B. Johnson seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.
Hey thanks for the contribution, I will make sure to review this as soon as I can. Either today or tomorrow.
Can we make sure we test the specific scenario brought up in the issue as well https://github.com/temporalio/sdk-java/issues/2579? Basically ensure we can inject a non-root bean like a non-root client, Thanks!
@Quinn-With-Two-Ns changing this to a draft actually while I think about it a bit more. ~~Further testing leads me to think there might be a need for a different bean processor rather than BeanPostProcessor (perhaps BeanFactoryPostProcessor)~~
Updated
Slight change to my original proposed fix - added shouldStartSuccessfullyWithNonRootNamespaceConfiguration for verification
@expanded-for-real I don't think shouldStartSuccessfullyWithNonRootNamespaceConfiguration really covers the case in question. I don't think this verifies that constructor or field injection would work since your just getting the beans from the application context. I think we should test those two cases explicitly
@Quinn-With-Two-Ns I was able to create a test that basically mimicked the timing issue (which became BeanAvailabilityValidator in the NonRootNamespaceBeanAvailabilityTest class) and I think it ended up being a bit more subtle than I previously thought. I believe the original BeanPostProcessor approach was running too late in the Spring lifecycle to enable @Resource injection, but I was able to resolve it by allowing @Resource beans to be registered earlier through a ImportBeanDefinitionRegistrar implementation. The existing tests all pass with only one modification to MultiNamespaceTest but this will likely require careful review.