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