Migrate to Asciidoctor Tabs

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc

@@ -15,8 +15,11 @@ The ease-of-use afforded by the use of the `@Transactional` annotation is best
 illustrated with an example, which is explained in the text that follows.
 Consider the following class definition:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// the service class that we want to make transactional
 	@Transactional
@@ -43,8 +46,10 @@ Consider the following class definition:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// the service class that we want to make transactional
 	@Transactional
@@ -67,6 +72,7 @@ Consider the following class definition:
 		}
 	}
 ----
+======
 
 Used at the class level as above, the annotation indicates a default for all methods of
 the declaring class (as well as its subclasses). Alternatively, each method can be
@@ -128,8 +134,11 @@ preceding example.
 Reactive transactional methods use reactive return types in contrast to imperative
 programming arrangements as the following listing shows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// the reactive service class that we want to make transactional
 	@Transactional
@@ -156,8 +165,10 @@ programming arrangements as the following listing shows:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// the reactive service class that we want to make transactional
 	@Transactional
@@ -180,6 +191,7 @@ programming arrangements as the following listing shows:
 		}
 	}
 ----
+======
 
 Note that there are special considerations for the returned `Publisher` with regards to
 Reactive Streams cancellation signals. See the xref:data-access/transaction/programmatic.adoc#tx-prog-operator-cancel[Cancel Signals] section under
@@ -322,8 +334,11 @@ annotated at the class level with the settings for a read-only transaction, but
 `@Transactional` annotation on the `updateFoo(Foo)` method in the same class takes
 precedence over the transactional settings defined at the class level.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Transactional(readOnly = true)
 	public class DefaultFooService implements FooService {
@@ -339,8 +354,10 @@ precedence over the transactional settings defined at the class level.
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim",role="secondary"]
-.Kotlin
 ----
 	@Transactional(readOnly = true)
 	class DefaultFooService : FooService {
@@ -356,6 +373,7 @@ precedence over the transactional settings defined at the class level.
 		}
 	}
 ----
+======
 
 
 [[transaction-declarative-attransactional-settings]]
@@ -455,8 +473,11 @@ of the transaction manager bean. For example, using the qualifier notation, you
 combine the following Java code with the following transaction manager bean declarations
 in the application context:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public class TransactionalService {
 
@@ -470,8 +491,10 @@ in the application context:
 		public Mono<Void> doSomethingReactive() { ... }
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim",role="secondary"]
-.Kotlin
 ----
 	class TransactionalService {
 
@@ -491,6 +514,7 @@ in the application context:
 		}
 	}
 ----
+======
 
 The following listing shows the bean declarations:
 
@@ -527,8 +551,11 @@ methods, xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[Spring's
 define custom composed annotations for your specific use cases. For example, consider the
 following annotation definitions:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Target({ElementType.METHOD, ElementType.TYPE})
 	@Retention(RetentionPolicy.RUNTIME)
@@ -542,8 +569,10 @@ following annotation definitions:
 	public @interface AccountTx {
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim",role="secondary"]
-.Kotlin
 ----
 	@Target(AnnotationTarget.FUNCTION, AnnotationTarget.TYPE)
 	@Retention(AnnotationRetention.RUNTIME)
@@ -555,11 +584,15 @@ following annotation definitions:
 	@Transactional(transactionManager = "account", label = ["retryable"])
 	annotation class AccountTx
 ----
+======
 
 The preceding annotations let us write the example from the previous section as follows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public class TransactionalService {
 
@@ -574,8 +607,10 @@ The preceding annotations let us write the example from the previous section as
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim",role="secondary"]
-.Kotlin
 ----
 	class TransactionalService {
 
@@ -590,6 +625,7 @@ The preceding annotations let us write the example from the previous section as
 		}
 	}
 ----
+======
 
 In the preceding example, we used the syntax to define the transaction manager qualifier
 and transactional labels, but we could also have included propagation behavior,

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/applying-more-than-just-tx-advice.adoc

@@ -18,8 +18,11 @@ configuration and AOP in general.
 
 The following code shows the simple profiling aspect discussed earlier:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
-.Java
 ----
 	package x.y;
 
@@ -55,8 +58,10 @@ The following code shows the simple profiling aspect discussed earlier:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim",role="secondary",chomp="-packages"]
-.Kotlin
 ----
 	package x.y
 
@@ -92,6 +97,7 @@ The following code shows the simple profiling aspect discussed earlier:
 		}
 	}
 ----
+======
 
 The ordering of advice
 is controlled through the `Ordered` interface. For full details on advice ordering, see

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/aspectj.adoc

@@ -20,8 +20,11 @@ xref:core/aop.adoc[AOP] respectively.
 The following example shows how to create a transaction manager and configure the
 `AnnotationTransactionAspect` to use it:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// construct an appropriate transaction manager
 	DataSourceTransactionManager txManager = new DataSourceTransactionManager(getDataSource());
@@ -29,8 +32,10 @@ The following example shows how to create a transaction manager and configure th
 	// configure the AnnotationTransactionAspect to use it; this must be done before executing any transactional methods
 	AnnotationTransactionAspect.aspectOf().setTransactionManager(txManager);
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// construct an appropriate transaction manager
 	val txManager = DataSourceTransactionManager(getDataSource())
@@ -38,6 +43,7 @@ The following example shows how to create a transaction manager and configure th
 	// configure the AnnotationTransactionAspect to use it; this must be done before executing any transactional methods
 	AnnotationTransactionAspect.aspectOf().transactionManager = txManager
 ----
+======
 
 NOTE: When you use this aspect, you must annotate the implementation class (or the methods
 within that class or both), not the interface (if any) that the class implements. AspectJ

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/first-example.adoc

@@ -10,8 +10,11 @@ transactions being created and then rolled back in response to the
 `UnsupportedOperationException` instance. The following listing shows the `FooService`
 interface:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
-.Java
 ----
 	// the service interface that we want to make transactional
 
@@ -29,8 +32,10 @@ interface:
 
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
-.Kotlin
 ----
 	// the service interface that we want to make transactional
 
@@ -47,11 +52,15 @@ interface:
 		fun updateFoo(foo: Foo)
 	}
 ----
+======
 
 The following example shows an implementation of the preceding interface:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
-.Java
 ----
 	package x.y.service;
 
@@ -78,8 +87,10 @@ The following example shows an implementation of the preceding interface:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
-.Kotlin
 ----
 	package x.y.service
 
@@ -102,6 +113,7 @@ The following example shows an implementation of the preceding interface:
 		}
 	}
 ----
+======
 
 Assume that the first two methods of the `FooService` interface, `getFoo(String)` and
 `getFoo(String, String)`, must run in the context of a transaction with read-only
@@ -215,8 +227,11 @@ a transaction is started, suspended, marked as read-only, and so on, depending o
 transaction configuration associated with that method. Consider the following program
 that test drives the configuration shown earlier:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public final class Boot {
 
@@ -227,8 +242,10 @@ that test drives the configuration shown earlier:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	import org.springframework.beans.factory.getBean
 
@@ -238,6 +255,7 @@ that test drives the configuration shown earlier:
 		fooService.insertFoo(Foo())
 	}
 ----
+======
 
 The output from running the preceding program should resemble the following (the Log4J
 output and the stack trace from the `UnsupportedOperationException` thrown by the
@@ -281,8 +299,11 @@ return type is reactive.
 The following listing shows a modified version of the previously used `FooService`, but
 this time the code uses reactive types:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
-.Java
 ----
 	// the reactive service interface that we want to make transactional
 
@@ -300,8 +321,10 @@ this time the code uses reactive types:
 
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
-.Kotlin
 ----
 	// the reactive service interface that we want to make transactional
 
@@ -318,11 +341,15 @@ this time the code uses reactive types:
 		fun updateFoo(foo: Foo) : Mono<Void>
 	}
 ----
+======
 
 The following example shows an implementation of the preceding interface:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary",chomp="-packages"]
-.Java
 ----
 	package x.y.service;
 
@@ -349,8 +376,10 @@ The following example shows an implementation of the preceding interface:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary",chomp="-packages"]
-.Kotlin
 ----
 	package x.y.service
 
@@ -373,6 +402,7 @@ The following example shows an implementation of the preceding interface:
 		}
 	}
 ----
+======
 
 Imperative and reactive transaction management share the same semantics for transaction
 boundary and transaction attribute definitions. The main difference between imperative

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc

@@ -26,8 +26,11 @@ automatically rolled back in case of a failure. For more information on Vavr's T
 refer to the [official Vavr documentation](https://www.vavr.io/vavr-docs/#_try).
 
 Here's an example of how to use Vavr's Try with a transactional method:
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Transactional
 	public Try<String> myTransactionalMethod() {
@@ -37,6 +40,7 @@ Here's an example of how to use Vavr's Try with a transactional method:
 		return Try.of(delegate::myDataAccessOperation);
 	}
 ----
+======
 
 Checked exceptions that are thrown from a transactional method do not result in a rollback
 in the default configuration. You can configure exactly which `Exception` types mark a
@@ -138,8 +142,11 @@ is quite invasive and tightly couples your code to the Spring Framework's transa
 infrastructure. The following example shows how to programmatically indicate a required
 rollback:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public void resolvePosition() {
 		try {
@@ -150,8 +157,10 @@ rollback:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	fun resolvePosition() {
 		try {
@@ -162,6 +171,7 @@ rollback:
 		}
 	}
 ----
+======
 
 You are strongly encouraged to use the declarative approach to rollback, if at all
 possible. Programmatic rollback is available should you absolutely need it, but its

framework-docs/modules/ROOT/pages/data-access/transaction/event.adoc

@@ -15,8 +15,11 @@ event and that we want to define a listener that should only handle that event o
 transaction in which it has been published has committed successfully. The following
 example sets up such an event listener:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Component
 	public class MyComponent {
@@ -27,8 +30,10 @@ example sets up such an event listener:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Component
 	class MyComponent {
@@ -39,6 +44,7 @@ example sets up such an event listener:
 		}
 	}
 ----
+======
 
 The `@TransactionalEventListener` annotation exposes a `phase` attribute that lets you
 customize the phase of the transaction to which the listener should be bound.

framework-docs/modules/ROOT/pages/data-access/transaction/programmatic.adoc

@@ -33,8 +33,11 @@ anonymous inner class) that contains the code that you need to run in the contex
 a transaction. You can then pass an instance of your custom `TransactionCallback` to the
 `execute(..)` method exposed on the `TransactionTemplate`. The following example shows how to do so:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public class SimpleService implements Service {
 
@@ -57,8 +60,10 @@ a transaction. You can then pass an instance of your custom `TransactionCallback
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// use constructor-injection to supply the PlatformTransactionManager
 	class SimpleService(transactionManager: PlatformTransactionManager) : Service {
@@ -72,13 +77,17 @@ a transaction. You can then pass an instance of your custom `TransactionCallback
 		}
 	}
 ----
+======
 
 
 If there is no return value, you can use the convenient `TransactionCallbackWithoutResult` class
 with an anonymous class, as follows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	transactionTemplate.execute(new TransactionCallbackWithoutResult() {
 		protected void doInTransactionWithoutResult(TransactionStatus status) {
@@ -87,8 +96,10 @@ with an anonymous class, as follows:
 		}
 	});
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	transactionTemplate.execute(object : TransactionCallbackWithoutResult() {
 		override fun doInTransactionWithoutResult(status: TransactionStatus) {
@@ -97,13 +108,17 @@ with an anonymous class, as follows:
 		}
 	})
 ----
+======
 
 
 Code within the callback can roll the transaction back by calling the
 `setRollbackOnly()` method on the supplied `TransactionStatus` object, as follows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	transactionTemplate.execute(new TransactionCallbackWithoutResult() {
 
@@ -117,8 +132,10 @@ Code within the callback can roll the transaction back by calling the
 		}
 	});
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	transactionTemplate.execute(object : TransactionCallbackWithoutResult() {
 
@@ -132,6 +149,7 @@ Code within the callback can roll the transaction back by calling the
 		}
 	})
 ----
+======
 
 [[tx-prog-template-settings]]
 === Specifying Transaction Settings
@@ -143,8 +161,11 @@ xref:data-access/transaction/declarative/txadvice-settings.adoc[default transact
 following example shows the programmatic customization of the transactional settings for
 a specific `TransactionTemplate:`
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public class SimpleService implements Service {
 
@@ -160,8 +181,10 @@ a specific `TransactionTemplate:`
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	class SimpleService(transactionManager: PlatformTransactionManager) : Service {
 
@@ -173,6 +196,7 @@ a specific `TransactionTemplate:`
 		}
 	}
 ----
+======
 
 The following example defines a `TransactionTemplate` with some custom transactional
 settings by using Spring XML configuration:
@@ -212,8 +236,11 @@ to make yourself.
 Application code that must run in a transactional context and that explicitly uses
 the `TransactionalOperator` resembles the next example:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public class SimpleService implements Service {
 
@@ -235,8 +262,10 @@ the `TransactionalOperator` resembles the next example:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// use constructor-injection to supply the ReactiveTransactionManager
 	class SimpleService(transactionManager: ReactiveTransactionManager) : Service {
@@ -250,6 +279,7 @@ the `TransactionalOperator` resembles the next example:
 		}
 	}
 ----
+======
 
 `TransactionalOperator` can be used in two ways:
 
@@ -259,8 +289,11 @@ the `TransactionalOperator` resembles the next example:
 Code within the callback can roll the transaction back by calling the `setRollbackOnly()`
 method on the supplied `ReactiveTransaction` object, as follows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	transactionalOperator.execute(new TransactionCallback<>() {
 
@@ -271,8 +304,10 @@ method on the supplied `ReactiveTransaction` object, as follows:
 		}
 	});
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	transactionalOperator.execute(object : TransactionCallback() {
 
@@ -282,6 +317,7 @@ method on the supplied `ReactiveTransaction` object, as follows:
 		}
 	})
 ----
+======
 
 [[tx-prog-operator-cancel]]
 === Cancel Signals
@@ -306,8 +342,11 @@ xref:data-access/transaction/declarative/txadvice-settings.adoc[default transact
 following example shows customization of the transactional settings for a specific
 `TransactionalOperator:`
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public class SimpleService implements Service {
 
@@ -325,8 +364,10 @@ following example shows customization of the transactional settings for a specif
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	class SimpleService(transactionManager: ReactiveTransactionManager) : Service {
 
@@ -339,6 +380,7 @@ following example shows customization of the transactional settings for a specif
 		private val transactionalOperator = TransactionalOperator(transactionManager, definition)
 	}
 ----
+======
 
 [[transaction-programmatic-tm]]
 == Using the `TransactionManager`
@@ -356,8 +398,11 @@ use to your bean through a bean reference. Then, by using the `TransactionDefini
 `TransactionStatus` objects, you can initiate transactions, roll back, and commit. The
 following example shows how to do so:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	DefaultTransactionDefinition def = new DefaultTransactionDefinition();
 	// explicitly setting the transaction name is something that can be done only programmatically
@@ -373,8 +418,10 @@ following example shows how to do so:
 	}
 	txManager.commit(status);
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	val def = DefaultTransactionDefinition()
 	// explicitly setting the transaction name is something that can be done only programmatically
@@ -391,6 +438,7 @@ following example shows how to do so:
 
 	txManager.commit(status)
 ----
+======
 
 
 [[transaction-programmatic-rtm]]
@@ -403,8 +451,11 @@ use to your bean through a bean reference. Then, by using the `TransactionDefini
 `ReactiveTransaction` objects, you can initiate transactions, roll back, and commit. The
 following example shows how to do so:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	DefaultTransactionDefinition def = new DefaultTransactionDefinition();
 	// explicitly setting the transaction name is something that can be done only programmatically
@@ -421,8 +472,10 @@ following example shows how to do so:
 				.onErrorResume(ex -> txManager.rollback(status).then(Mono.error(ex)));
 	});
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	val def = DefaultTransactionDefinition()
 	// explicitly setting the transaction name is something that can be done only programmatically
@@ -438,5 +491,6 @@ following example shows how to do so:
 				.onErrorResume { ex -> txManager.rollback(status).then(Mono.error(ex)) }
 	}
 ----
+======