Break cycle between TransactionManagerCustomizers and TransactionManager

[snicoll]

This looks like an issue in migrating to @AutoConfiguration as it used to be after.

I also wonder why it should run before our TransactionAutoConfiguration. This looks strange to me, especially considering that the transaction manager uses TransactionManagerCustomizers which is defined by that auto-configuration.

[wilkinsona]

I also wonder why it should run before our TransactionAutoConfiguration

I think that's because it defines a TransactionManager bean that TransactionAutoConfiguration consumes. DataSourceTransactionManagerAutoConfiguration is similarly ordered for, I assume, the same reason.

especially considering that the transaction manager uses TransactionManagerCustomizers

DataSourceTransactionManagerAutoConfiguration has the same problem, as does HibernateJpaAutoConfiguration by the looks of things.

[snicoll]

We discussed this one and we analyzed the ability that TransactionManagerCustomizers stops being a bean but rather a helper that any auto-configuration can create via a simple constructor that takes ObjectProvider<PlatformTransactionManagerCustomizer>. Doing so means we no longer rely on the bean that's created by TransactionAutoConfiguration. Unfortunately, that doesn't fix the problem as a customizer implementation is provided by TransactionAutoConfiguration.

Given that auto-configurations that provide a PlatformTransactionManager must run before TransactionAutoConfiguration, I am now wondering if we shouldn't flip the problem and require that those configuration provide a bean of a certain type that can create the transaction manager, rather than the transaction manager itself. This would have the advantage of. centralizing the customization as well as the bean name. I am going to try to implement this to see if that fixes this problem.