JtaTransactionManager created with the JtaTransactionManagerFactoryBean is not ready to use

[bbodnar]

A JtaTransactionManager created with the JtaTransactionManagerFactoryBean (the only way to get the proper JTA-support when using a Java-configuration, introduced in [SPR-12197]) is not ready to use, because JtaTransactionManager is an InitializingBean and InitializingBean.afterPropertiesSet() is basically not called by Spring on factory-made beans.

Workarounds exist (eg. calling FactoryBean.getObject() on JtaTransactionManagerFactoryBean directly and exposing the result (the JtaTransactionManager) to the application-context/bean-factory), but that was surely not intended so by the authors. A possible solution would be to make JtaTransactionManagerFactoryBean an InitializingBean and perform the initialization of the actual transaction-manager, when Spring calls afterPropertiesSet() on the factory.

[bbodnar]

TransactionManagerFactoryBeanDemo.zip

A small demo-application attached to illustrate the problem. Attempting to use the transaction-manager fails with "org.springframework.transaction.CannotCreateTransactionException: No JTA UserTransaction available - programmatic PlatformTransactionManager.getTransaction usage not supported", because the JtaTransactionManager isn't initialized. Enabling the workaround in demo.spring.Config solves the problem (but that is no regular solution).

[sbrannen]

@bbodnar, are you actively deploying your application to WebLogic or WebSphere?

If not, there's no need to use the JtaTransactionManagerFactoryBean: you can instead simply return a new instance of JtaTransactionManager from an @Bean method.

[bbodnar]

Yes, the software this is part of is used actively - besides JBoss/Wildfly - on Websphere Classic.

[sbrannen]

@bbodnar, thanks for the feedback.

I suppose we could introduce something like a JtaTransactionManagerBuilder (for use with JavaConfig) analogous to the LocalSessionFactoryBuilder that was introduced as a companion to the LocalSessionFactoryBean for Hibernate.

Let's see what the rest of the team thinks.

[snicoll]

Would that new high-level type have any other feature than initializing the transaction manager? I'd introduce such a type only if we use the opportunity to add additional features.

[sbrannen]

Would that new high-level type have any other feature than initializing the transaction manager?

No, I don't think it would introduce any new features, and consequently it would not really be a "builder" but rather simply a "factory" (e.g., JtaTransactionManagerFactory).

I'd introduce such a type only if we use the opportunity to add additional features.

Understood.

A possible solution would be to make JtaTransactionManagerFactoryBean an InitializingBean and perform the initialization of the actual transaction-manager, when Spring calls afterPropertiesSet() on the factory.

So what about @bbodnar's above proposal?

Workarounds exist (eg. calling FactoryBean.getObject() on JtaTransactionManagerFactoryBean directly and exposing the result (the JtaTransactionManager) to the application-context/bean-factory), but that was surely not intended so by the authors.

@jhoeller, since you're listed as the sole author of JtaTransactionManagerFactoryBean, what's your position on the matter?

[bbodnar]

A note to my proposal: in Spring's sources there are already few cases, where afterPropertiesSet() on beans implementing InitializingBean is called manually (i.e. not by the bean-factory):

- spring-context-5.1.5.RELEASE.jar!/org/springframework/cache/interceptor/CacheProxyFactoryBean#createMainInterceptor()
- spring-context-5.1.5.RELEASE.jar!/org/springframework/context/annotation/MBeanExportConfiguration#WEBSPHERE#getMBeanServer()
- spring-context-5.1.5.RELEASE.jar!/org/springframework/jndi/JndiObjectFactoryBean#JndiObjectProxyFactory#createJndiObjectProxy()
- spring-tx-5.1.5.RELEASE.jar!/org/springframework/transaction/interceptor/TransactionProxyFactoryBean#createMainInterceptor()

I think, this would be also here the most straightforward solution.

[jhoeller]

Indeed, letting JtaTransactionManagerFactoryBean implement InitializingBean, propagating it to the JtaTransactionManager instance, would indeed work. There's a potential conflict with existing workarounds where calling code triggers JtaTransactionManager.afterPropertiesSet (e.g. manually or through exposing getObject() from an @Bean method) since afterPropertiesSet is only to be called once but that's acceptable for 5.2 at least.

[bbodnar]

@jhoeller: thank you for the fix!