BeanCurrentlyInCreationException when two DataSources used with DataSourceInitializer

[zachmarshall]

It appears that when there are two DataSource beans created and one bean factory method calls the other DataSource's bean factory method (e.g. in a delegate pattern), DataSourceInitializer triggers a circular bean reference. It doesn't help that one bean is tagged @Primary.

Apologies if I'm doing something incorrectly. I posted at Stack Overflow and did not get responses. I reviewed the doc and I believe I've followed that, and it does not mention this delegate pattern.

I've created a sample repository with two junit tests that demonstrate the issue. The full stack trace is also available there along with some analysis. In summary, the @Primary DataSource bean triggers creation of the subordinate DataSource bean which completes successfully. The creation of the subordinate bean triggers DataSourceInitializer which asks the bean factory for the DataSource and the bean factory selects the @Primary which is still in creation.

I've reviewed both open and closed issues and found several relevant issues: #2383 is similar but isn't using @Primary, #8068 seems unrelated, #7652 mentions tricks needed for a similar setup but doesn't have the same relationship between the two beans, #5541 implies this should work but again doesn't have one factory bean calling the other factory bean, #5104 suggests using @Primary which doesn't help in this case. #2784 seems to be the closest match and was closed per 9c73312. However, 9c73312 only seems to update the Rabbit and JMS configuration. Should @ConditionalOnSingleCandidate also be used for the DataSourceInitializer?

[snicoll]

Should @ConditionalOnSingleCandidate also be used for the DataSourceInitializer?

We intend to do that, yes see #6560. There could be a way to break that cycle though.

[zachmarshall]

Thanks and sorry I missed that issue in my search. I see you've asked to keep convo here and will do so.

I do agree that I would like to resolve this without requiring that approach. Why does DataSourceInitializer even exist as a bean? Why not do the actual work in DataSourceInitializerPostProcessor on either each and every DataSource or only on @Primary beans?

[snicoll]

Ironically enough, that test passes in IntelliJ IDEA.

I can see where the problem comes from now. The BPP attempts to fully initialize DataSourceInitializer as soon as it sees a DataSource. The problem in your example is that the secondary one (that's not primary) is the first one to be post-processed so it early triggers the initialization of the DataSourceInitalizer and that has the effect of requesting the primary DataSource to be resolved.

I am not sure I get why IJ does not reveal the cycle. But I think I have an idea to fix it.

[zachmarshall]

@snicoll thanks, that was my analysis as well. I did find a workaround - by using @DependsOn("dataSourceInitializer") on the @Primary bean definition, spring eagerly creates the dataSourceInitializer bean before the primary is marked as in creation. Kind of a hack but works for now.

[snicoll]

Given you have a workaround and changing things in the BPP may break other use cases, I am tempted to close this issue as a duplicate of #9528. Let see what the rest of the team think.