[ShakilUrRehman21]

Previously, the PulsarTransactionManager that is auto-configured when spring.pulsar.transaction.enabled is set was not customized by TransactionManagerCustomizers, unlike the transaction managers that are auto-configured for JDBC, JPA, Neo4j, R2DBC, Kafka, and Batch Mongo.

As a consequence:

• TransactionExecutionListener beans (introduced in Spring Framework 6.1) were not added to it, leaving transaction lifecycle events unobserved.
• TransactionManagerCustomizer beans were not applied to PulsarTransactionManager.
• Common transaction properties configured under spring.transaction.* (such as default-timeout and rollback-on-commit-failure via TransactionProperties) were not configured on the manager.

This commit applies TransactionManagerCustomizers if available, and adds unit tests verifying that TransactionExecutionListener beans and customizer settings are applied.

[agammann]

Could the test register a user-provided TransactionManagerCustomizer bean and assert that it changes the Pulsar manager? The new cases cover the auto-configured execution listener and default-timeout property, but the PR also promises to apply application customizers. An explicit bean case would guard that part of the contract and the ObjectProvider path. I reviewed the diff; I did not run tests locally.

[ShakilUrRehman21]

Could the test register a user-provided TransactionManagerCustomizer bean and assert that it changes the Pulsar manager? The new cases cover the auto-configured execution listener and default-timeout property, but the PR also promises to apply application customizers. An explicit bean case would guard that part of the contract and the ObjectProvider path. I reviewed the diff; I did not run tests locally.

Thanks for taking the time to review!

TransactionProperties actually implements TransactionManagerCustomizer, so the existing test transactionManagerWithCustomizersIsConfigured() already verifies that a customizer bean registered in the context is gathered and applied to PulsarTransactionManager.

This also aligns with the testing pattern used in the merged PRs for Kafka (#52524) and R2DBC (#52478).

[snicoll]

Thanks for the PR, but we already have a proposal for this, see #52592.