Fix syntax highlighting

asciidoc/community_features/con_mg_changes-in-vertx-cassandra-client.adoc

@@ -11,6 +11,7 @@ In {VertX} {v4}, the Cassandra client uses Datastax Java driver with version 4.x
 
 The following example shows Datastax Java driver classes and create statements in {VertX} {v3x} releases.
 
+[source,java]
 ----
 import com.datastax.driver.core.ResultSet;
 import com.datastax.driver.core.Row;
@@ -28,6 +29,7 @@ cassandraClient.execute(statement, done -> {
 
 The following example shows Datastax Java driver classes and create statements in {VertX} {v4}.
 
+[source,java]
 ----
 import com.datastax.oss.driver.api.core.cql.ResultSet;
 import com.datastax.oss.driver.api.core.cql.Row;
@@ -49,6 +51,7 @@ Object mappers are no longer supported because of changes in Datastax Java drive
 
 The following mapping construction is not supported in {VertX} {v4} release:
 
+[source,java]
 ----
 @Table(keyspace = "test", name = "names")
 public class MappedClass {
@@ -64,6 +67,7 @@ The `CassandraClientOptions.setPort()`, `CassandraClientOptions.getContactPoints
 
 The following example shows the use of older methods in {VertX} {v3x} releases.
 
+[source,java]
 ----
 import io.vertx.cassandra.CassandraClient;
 import io.vertx.cassandra.CassandraClientOptions;
@@ -76,6 +80,7 @@ CassandraClient client = CassandraClient.create(vertx, options);
 
 The following example shows how to use `CassandraClientOptions.addContactPoint()`method in {VertX} {v4}.
 
+[source,java]
 ----
 import io.vertx.cassandra.CassandraClient;
 import io.vertx.cassandra.CassandraClientOptions;

asciidoc/community_features/hazelcast.adoc

@@ -15,6 +15,7 @@ If you had a custom Hazelcast configuration file in your {VertX} {v3x} applicati
 
 * Add the map `__vertx.nodeInfo`.
 
+[source,xml]
 ----
 <map name="__vertx.nodeInfo">
   <backup-count>1</backup-count>

asciidoc/community_features/ignite.adoc

@@ -13,6 +13,7 @@ If the cluster manager is used without any configuration changes there is no mig
 To overide the `default-ignite.json` you can simply add `ignite.json` to your classpath. The json format supports customizing ignite options, cache options, discovery options and ssl options. For further customization you need to fall back to the old XML format.
 
 In the example below the default config is extended to activate TLS for cluster communication.
+
 [source,json]
 ----
 {

asciidoc/community_features/kotlin.adoc

@@ -5,18 +5,20 @@
 Vert.x 3 generates extension suspending extension methods, e.g `get(Handler<AsyncResult<Result>>`
 generates `getAwait()` extension method.
 
-```kotlin
+[source,kotlin]
+----
 // getSomethingAwait() is a generated extension method
 // and is deprecated
 var result = getSomethingAwait();
-```
+----
 
 Vert.x 4 provides a future based model and the Vert.x `Future` has an `await()` extension methods
 that does the same. The code above can simply be rewritten as
 
-```kotlin
+[source,kotlin]
+----
 var result = getSomething().await();
-```
+----
 
 == Script compiler
 

asciidoc/community_features/rabbitmq-client.adoc

@@ -5,7 +5,8 @@
 In Vert.x 4 The RabbitMQ options inherits from NetClientOptions to leverage common connection options  including SSL.
 Two options have been removed in favor for their base class equivalent, hence they have been renamed.
 
-```java
+[source,java]
+----
 // Vert.x RabbitMQOptions  3.x:
 
 RabbitMQOptions options = new RabbitMQOptions()
@@ -17,5 +18,4 @@ RabbitMQOptions options = new RabbitMQOptions()
 RabbitMQOptions options = new RabbitMQOptions()
   .setReconnectAttempts(42)
   .setReconnectInterval(500);
-```
-
+----

asciidoc/community_features/wiremongo.adoc

@@ -4,7 +4,8 @@ The https://github.com/vert-x3/vertx-embedded-mongo-db[vertx-embedded-mongo-db]
 
 Let's assume we want to test our persistence layer's `findApples` method to make sure it creates the correct mongo query. Here's what such a test may look like with vertx-wiremongo:
 
-```java
+[source,java]
+----
 @Test
 public void testFindApples(TestContext ctx) {
 
@@ -24,6 +25,6 @@ public void testFindApples(TestContext ctx) {
     })
     .onComplete(ctx.asyncAssertSuccess());
 }
-```
+----
 
 A complete documentation can be found https://github.com/NoEnv/vertx-wiremongo[here].

asciidoc/modules/con_mg_changes-in-connection.adoc

@@ -9,6 +9,7 @@ The `NetServerOptions.isClientAuthRequired()` method has been removed. Use the `
 
 The following example shows how to use a switch statement to check if authentication of the client is required.
 
+[source,java]
 ----
 switch (options.getClientAuth()) {
 case REQUIRED:
@@ -20,6 +21,8 @@ default:
 ----
 
 The following example shows how to use the check if authentication of the client is required in {Vertx} {v4}.
+
+[source,java]
 ----
 if (options.getClientAuth() == ClientAuth.REQUIRED) {
 // behavior in releases prior to {VertX} {v4}

asciidoc/modules/con_mg_changes-in-eventbus-javascript-client.adoc

@@ -21,6 +21,7 @@ Use the following code in your build scripts to access the module.
 +
 ** JSON scripts
 +
+[source,json]
 ----
 {
   "devDependencies": {

asciidoc/modules/con_mg_changes-in-eventbus.adoc

@@ -16,11 +16,13 @@ The request-response messaging pattern should use the new `request` and `replyAn
 The following example shows the request and reply to a message in {VertX} {v3x} releases.
 
 Request::
+[source,java]
 ----
 eventBus.send("the-address", body, ar -> ...);
 ----
 
 Reply::
+[source,java]
 ----
 eventBus.consumer("the-address", message -> {
        message.reply(body, ar -> ...);
@@ -30,11 +32,13 @@ eventBus.consumer("the-address", message -> {
 The following example shows the request and reply to a message in {VertX} {v4}.
 
 Request::
+[source,java]
 ----
 eventBus.request("the-address", body, ar -> ...);
 ----
 
 Reply::
+[source,java]
 ----
 eventBus.consumer("the-address", message -> {
   message.replyAndRequest(body, ar -> ...);

asciidoc/modules/con_mg_changes-in-future.adoc

@@ -8,13 +8,16 @@ This section explains the changes in future.
 From {VertX} {v4} onward, multiple handlers are supported for a future. The `Future<T>.setHandler()` method used to set a single handler and has been removed. Use `Future<T>.onComplete()`, `Future<T>.onSuccess()`, and `Future<T>.onFailure()` methods instead to call handlers on completion, success, and failure results of an action.
 
 The following example shows how to call a handler in {VertX} {v3x} releases.
+
+[source,java]
 ----
 Future<String> fut = getSomeFuture();
 fut.setHandler(ar -> ...);
 ----
 
 The following example shows how to call the new `Future<T>.onComplete()` method in {VertX} {v4}.
 
+[source,java]
 ----
 Future<String> fut = getSomeFuture();
 fut.onComplete(ar -> ...);
@@ -31,13 +34,17 @@ In {VertX} {v4}, the `Future<T>.completer()` method has been removed. `Future<T>
 The `HttpClientRequest.connectionHandler()` method has been removed. Use `HttpClient.connectionHandler()` method instead to call connection handlers for client requests in your application.
 
 The following example shows how the `HttpClientRequest.connectionHandler()` method was used in {VertX} {v3x} releases.
+
+[source,java]
 ----
 client.request().connectionHandler(conn -> {
   // Connection related code
 }).end();
 ----
 
 The following example shows you how to use the new `HttpClient.connectionHandler()` method in {VertX} {v4}.
+
+[source,java]
 ----
 client.connectionHandler(conn -> {
   // Connection related code

asciidoc/modules/con_mg_changes-in-infinispan-cluster-manager.adoc

@@ -16,6 +16,7 @@ If you had a custom Infinispan configuration file in your {VertX} {v3x} applicat
 * Change the `__vertx.subs` cache type to replicated instead of distributed.
 * Add the replicated cache `__vertx.nodeInfo`.
 
+[source,xml]
 ----
  <cache-container default-cache="distributed-cache">
     <distributed-cache name="distributed-cache"/>

asciidoc/modules/con_mg_changes-in-verticles.adoc

@@ -8,11 +8,15 @@ This section explains the changes in the verticles.
 In earlier releases of {VertX}, `VerticleFactory.createVerticle()` method synchronously instantiated a verticle. From {VertX} {v4} onward, the method asynchronously instantiates the verticle and returns the callback `Callable<Verticle>` instead of the single verticle instance. This improvement enables the application to call this method once and invoke the returned callable multiple times for creating multiple instances.
 
 The following code shows how verticles were instantiated in {VertX} {v3x} releases.
+
+[source,java]
 ----
 Verticle createVerticle(String verticleName, ClassLoader classLoader) throws Exception;
 ----
 
 The following code shows how verticles are instantiated in {VertX} {v4}.
+
+[source,java]
 ----
 void createVerticle(String verticleName, ClassLoader classLoader, Promise<Callable<Verticle>> promise);
 ----
@@ -24,11 +28,15 @@ The `VerticleFactory` class has been simplified. The class does not require init
 If your existing applications use factories, in {VertX} {v4} you can update the code to use a callable when a promise completes or fails. The callable can be called several times.
 
 The following example shows existing factories in an {VertX} {v3x} application.
+
+[source,java]
 ----
 return new MyVerticle();
 ----
 
 The following example shows how to update existing factories to use promise in {VertX} {v4}.
+
+[source,java]
 ----
 promise.complete(() -> new MyVerticle());
 ----

asciidoc/modules/con_mg_changes-in-vertx-grpc.adoc

@@ -10,9 +10,8 @@ In {VertX} {v4}, the module `protoc-gen-grpc-java` is no longer available. This
 In previous releases, to work with gRPC, the following details were added to `pom.xml` file.
 
 [source,xml]
-
 ----
-  <!-- Vert.x 3.x -->
+<!-- Vert.x 3.x -->
 <plugin>
   <groupId>org.xolstice.maven.plugins</groupId>
   <artifactId>protobuf-maven-plugin</artifactId>
@@ -29,9 +28,8 @@ In previous releases, to work with gRPC, the following details were added to `po
 In {VertX} {v4}, a new gRPC compiler plugin is available. This plugin uses the official gRPC compiler instead of the fork. To work with the new gRPC plugin, add the following details to `pom.xml` file.
 
 [source,xml]
-
 ----
-    <!-- Vert.x 4.0 -->
+<!-- Vert.x 4.0 -->
 <plugin>
   <groupId>org.xolstice.maven.plugins</groupId>
   <artifactId>protobuf-maven-plugin</artifactId>

asciidoc/modules/con_mg_changes-in-vertx-redis-client.adoc

@@ -9,6 +9,7 @@ The deprecated term "slave" has been replaced with "replica" in Redis roles and
 
 Roles:: The following example shows you usage of `SLAVE` role in {VertX} {v3x} releases.
 
+[source,java]
 ----
 // Before (3.x)
 Redis.createClient(
@@ -22,6 +23,7 @@ Redis.createClient(
 
 The following example shows you usage of `REPLICA` role in {VertX} {v4}.
 
+[source,java]
 ----
 // After (4.0)
 Redis.createClient(
@@ -35,13 +37,15 @@ Redis.createClient(
 
 Node options:: The following example shows you usage of node type `RedisSlaves` in {VertX} {v3x} releases.
 
+[source,java]
 ----
 // Before (3.9)
 options.setUseSlaves(RedisSlaves);
 ----
 
 The following example shows you usage of node type `RedisReplicas` in {VertX} {v4}.
 
+[source,java]
 ----
 // After (4.0)
 options.setUseReplicas(RedisReplicas);

asciidoc/modules/con_mg_generic-updates-in-vertx-http.adoc

@@ -71,6 +71,7 @@ Use the new method `HttpServerRequest.toWebSocket()` instead. This new method is
 +
 The following example shows the use of synchronous method in {VertX} {v3x}.
 +
+[source,java]
 ----
 // 3.x
 server.requestHandler(req -> {
@@ -80,6 +81,7 @@ server.requestHandler(req -> {
 +
 The following example shows the use of asynchronous method in {VertX} {v4}.
 +
+[source,java]
 ----
 // 4.0
 server.requestHandler(req -> {
@@ -95,6 +97,7 @@ In {VertX} {v3x}, you could use the the HTTP client pool size to define the maxi
 
 The following example shows how WebSocket connections are set in {VertX} {v3x}.
 
+[source,java]
 ----
 // 3.x
 options.setMaxPoolSize(30); // Maximum connection is set to 30 for each endpoint
@@ -104,6 +107,7 @@ However, in {VertX} {v4}, there is no pooling of WebSocket TCP connections, beca
 
 The following example shows how to set WebSocket connections in {VertX} {v4}.
 
+[source,java]
 ----
 // 4.0
 options.setMaxWebSockets(30); // Maximum connection is set to 30 for each endpoint
@@ -149,6 +153,7 @@ switch (method.name()) {
 
 You can also use the following code in {VertX} {v4}.
 
+[source,java]
 ----
 HttpMethod PROPFIND = HttpMethod.valueOf("PROPFIND");
 
@@ -164,11 +169,15 @@ if (method == HttpMethod.GET) {
 If you are using `HttpMethod.OTHER` value in your applications, use the following code to migrate the application to {VertX} {v4}.
 
 The following example shows you the code in {VertX} {v3x} releases.
+
+[source,java]
 ----
 client.request(HttpMethod.OTHER, ...).setRawName("PROPFIND");
 ----
 
 The following example shows you the code in {VertX} {v4}.
+
+[source,java]
 ----
 client.request(HttpMethod.valueOf("PROPFIND"), ...);
 ----

asciidoc/modules/con_mg_handling_deprecations_and_removals.adoc

@@ -13,6 +13,7 @@ The Java compiler generates warnings when deprecated APIs are used. You can use
 
 The following example shows an EventBus method that was deprecated in an {VertX} {v3x} releases.
 
+[source,java]
 ----
 // Send was deprecated in Vert.x 3.x release
 vertx.eventBus().send("some-address", "hello world", ar -> {
@@ -24,6 +25,7 @@ The method `send(String,String,Handler<AsyncResult<Message>>)` has been replaced
 
 The following example shows how to update your application to use the new method.
 
+[source,java]
 ----
 // New method can be used in Vert.x 3.x and Vert.x 4.x releases
 vertx.eventBus().request("some-address", "hello world", ar -> {