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.
Comment From: 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.
Comment From: 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.