Переход с Vert.x 4 на 5

Это руководство описывает обновления в выпуске Eclipse Vert.x 5. Используйте эту информацию для обновления ваших приложений Vert.x 4.x до Vert.x 5. В нем представлена информация о новых, устаревших и неподдерживаемых функциях в этом выпуске.

В зависимости от модулей, используемых в вашем приложении, вы можете прочитать соответствующий раздел, чтобы узнать больше об изменениях в Vert.x 5.

О Vert.x

Vert.x — это набор инструментов, используемый для создания реактивных, неблокирующих и асинхронных приложений, работающих на виртуальной машине Java (JVM). Он содержит несколько компонентов, которые помогут вам создавать реактивные приложения. Он разработан как облачно-ориентированный.

Поскольку Vert.x поддерживает асинхронные приложения, его можно использовать для создания приложений с большим объемом сообщений, обработки больших событий, HTTP-взаимодействий и т. д.

Что изменилось в Vert.x 5

В этом разделе объясняются фундаментальные различия между выпусками Vert.x 5 и 4.x.

Обработка устареваний и удалений

Некоторые функции и возможности были устаревшими или удалены в Vert.x 5. Прежде чем переносить ваши приложения в Vert.x 5, проверьте наличие устареваний и удалений.

Некоторые API были устаревшими в выпуске Vert.x 4.x, и в этом выпуске были предоставлены новые эквивалентные API.
Устаревшие API были удалены в Vert.x 5.

Если ваше приложение использует устаревший API, вы должны обновить свое приложение, чтобы использовать новый API. Это помогает при переносе приложений на последнюю версию продукта.

Компилятор Java генерирует предупреждения при использовании устаревших API. Вы можете использовать компилятор для проверки устаревших методов при переносе приложений в Vert.x 5.

Завершение работы и удаление компонентов

Несколько компонентов завершают свою работу в версии 5, что означает, что они по-прежнему поддерживаются в течение срока службы серии 5.x, но мы не рекомендуем их больше использовать, поскольку мы предоставляем им замены. Такие компоненты планируется убрать в следующем основном выпуске (Vert.x 6).

Вот список компонентов, завершающих работу в версии 5:

Компонент	Замена
gRPC Netty	Клиент и сервер Vert.x gRPC
JDBC API	Реализация клиентского API SQL для JDBC
Service Discovery	Vert.x Service Resolver
RxJava 2	Mutiny или RxJava 3
OpenTracing	OpenTelemetry
Vert.x Unit	Vert.x JUnit 5

Компонент

Замена

gRPC Netty

Клиент и сервер Vert.x gRPC

JDBC API

Реализация клиентского API SQL для JDBC

Service Discovery

Vert.x Service Resolver

RxJava 2

Mutiny или RxJava 3

OpenTracing

OpenTelemetry

Vert.x Unit

Vert.x JUnit 5

Вот список компонентов, удаленных в версии 5, которые были завершены в серии 4.x.

Компонент	Замена
Vert.x Sync	Vert.x виртуальные потоки
Service Factories	Нет
Maven Service Factory	Нет
HTTP Service Factory	Нет
Vert.x Web OpenAPI	Vert.x Web OpenAPI Router

Компонент

Замена

Vert.x Sync

Vert.x виртуальные потоки

Service Factories

Нет

Maven Service Factory

Нет

HTTP Service Factory

Нет

Vert.x Web OpenAPI

Vert.x Web OpenAPI Router

Принятие будущей модели

Vert.x 4 расширил асинхронную модель обратного вызова 3.x до гибридной модели future/callback, чтобы упростить переход с Vert.x 3.

У каждого метода обратного вызова есть соответствующий метод future:

public interface HttpClient {

   // Future version
   Future<HttpClientRequest> request(RequestOptions request);

   // Callback version
   void request(RequestOptions request, Handler<AsyncResult<HttpClientRequest>> callback);
   ...
}

Vert.x 5 сохраняет только модель future, и, следовательно, модель обратного вызова исчезла, вместо этого вы получаете:

public interface HttpClient {

   // Future version
   Future<HttpClientRequest> request(RequestOptions request);
   ...
}

Методы обратного вызова Vert.x 4.x не являются устаревшими методами, однако после выпуска Vert.x 5 методы обратного вызова должны быть устаревшими, чтобы упростить переход на Vert.x 5.

Конструкторы Vert.x

Vert.x 5 представил использование шаблона builder, который упрощает конфигурацию компонентов с экземплярами объектов.

До 5, такая настройка обычно поддерживалась параметрами.

Настройка экземпляра Vertx в Vert.x 4.x

Future<Vertx> future = Vertx.clusteredVertx(options.setClusterManager(clusterManager));

Шаблон builder предоставляет чистую и простую альтернативу для разделения конфигурации и настройки.

Настройка экземпляра Vertx в Vert.x 5

Future<Vertx> f = Vertx
  .builder()
  .with(options)
  .withClusterManager(clusterManager)
  .buildClustered();

Этот шаблон был принят, когда это было возможно, в Vert.x 5 и будет подробно описан для каждого компонента.

Изменения в компонентах

Удаление инструмента командной строки Vert.x

Инструмент командной строки vertx был удален в Vert.x 5.

Мы хотим сосредоточиться на варианте использования типичного приложения Vert.x: скомпилированного и при необходимости упакованного в исполняемый uber-jar.

Вы можете сделать это с помощью Maven и плагина Vert.x Maven. Плагин может создать новый проект Maven в вашем репозитории или обновить существующий.

В дополнение к упаковке приложения в виде исполняемого uber-jar, он также может запускать ваше приложение в режиме разработки (повторно развертывая основной вертикс при обнаружении изменений в файлах).

Если вы пользователь Gradle, плагин Vert.x Gradle предоставляет аналогичные функции.

Устаревание фреймворка CLI

Фреймворк CLI устарел в Vert.x 5. Это включает класс io.vertx.core.Launcher, который на нём основан.

Если ваше приложение — это утилита командной строки или ей требуется такая, проверьте альтернативы, такие как Picocli. На самом деле, в различных аспектах Picocli более гибкий и мощный, чем фреймворк CLI Vert.x.

Устаревший CLI Vert.x

Если, оценивая альтернативы, вам нужно сохранить функциональность фреймворка CLI, вы можете сделать это, добавив эту зависимость в свой проект (Maven):

<dependency>
  <groupId>io.vertx</groupId>
  <artifactId>vertx-launcher-legacy-cli</artifactId>
  <version>5.0.0</version>
</dependency>

Этот новый проект содержит устаревший фреймворк CLI, включая класс io.vertx.core.Launcher.

Обратите внимание, что обратная совместимость не гарантируется на протяжении всего жизненного цикла Vert.x 5.

Запускатель приложений Vert.x

В Vert.x 5 новый модуль, Запускатель приложений Vert.x, заменяет класс io.vertx.core.Launcher Vert.x 4.x.

Сначала вы должны добавить его в зависимости вашего проекта (Maven):

<dependency>
  <groupId>io.vertx</groupId>
  <artifactId>vertx-launcher-application</artifactId>
  <version>5.0.0</version>
</dependency>

Для запуска приложения используйте io.vertx.launcher.application.VertxApplication в качестве главного класса.

# Assuming the command is executed on a Unix-like system which has the classpath configured in the CLASSPATH environment variable.
java -cp $CLASSPATH io.vertx.launcher.application.VertxApplication my.app.MainVerticle

Если ваше приложение упаковано как исполняемый JAR-файл, имея атрибут Main-Class, установленный на значение io.vertx.launcher.application.VertxApplication в файле META-INF/MANIFEST.MF, команду можно упростить.

java -jar myapp.jar my.app.MainVerticle

Запускатель приложений Vert.x 5 не поддерживает динамическую перезагрузку вертиклов при изменении файлов. Если вам нужна эта функция на стадии разработки, и ваш проект построен с помощью Maven, ознакомьтесь с Плагином Maven для Vert.x.

Ядро Vert.x

Настройка экземпляра Vert.x

Экземпляр Vertx можно настроить несколькими способами:

менеджер кластера
фабрика метрик
фабрика трассировки

В Vert.x 5 настройка достигается с помощью VertxBuilder.

Настройка с менеджером кластера

// 4.x
Future<Vertx> f = Vertx.clusteredVertx(
  new VertxOptions().setClusterManager(clusterManager)
);

// 5.0
Future<Vertx> f = Vertx
  .builder()
  .withClusterManager(clusterManager)
  .buildClustered();

Аналогично, фабрики метрик и трассировки настраиваются аналогично.

Настройка с фабриками трассировки/метрики

// 4.x
Vertx vertx = Vertx.vertx(
  new VertxOptions()
    .setMetricsOptions(new MetricsOptions().setEnabled(true).setFactory(factory))
    .setTracingOptions(new TracingOptions().setFactory(factory))
);

// 5.0
Vertx vertx = Vertx
   .builder()
  .withMetrics(factory)
  .withTracer(factory)
  .build();

Реализации трассировки Vert.x были обновлены для поддержки настройки с реализацией трассировщика для этой цели:

Настройка экземпляра с OpenTelemetry

// 4.x
Vertx vertx = Vertx.vertx(new VertxOptions()
    .setTracingOptions(
      new OpenTelemetryOptions(openTelemetry)
    )
  );

// 5.0
Vertx vertx = Vertx.builder()
 .withTracer(new OpenTelemetryTracingFactory(openTelemetry))
 .build();

Реализации метрик Vert.x были обновлены для поддержки настройки с реализацией метрик для этой цели:

Настройка экземпляра с регистром метрик Dropwizard

// 4.x
Vertx vertx = Vertx.vertx(new VertxOptions()
 .setMetricsOptions(new DropwizardMetricsOptions()
   .setMetricsRegistry(myRegistry)
   .setEnabled(true)));

// 5.0
Vertx vertx = Vertx.builder()
  .with(new VertxOptions()
    .setMetricsOptions(new DropwizardMetricsOptions()
    .setEnabled(true)))
  .withMetrics(new DropwizardMetricsFactory(myRegistry))
  .build();

Изменения, связанные с HTTP

Обработчик завершения работы соединения HTTP/2

Обработчик завершения работы соединения HTTP/2 уведомляет обработчик, когда начинается завершение работы соединения, ранее обработчик получал уведомление после закрытия всех потоков соединения. Предыдущее поведение можно получить с помощью обработчика закрытия соединения.

Это позволяет быть в курсе завершения работы соединения и принимать соответствующие меры для остановки потоков в обработке. Это также соответствует поведению других обработчиков завершения работы.

Удаление варианта завершения работы соединения HTTP без единицы времени

Вариант HttpConnection#shutdown(long) удален в пользу HttpConnection#shutdown(long, TimeUnit).

// 4.x
connection.shutdown(5 * 1000); // 5 seconds

// 5.0
connection.shutdown(5, TimeUnit.SECONDS); // 5 seconds

Удаление HTTP push ответа сервера с полномочиями строки

HttpServerResponse#push методы со строковыми полномочиями были удалены в пользу того же метода с типом HostAndPort.

// 4.x
response.push(httpMethod, authorityAsString path);

// 5.0
response.push(httpMethod, HostAndPort.parse(authorityAsString) path);

Удаление метода карты cookie запроса HTTP-сервера

Устаревший метод HttpServerRequest#cookieMap был удален, вместо этого следует использовать метод HttpServerRequest#cookies.

// 4.x
Map<String, Cookie> cookieMap = request.cookieMap();

// 5.0
Set<Cookie> cookies = request.cookies();

Использование равномерного распределителя байтов для потоков HTTP/2

Распределитель байтов потока по умолчанию использует приоритеты потоков для определения количества байтов, отправляемых для каждого потока, это изменение позволяет использовать стратегию, которая не использует приоритеты потоков и обеспечивает лучшую производительность, поскольку потребляет меньше ЦП.

Реализация по умолчанию теперь UniformStreamByteDistributor вместо WeightedFairQueueByteDistributor.

Переименование HttpClientRequest setTimeout в setIdleTimeout

Тайм-аут запроса на самом деле является тайм-аутом простоя, он был переименован, чтобы избежать путаницы.

// 4.x
request.setTimeout(timeout);

// 5.0
request.setIdleTimeout(timeout);

Удаление методов HttpClient WebSocket

HttpClient методы WebSocket перемещены в новый API WebSocketClient.

// 4.x
HttpClient httpClient = vertx.createHttpClient();
Future<WebSocket> f = httpClient.webSocket(connectOptions);

// 5.0
WebSocketClient wsClient = vertx.createWebSocketClient();
Future<WebSocket> f = wsClient.connect(connectOptions);

Настройка HTTP-клиента

HttpClient методы настройки были перемещены в новый HttpClientBuilder:

redirectHandler
connectionHandler

// 4.x
HttpClient client = vertx.createHttpClient();
client.connectionHandler(conn -> ...);
client.redirectHandler(request -> ...);

// 5.0
HttpClient client = vertx.httpClientBuilder()
  .withConnectHandler(conn -> ...)
  .withRedirectHandler(request -> ...)
  .build();

Очистка API HttpClient

В Vert.x 4.x API HttpClient предоставляет два отдельных API:

Взаимодействия HTTP, такие как метод request.
Операции HTTP-клиента, такие как updateSSLOptions

Начиная с Vert.x 5, HttpClient сохраняет только взаимодействия HTTP, новый API HttpClientAgent расширяет HttpClient и предоставляет эти методы:

// 4.x
HttpClient client = vertx.createHttpClient();
client.updateSSLOptions(sslOptions);

// 5.0
HttpClientAgent client = vertx.createHttpClient();
client.updateSSLOptions(sslOptions);

Настройка пула HttpClient

В Vert.x 4.x HttpClientOptions настраивает пул HTTP/1.x и HTTP/2.

Начиная с Vert.x 5, эта конфигурация выполняется через PoolOptions.

// 4.x
HttpClient client = vertx.createHttpClient(new HttpClientOptions()
  .setMaxPoolSize(http1MaxPoolSize)
  .setHttp2MaxPoolSize(http2MaxPoolSize)
);

// 5.0
HttpClient client = vertx.createHttpClient(new PoolOptions()
  .setHttp1MaxSize(http1MaxPoolSize)
  .setHttp2MaxSize(http2MaxPoolSize)
);

Удаление метода HttpServerResponse close

Метод HttpServerResponse close закрывает HTTP-соединение, это может ввести в заблуждение, поскольку есть лучший API для взаимодействия с текущим жизненным циклом запроса/соединения, который HttpServerResponse#reset и HttpConnection#close.

Когда необходимо закрыть фактическое HTTP-соединение:

// 4.x
response.close();

// 5.0
request.connection().close();

Когда текущий запрос/ответ должен быть удален:

// 4.x
response.close();

// 5.0
response.reset();

Асинхронные методы потока HTTP теперь возвращают future вместо fluent

Некоторые методы изменили свой тип возврата fluent на тип future, чтобы сигнализировать о результате завершения:

writeCustomFrame
writeContinue
reset

// 4.x
response.writeCustomFrame(12, 134, expectedRecv).end();

// 5.0
response.writeCustomFrame(12, 134, expectedRecv);
response.end();

Новое свойство authority, заменяющее host/port

HttpClientRequest и HttpServerRequest предоставляют полномочия запроса, используя комбинацию host/port для запроса клиента и один заголовок host для сервера. Кроме того, эта терминология также сбивает с толку с фактическим хостом и портом сервера.

Они заменены новым свойством authority:

Client request

// 4.x
request.setHost(host).setPort(port);

// 5.0
request.authority(HostAndPort.create(host, port));

Server request

// 4.x
String host = request.host(); // host:port string

// 5.0
HostAndPort authority = request.authority();

Удаление потоков HttpServer request и WebSocket

HttpServer#requestStream() и HttpServer#timeoutStream() были удалены. Эти потоки были разработаны для языков, подобных Rx, и на самом деле не приносят никакой пользы.

// 4.x
server.requestStream().handler(request -> ...);

// 5.0
server.requestHandler(request -> ...).listen();

Удаление методов рукопожатия сервера WebSocket

API WebSocket сервера может управлять рукопожатием неявно (например, отправка сообщения) или явно (принятие или любое взаимодействие WebSocket). Это приводит к более сложной реализации, чем должно быть для такого API.

Accepting a handshake

// 4.x
server.webSocketHandler(ws -> {
  ws.accept();
  ws.write();
};

// 5.0
server.webSocketHandshakeHandler(handshake -> {
  handshake.accept();
});
server.webSocketHandler(ws -> {
  ws.write();
};

Rejecting a handshake

// 4.x
server.webSocketHandler(ws -> {
  ws.reject();
};

// 5.0
server.webSocketHandshakeHandler(handshake -> {
  handshake.reject();
});

Future

Удаление типа CompositeFuture raw Future

CompositeFuture методы объявляют типы raw Future, например, all(Future,Future) or all(List<Future>>), такие объявления вынуждают пользователя приводить при использовании List<Future<Something>>. Эти методы были сделаны полностью обобщенными с использованием типа wildcard.

List<Future<User>> users = ...

// 4.x
CompositeFuture cf = CompositeFuture.all((List<Future>)users);

// 5.0
CompositeFuture cf = Future.all(users);

Удаление метода Future eventually, который принимает функцию в качестве аргумента

Future#eventually метод принимает в качестве параметра Function<Void, Future<T>>, это было разработано для codegen, который не поддерживает Supplier. Объект Future больше не генерируется кодом с Vert.x 4.x, поэтому мы можем использовать Supplier, что более уместно.

// 4.x
future.eventually(v -> someFuture());

// 5.0
future.eventually(() -> someFuture());

Logging

Использование API ведения журнала Vert.x было сокращено в Vert.x 4 для использования компонентами Vert.x, другими словами, API стал внутренним для Vert.x:

io.vertx.core.logging.Logger и io.vertx.core.logging.LoggerFactory были устарели, чтобы не допустить использования этого API. Вместо этого следует использовать API ведения журнала, такой как Log4j 2 или SLF4J.

Конечно, конфигурация внутренней части ведения журнала Vert.x остается полностью поддерживаемой, как обычно, например, свойство системы vertx.logger-delegate-factory-class-name.

Свойства системы

В Vert.x 5 было удалено несколько системных свойств.

Имя Комментарий

Имя	Комментарий
`vertx.json.base64`	JSON Vert.x 3.x поддерживает RFC-7493, однако формат кодера/декодера JSON был некорректным. Пользователи, которым необходимо взаимодействовать с приложениями Vert.x 3.x, должны были установить системное свойство `vertx.json.base64` в `legacy`.
`vertx.cluster.managerClass`	Не используется, не документирован и не протестирован.
`vertx.javaCompilerOptions`	Не используется, не документирован и не протестирован.
`vertx.flashPolicyHandler`	Сервер Vert.x HTTP/1.1 содержит скрытую опцию для обнаружения клиентов Adobe Flash и возврата ответа файла политики. Эта опция активируется системным свойством `vertx.flashPolicyHandler`, на которое есть ссылка только в исходном коде (закрытое поле) и которое не тестируется.
`vertx.cwd`	Это системное свойство не было документировано и использовалось только в репозитории `vertx-examples`.
`vertx.disableTCCL`	Вместо этого следует использовать `VertxOptions#setDisableTCCL(boolean)`.

vertx.json.base64

JSON Vert.x 3.x поддерживает RFC-7493, однако формат кодера/декодера JSON был некорректным. Пользователи, которым необходимо взаимодействовать с приложениями Vert.x 3.x, должны были установить системное свойство vertx.json.base64 в legacy.

vertx.cluster.managerClass

Не используется, не документирован и не протестирован.

vertx.javaCompilerOptions

Не используется, не документирован и не протестирован.

vertx.flashPolicyHandler

Сервер Vert.x HTTP/1.1 содержит скрытую опцию для обнаружения клиентов Adobe Flash и возврата ответа файла политики. Эта опция активируется системным свойством vertx.flashPolicyHandler, на которое есть ссылка только в исходном коде (закрытое поле) и которое не тестируется.

vertx.cwd

Это системное свойство не было документировано и использовалось только в репозитории vertx-examples.

vertx.disableTCCL

Вместо этого следует использовать VertxOptions#setDisableTCCL(boolean).

Рабочие вертиклы

Удаление свойства развертывания worker

DeploymentOptions#setWorker и DeploymentOptions#getWorker методы удалены с момента введения нового ThreadingModel.

// 4.x
Future<String> f = vertx.deployVerticle(new DeploymentOptions().setWorker(true, ...)

// 5.0
Future<String> f = vertx.deployVerticle(new DeploymentOptions().setThreadingModel(ThreadingModel.WORKER, ...)

Назначение рабочего цикла событий

С тех пор как развертывание worker Vert.x 5 использует один цикл событий для всех рабочих вертиклов вместо цикла событий на экземпляр worker.

Ранее это соответствовало развертываниям цикла событий, которые использовали цикл событий на экземпляр вертикла для целей масштабируемости.

Изменения шины событий

Удаление динамического максимального количества буферизованных сообщений потребителя сообщений

У потребителя сообщений шины событий есть динамический верхний предел для буферизованных сообщений. Вместо этого это должно быть настроено при создании потребителя:

// 4.x
eventBus.consumer(ADDRESS, msg -> ...).setMaxBufferedMessages(2000);

// 5.0
eventBus.consumer(new MessageConsumerOptions()
     .setAddress(ADDRESS)
     .setMaxBufferedMessages(2000)
   , msg -> ...);

Файловая система

Удаление рекурсивного логического значения в методе удаления файловой системы

Методы FileSystem#deleteRecursive(…) объявляет логическое значение recursive, которое практически имитирует вызов FileSystem#delete, вместо этого пользователи должны либо вызывать delete, либо deleteRecursive

// 4.x
stream.deleteRecusrive(path, false);

// 5.0
stream.delete(path);

Аналогично,

// 4.x
stream.deleteRecursive(path, true);

// 5.0
stream.deleteRecursive(path);

Разное

Удаление потоков подключения NetServer

NetServer#connectStream() было удалено. Этот поток был разработан для языков, подобных Rx, и фактически не предоставлял никаких преимуществ за счёт API.

// 4.x
server.connectStream().handler(socket -> ...);

// 5.0
server.connectHandler(socket -> ...).listen();

Изменения в NoStackTraceThrowable

`Future#fail(String msg)` fail the future with a `NoStackTraceThrowable` wrapping the error message.

Когда виртуальная нить ожидает результат задания, в случае ошибки, NoStackTraceThrowable перебрасывается, что заставляет виртуальную нить перехватывать экземпляр Throwable.

Начиная с Vert.x 5, суперкласс NoStackTraceThrowable — VertxException.

// 4.x
try {
  future.await();
} catch(Throwable t) {
  ...
}

// 5.0
try {
  future.await();
} catch(Exception t) {
  ...
}

Это оказывает влияние на использование виртуальных нитей Vert.x и Kotlin coroutines.

Удаление TimeoutStream

TimeoutStream было удалено. Этот поток был разработан для языков, подобных Rx, и фактически не предоставлял никаких преимуществ за счёт API. Вместо этого следует использовать планировщик фреймворка вместе с контекстом Vert.x.

// 4.x
vertx.periodicStream(1L).handler(timerID -> ...);

// 5.0
server.setPeriodic(1L, timerID -> ...);

Для интеграций, подобных RxJava

// 4.x
Observable<Long> timer = vertx.periodicStream(1000).toObservable();

// 5.0
Scheduler scheduler = RxHelper.scheduler(vertx);
Observable<Long> timer = Observable.interval(100, 100, TimeUnit.MILLISECONDS, scheduler);

Изменения в локальном хранилище контекста

API локального хранилища контекста устаревшего типа удалён из публичного API.

Следующие методы были перемещены в интерфейс io.vertx.core.internal.ContextInternal и могут быть удалены в любое время в Vert.x 5.

Локальное хранилище контекста очень похоже на предыдущий API:

// 4.x
context.putLocal("custom", new CustomLocal());

// 5.0
context.putLocal(CustomLocal.KEY, new CustomLocal());

Необходимо надлежащее объявление пользовательского локального хранилища:

public class CustomLocal implements VertxServiceProvider {
  public static final ContextLocal<CustomLocal> KEY = ContextLocal.registerLocal(CustomLocal.class);
  /*
    Holds some state
   */
}

Такой поставщик должен быть объявлен как поставщик услуг Java в META/INF/services/io.vertx.core.spi.VertxServiceProvider и необязательно в module-info.java.</p>

Удаление keyCertOptions key manager mapper

Метод KeyCertOptions#keyManagerMapper() был удалён в Vert.x 5. Вместо этого разработчики должны реализовать keyManagerFactoryMappermethod, предоставляющий возможность кэширования KeyManagerFactory для разработчика, управляющего жизненным циклом менеджера ключей.

Удаление методов execute blocking с обработчиком обещания

API для выполнения блокирующих действий использует шаблон с обработчиком, завершающим или отклоняющим обещание. Вместо этого это можно заменить на java.util.concurrent.Callable, возвращающим то же значение или генерирующим исключение.

// 4.x
Future<String> fut = vertx.executeBlocking(promise -> promise.complete("result"));

// 5.0
Future<String> fut = vertx.executeBlocking(() -> "result");

Методы processArgs устарели

io.vertx.core.Context#processArgs и io.vertx.core.AbstractVerticle#processArgs устарели.

Начиная с версии 5, Vert.x больше не тесно связан с CLI.

Удаление использования типов Netty

API Vert.x предоставляет доступ к API Netty в своём публичном API, позволяя взаимодействовать с ним. Поскольку Netty эволюционирует к Netty 5, мы должны удалить API Netty из публичного API Vert.x в Vert.x 5, чтобы иметь возможность изменить используемую версию Netty без проблем с версией Netty.

Такой API продолжает существовать в Vert.x 5, но перемещён во внутренний API, который не является договорным. Поэтому опытные пользователи этого API могут продолжать его использовать, при условии, что версия Vert.x 5 использует Netty 4.

// 4.x
ByteBuf bb = buff.getByteBuf();
Buffer buf = Buffer.buffer(bb);
EventLoopGroup group = vertx.nettyEventLoopGroup();

// 5.0
ByteBuf bb = ((BufferInternal)buff).getByteBuf();
buf = BufferInternal.buffer(bb);
group = ((VertxInternal)vertx).nettyEventLoopGroup();

Vert.x Auth

Обрезка AuthProvider

`io.vertx.ext.auth.AuthProvider` устарел в Vert.x 4.0 в пользу io.vertx.ext.auth.authentication.AuthenticationProvider.

// 4.x
AuthProvider authProvider = ...

// 5.0
AuthenticationProvider authProvider = ...

Vert.x для Kotlin

Удаление генерации расширяющих методов await

Vert.x 4.x для Kotlin генерирует отложенные расширяющие методы для облегчения вызова асинхронных методов Vert.x.

suspend fun HttpServer.listenAwait(port: Int, host: String): HttpServer {
   return awaitResult {
     this.listen(port, host, it)
  }
}

Такие методы устарели, так как эквивалент можно достичь, используя экземпляр Vert.x future, и удалены в Vert.x 5.

// 4.x
server.listenAwait(port, host)

// 5.0
server.listen(host, port).coAwait()

Vert.x gRPC

Удаление GrpcReadStream#collecting в пользу ReadStream#collect

// 4.x
stream.collecting(collector);

// 5.0
stream.collect(collector);

Удаление методов, объявляющих метод-описатель

Методы GrpcClient/GrpcServer, объявляющие MethodDescriptor, были удалены.

Вместо этого эти методы теперь доступны в интерфейсах GrpcIoClient/GrpcIoServer, которые расширяют интерфейсы GrpcClient/GrpcServer.

// 4.x
GrpcServer server = GrpcServer.create(vertx);

// 5.0
GrpcIoServer server = GrpcIoServer.create(vertx);
server.callHandler(methodDescriptor, request -> ...);

Vert.x Web

API контекста маршрутизации для работы с пользователем

Операции, связанные с пользователем, были перемещены в единый API контекста, доступный из RoutingContext

Выход

// 4.x
routingContext.clearUser();

// 5.0
UserContext userContext = routingContext.userContext();
userContext.logout();

Установка пользователя

Метод RoutingContext#setUser был удалён. Эту операцию следует выполнять с помощью обработчиков аутентификации.

Настройка статического обработчика

Методы StaticHandler setAllowRootFileSystemAccess и setWebRoot удалены после того, как были устаревшими в Vert.x 4.x.

Вместо этого обработчик должен быть настроен во время создания:

// 4.x
StaticHandler handler = StaticHandler.create().setAllowRootFileSystemAccess(true).setWebRoot(root);

// 5.0
StaticHandler handler = StaticHandler.create(FileSystemAccess.ROOT, root);

Распаковка движка шаблонов

Методы движка шаблонов для получения базового экземпляра движка были удалены после того, как устарели:

HandlebarsTemplateEngine#getHandlebars
ThymeleafTemplateEngine#getThymeleafTemplateEngine

Вместо этого следует использовать TemplateEngine#unwrap:

// 4.x
Handlebars handlebarsUnwrapped = handlebarsTemplateEngine.getHandlebars();
TemplateEngine thymeleafUnwrapped = thymeleafTemplateEngine.getThymeleafTemplateEngine();

// 5.0
handlebarsUnwrapped = handlebarsTemplateEngine.unwrap();
thymeleafUnwrapped = thymeleafTemplateEngine.unwrap();

CORS регулярные выражения источников

Изменены имена методов для регулярных выражений источников CORS, чтобы соответствовать остальной части фреймворка

CorsHandler#addRelativeOrigin
CorsHandler#addRelativeOrigins

Вместо этого следует использовать addOriginWithRegex или addOriginsWithRegex:

// 4.x
CorsHandler.addRelativeOrigin(".*");
CorsHandler.addRelativeOrigins(List.of(".*", "https?://.*"));

// 5.0
CorsHandler.addOriginWithRegex(".*");
CorsHandler.addOriginsWithRegex(List.of(".*", "https?://.*"));

Vert.x Web Client

Замена ожиданий ответа

Vert.x Core представляет новый API для реализации проверок ожиданий, вдохновленных функцией ожидания ответа Web Client.

HTTP клиент Vert.x поставляется с тем же набором предопределенных ожиданий, что и ожидания ответа Web Client, что еще более важно, ожидания ответа HTTP клиента могут быть повторно использованы Web Client.

Ожидания ответа HTTP используют новую операцию Future#expecting в сочетании с реализацией HttpResponseExpectation.

// 4.x
client
  .get(8080, "myserver.mycompany.com", "/some-uri")
  .expect(ResponsePredicate.SC_SUCCESS)
  .send()
  .onSuccess(res -> {
    // ....
  });

// 5.0
client
  .get(8080, "myserver.mycompany.com", "/some-uri")
  .send()
  .expecting(HttpResponseExpectation.SC_SUCCESS)
  .onSuccess(res -> {
    // ....
  });

Vert.x Web GraphQL

Обновление до GraphQL-Java 23

Vert.x Web GraphQL был обновлен с GraphQL-Java 20 до GraphQL-Java 23.

GraphQL-Java 22 и 23 являются выпусками с критическими изменениями:

Vert.x Web Validation

Замена устаревшего SchemaParser

Vert.x Web Validation основывалась на устаревшем API JSON Schema, который больше не доступен в Vert.x 5.

// 4.x
ValidationHandlerBuilder.create(schemaParser)

// 5.0
SchemaRepository schemaRepo = SchemaRepository.create(new JsonSchemaOptions().setDraft(DRAFT7));
ValidationHandlerBuilder.create(schemaRepo);

Для повышения безопасности новый SchemaRepository не загружает автоматически внешние ссылки. В случае, если ваша схема содержит внешние ссылки, вы должны предоставить и разыменовать их заранее.

Vert.x SQL Client

Client builder

Подтипы Pool не очень полезны, поскольку они не содержат никаких дополнительных методов и используются в основном для статического построения пула.

Кроме того, эти статические методы негибки и многочисленны из-за перегрузки.

Мы заменяем эти методы новым API client builder.

// 4.x
PgPool client = PgPool.pool(vertx, connectOptions, poolOptions);

//5.0
Pool client = PgBuilder.pool()
  .with(poolOptions)
  .connectingTo(connectOptions)
  .using(vertx)
  .build();

Параметры подключения

Класс SqlConnectOptions больше не наследует класс NetClientOptions.

Конфигурация TLS SqlConnectOptions по-прежнему происходит в этом классе.

// 4.x
// 5.0
PgConnectOptions options = new PgConnectOptions()
  .setPort(port)
  .setHost(host)
  .setDatabase(database)
  .setUser(user)
  .setPassword(password)
  .setSslOptions(new ClientSSLOptions()
    .setTrustOptions(new PemTrustOptions().addCertPath(pathToCert))
  );

NetClientOptions все еще можно передавать при создании клиента благодаря ClientBuilder.

// 5.0
Pool pool = PgBuilder.pool()
      .connectingTo(connectOptions)
      .with(tcpOptions)
      .build();

Обработчик подключения к пулу

Метод Pool#connectHandler перемещен в новый ClientBuilder, обработчик устанавливается один раз во время сборки, а не является изменяемым полем реализаций пула.

// 4.x
pool.connectHandler(connectHandler);

// 5.0
builder.connectHandler(connectHandler);

Поставщик соединений пула

Метод Pool#connectionProvider заменен методом создания Supplier<Future<SqlConnectOptions>>.

// 4.x
pool.connectionProvider(ctx -> futureOfSqlConnection(ctx));

// 5.0
builder.connectingTo(() -> futureOfSqlConnectOptions());

Vert.x Mongo Client

Обновление до MongoDB Java Driver 5

MongoDB Java Driver 5.x — это выпуск с критическими изменениями.

В IndexOptions, bucketSize был удален.

Кроме того, StreamFactoryFactory был заменен на TransportSettings, и Netty — единственный доступный транспорт.

Vert.x Redis Client

Удаление аргумента null в запросе

Redis не принимает значения null в запросе. Следовательно, метод Request#nullArg() закодировал null как строку "null" из 4 символов.

Этот метод, который был устаревшим в 4.x, удален. Все места, которые использовали его для кодирования значения null, теперь выдают IllegalArgumentException.

Если вы используете значения null в запросах Redis, вы должны прекратить это делать. Чтобы восстановить предыдущее поведение, вы должны вручную закодировать значения null как "null". Это относится к:

Request.arg(String)
Request.arg(Buffer)
Request.arg(JsonArray): как сам массив, так и отдельные элементы
Request.arg(JsonObject): как сам объект, так и отдельные элементы

Автоматическая пересылка подписок Redis в шину событий Vert.x

В Vert.x 4.x подписки Redis автоматически пересылались в шину событий, если только обработчик сообщений не был установлен явным образом (с использованием RedisConnection.handler()).

Это больше не так. Начиная с Vert.x 5, вы всегда должны зарегистрировать обработчик сообщений. Если вы по-прежнему хотите, чтобы сообщения подписки пересылались в шину событий, вы должны вручную создать экземпляр EventBusHandler и зарегистрировать его, используя RedisConnection.handler():

RedisConnection conn = ...;
conn.handler(EventBusHandler.create(vertx));
conn.send(Request.cmd(Command.SUBSCRIBE).arg("news"));

Кроме того, EventBusHandler пересылает не только сообщения ([p]message); он также пересылает подписки и отмены подписок ([p]subscribe и [p]unsubscribe).

RedisCluster.groupByNodes() изменил тип возврата + изменения в генерации кода

Метод RedisCluster#groupByNodes() возвращал Future<List<List<Request>>>. Из-за этого типа возврата, RedisCluster не был @VertxGen.

Это изменилось в Vert.x 5. Метод groupByNodes() теперь возвращает Future<RequestGrouping>, а весь интерфейс @VertxGen.

Кроме того, интерфейсы Request, Response и Command больше не @VertxGen — вместо этого они @DataObject. Это означает, что пользователи API, сгенерированных кодом (например, Vert.x Rx), больше не будут использовать сгенерированные оболочки; они будут использовать основные интерфейсы Vert.x Redis.

Сериализация/десериализация JSON RedisOptions

Класс RedisOptions имеет несколько методов для настройки конечных точек Redis. Эти методы по-прежнему доступны, но формат JSON этого класса изменился, включив только одно каноническое поле: endpoints.

Если вы полагаетесь на форму JSON объектов RedisOptions, обратите внимание, что члены endpoint, connectionString и connectionStrings объекта JSON больше не распознаются десериализатором и больше не генерируются сериализатором. Убедитесь, что необходимая информация присутствует в члене endpoints.

Замены addEndpoint/setEndpoint в параметрах

RedisOptions#addEndpoint и RedisOptions#setEndpoint заменены на RedisOptions#addConnectionString и RedisOptions#setConnectionString

// 4.x
options.setEndpoint(location);

// 4.x
options.setConnectionString(location);

Клиент Vert.x RabbitMQ

Библиотека клиента RabbitMQ 4.x представляла собой абстракцию высокого уровня API RabbitMQ, что, к сожалению, делало невозможным некоторые операции с RabbitMQ. Это означало, что библиотека клиента RabbitMQ 5.0 — это полная переработка с совершенно другим API.

Установление соединения

Библиотека клиента RabbitMQ 4.x использует один RabbitMQClient, который инкапсулирует соединение и канал. В библиотеке клиента 5.0 эти два компонента обрабатываются отдельно, и можно иметь несколько каналов на одно соединение.

RabbitMQChannel 5.0 имеет API, наиболее близкий к RabbitMQClient 4.x.

// 4.x
    RabbitMQOptions config = new RabbitMQOptions();
    // full amqp uri
    config.setUri("amqp://xvjvsrrc:VbuL1atClKt7zVNQha0bnnScbNvGiqgb@brokerhost/vhost");
    RabbitMQClient client = RabbitMQClient.create(vertx, config);

    // Connect
    client.start(asyncResult -> {
      if (asyncResult.succeeded()) {
        logger.info("RabbitMQ successfully connected!");
      } else {
        logger.warning("Failed to connect to RabbitMQ: {0}", asyncResult.cause().getMessage());
      }
    });

// 5.0
    RabbitMQOptions config = new RabbitMQOptions();
    config.setUri("amqp://brokerhost/vhost");
    config.setConnectionName(this.getClass().getSimpleName());
    config.setUser("guest");
    config.setPassword("guest");

    RabbitMQClient.connect(vertx, config)
            .compose(connection -> {
              RabbitMQChannelBuilder builder = connection.createChannelBuilder();
              return builder.openChannel();
            })
            .onSuccess(channel -> logger.info("Channel opened: {0}", channel.getChannelId()))
            .onFailure(ex -> logger.warning("Failed to connect to RabbitMQ: {0}", ex))
            ;

Обработчик события установления соединения

Асинхронный клиент RabbitMQ с автоматическими переподключениями должен предоставить способ создания обменов и очередей до того, как канал будет доступен для использования. В библиотеке 4.x это делается с помощью единственного connectionEstablishedCallback, добавленного к RabbitMQClient. В библиотеке 5.0 это делается с помощью channelOpenHandler, который должен быть объявлен до открытия канала.

connectionEstablishedCallback 4.x передает RabbitMQClient, в библиотеке 5.0 RabbitMQChannel еще не создан на момент вызова channelOpenHandler, поэтому он передает com.rabbitmq.client.Channel. channelOpenHandler вызывается внутри блокирующего обработчика.

// 4.x
    RabbitMQClient client = RabbitMQClient.create(vertx, config);
    client.addConnectionEstablishedCallback(promise -> {
                client.exchangeDeclare(EXCHANGE_NAME, EXCHANGE_TYPE, EXCHANGE_DURABLE, EXCHANGE_AUTO_DELETE)
                    .compose(v -> {
                      return client.queueDeclare(QUEUE_NAME, QUEUE_DURABLE, QUEUE_EXCLUSIVE, QUEUE_AUTO_DELETE);
                    })
                    .compose(declareOk -> {
                      return client.queueBind(QUEUE_NAME, EXCHANGE_NAME, "");
                    })
                    .onComplete(promise);
    });

// 5.0
    RabbitMQClient.connect(vertx, config)
            .compose(connection -> {
              return connection.createChannelBuilder()
                      .withChannelOpenHandler(chann -> {
                        chann.exchangeDeclare(EXCHANGE_NAME, EXCHANGE_TYPE, EXCHANGE_DURABLE, EXCHANGE_AUTO_DELETE, null);
                        chann.queueDeclare(QUEUE_NAME, QUEUE_DURABLE, QUEUE_EXCLUSIVE, QUEUE_AUTO_DELETE, null);
                        chann.queueBind(QUEUE_NAME, EXCHANGE_NAME, "", null);
                      })
                      .openChannel();
            })
            ;

Потребление

Объект RabbitMQChannel 5.0 предоставляет метод basicConsume, но рекомендуется использовать RabbitMQConsumer для предоставления сообщений в виде Vert.x ReadStream.

Если каждый текст сообщения может обрабатываться синхронно без блокирующих вызовов, может быть несколько сообщений в полете внутри потребителя одновременно. Важно использовать RabbitMQ QOS для ограничения количества сообщений, получаемых клиентом.

Обратите внимание на использование STRING_MESSAGE_CODEC для преобразования тела сообщения в строку перед вызовом обратного вызова.

// 4.x
    client.basicConsumer(QUEUE_NAME, rabbitMQConsumerAsyncResult -> {
      if (rabbitMQConsumerAsyncResult.succeeded()) {
        RabbitMQConsumer mqConsumer = rabbitMQConsumerAsyncResult.result();
        mqConsumer.handler(message -> {
          System.out.println("Got message: " + message.body().toString());
        });
      }
    });

// 5.0
    connection.createChannelBuilder()
            .withQos(0, 10)
            .createConsumer(RabbitMQChannelBuilder.STRING_MESSAGE_CODEC
                    , QUEUE_NAME
                    , null
                    , new RabbitMQConsumerOptions()
                    , (consumer, message) -> {
                      System.out.println("Got message: " + message.body());
                      return message.basicAck();
                    });

Публикация

RabbitMQ предоставляет два варианта для сообщений: гарантировать, что потребители получат сообщение не более одного раза, или гарантировать, что потребители получат сообщение как минимум один раз. Первый вариант является стандартным и не требует ничего, кроме вызова basicPublish, но опубликованные сообщения могут быть потеряны и не доставлены вообще.

Для обеспечения того, чтобы сообщение было получено, издатель должен дождаться подтверждения от RabbitMQ. Если это подтверждение не пришло до разрыва соединения с брокером, издатель должен повторно отправить сообщение, когда брокер вернет его.

Библиотека Vert.x RabbitMQ предоставляет RabbitMQPublisher, чтобы упростить асинхронную обработку подтверждений.

// 4.x
    Map<String, JsonObject> messages = ...
    RabbitMQPublisher publisher = RabbitMQPublisher.create(vertx, client, options);

    publisher.getConfirmationStream().handler(conf -> {
      if (conf.isSucceeded()) {
        messages.remove(conf.getMessageId());
      }
    });

    messages.forEach((k,v) -> {
      com.rabbitmq.client.BasicProperties properties = new AMQP.BasicProperties.Builder()
              .messageId(k)
              .build();
      publisher.publish(EXCHANGE_NAME, ROUTING_KEY, properties, v.toBuffer());
    });

    // Wait for messages to be empty


// 5.0
    Map<String, JsonObject> messages = ...
    RabbitMQClient.connect(vertx, config)
            .compose(connection -> {
              return connection.createChannelBuilder()
                      .createPublisher(EXCHANGE_NAME
                              , RabbitMQChannelBuilder.JSON_OBJECT_MESSAGE_CODEC
                              , new RabbitMQPublisherOptions().setResendOnReconnect(true)
                      );
            })
            .compose(publisher -> {
              List<Future<Void>> futures = new ArrayList<>(messages.size());
              messages.forEach((k,v) -> {
                AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
                        .messageId(k)
                        .build();
                futures.add(publisher.publish(ROUTING_KEY, properties, v));
              });

              return Future.all(futures);
            })
            .onSuccess(v -> logger.info("All message sent and confirmed"))
            .onFailure(ex -> logger.log(Level.SEVERE, "Failed: {0}", ex))
            ;

Клиент Vert.x Consul

io.vertx.ext.consul.AclToken был удален, вместо этого следует использовать io.vertx.ext.consul.token.AclToken.

Эти устаревшие методы API были удалены:

Check#getNodeName(), вместо этого следует использовать Check#getNode().
ConsulClient#createAclToken(io.vertx.ext.consul.AclToken), вместо этого используйте createAclToken(io.vertx.ext.consul.token.AclToken)
ConsulClient#updateAclToken(io.vertx.ext.consul.AclToken), вместо этого используйте updateAclToken(String, io.vertx.ext.consul.token.AclToken)
ConsulClient#cloneAclToken(String), вместо этого используйте cloneAclToken(String, CloneAclTokenOptions)
ConsulClient#infoAclToken(String), вместо этого используйте readAclToken(String)
ConsulClient#destroyAclToken(String), вместо этого используйте deleteAclToken(String)
ConsulClient#listAclTokens(), вместо этого используйте getAclTokens()

Мониторинг состояния Vert.x

Улучшения зависимостей для проверки состояния

Ранее Vert.x Health Check зависел от Vert.x Web и Vert.x Auth. Теперь он определяет только API проверки состояния, а обработчик маршрута проверки состояния перенесен в Vert.x Web.

Это привело к изменению пакета в объявлениях импорта.

// 4.x
import io.vertx.ext.healthchecks.HealthCheckHandler;

// 5.0
import io.vertx.ext.web.healthchecks.HealthCheckHandler;

Vert.x Разрыв цепи

Удалить устаревший (для удаления) политику повторных попыток

Политика повторных попыток разрыва цепи с аргументом Java-функции была удалена после устаревания в 4.x.

Вместо этого следует использовать RetryPolicy функциональный интерфейс.

// 4.x
breaker.retryPolicy(retryCount -> 5);

// 5.0
breaker.retryPolicy((failure, retryCount) -> 5);

Vert.x MQTT

Устаревшие методы получения/установки строки сообщения will в опциях клиента удалены

Методы получения/установки строки сообщения will в опциях клиента удалены после устаревания в 4.x.

Вместо этого следует использовать версию Buffer

// 4.x
options.setWillMessage(str);

// 5.0
options.setWillMessageBytes(Buffer.buffer(str));

Клиент Vert.x Mail

Удалить устаревшие свойства MailConfig setKeyStore/setKeyStorePassword

Удалить устаревшие свойства MailConfig#setKeyStore и MailConfig#setKeyStorePassword.

Вместо этого используйте MailConfig#setTrustOptions.

// 4.x
options.setKeyStore(trustStorePath);
options.setKeyStorePassword(trustStorePassword);

// 5.0
options.setTrustOptions(new JksOptions().setPath(trustStorePath).setPassword(trustStorePassword));

Vert.x JUnit 5

Удалить устаревший метод проверки успешного выполнения контекста теста

Вместо этого используйте succeedingThenComplete() или succeeding(Handler).

// 4.x
someFuture.onComplete(testContext.succeeding());

// 5.0
someFuture.onComplete(testContex.succeedingThenComplete());

Прокси-сервис Vert.x

Удаление ServiceAuthInterceptor

Вместо этого используйте AuthorizationInterceptor.

// 4.x
new ServiceBinder(vertx)
   .addInterceptor(new ServiceAuthInterceptor()...)
   .register(SomeService.class, service);

// 5.0
new ServiceBinder(vertx)
   .addInterceptor(AuthorizationInterceptor.create(authorizationProvider)...)
   .register(SomeService.class, service);

Функциональный обработчик ServiceBinder

ServiceBinder#addInterceptor(Function) и ServiceBinder#addInterceptor(String, Function) были удалены в пользу варианта с функциональным интерфейсом ServiceInterceptor.

// 4.x
binder.addInterceptor(msg -> vertx.timer(10, TimeUnit.MILLISECONDS).map(msg));

// 5.0
binder.addInterceptor((vertx, interceptorContext, body) -> vertx.timer(10, TimeUnit.MILLISECONDS).map(body));

Удаление утилиты ProxyHelper

Утилита класса ProxyHelper удалена в пользу эквивалентов ServiceProxyBuilder / ServiceBinder.

// 4.x
ProxyHelper.registerService(MyService.class, vertx, service, "the-address");
MyService proxy = ProxyHelper.createProxy(MyService.class, vertx, "the-address");

// 5.0
new ServiceBinder(vertx)
  .setAddress("the-address")
  .register(MyService.class, service);
MyService proxy = new ServiceProxyBuilder(vertx)
  .setAddress("the-address")
  .build(MyService.class)

Vert.x Потоковые расширения

Изменения объектов данных

Несколько классов Vert.x, которые исторически были аннотированы как @VertxGen и считались асинхронными типами, были преобразованы в объекты данных.

Вследствие этого реактивные потоки, такие как генераторы, больше не будут нуждаться в обёртке/развёртывании этого типа, что позволит избежать ненужного выделения памяти.

Это означает, что эти объекты больше не будут обернуты Vert.x RX, и имя пакета типа будет изменено.

Следующие классы были преобразованы в объекты данных:

io.vertx.core.buffer.Buffer
io.vertx.core.net.HostAndPort
io.vertx.core.net.SocketAddress
io.vertx.core.net.SelfSignedCertificate
io.vertx.core.MultiMap
io.vertx.core.datagram.DatagramPacket
io.vertx.core.dns.MxRecord
io.vertx.core.dns.SrvRecord
io.vertx.core.file.FileProps
io.vertx.core.file.FileSystemProps
io.vertx.core.http.Cookie
io.vertx.core.http.HttpFrame
io.vertx.core.http.WebSocketFrame
io.vertx.core.json.JsonEvent

Среди всех вышеперечисленных типов, тип буфера Vert.x, вероятно, наиболее существенно изменился.

io.vertx.core.buffer.Buffer исторически являлся частью API как асинхронный сгенерированный тип, аннотированный @VertxGen. Он всегда был обернут/разворачивался с помощью реактивных потоков, таких как генераторы.

// 4.x
io.vertx.reactivex.core.buffer.Buffer buffer = rxApi.getBuffer();

// 5.0
io.vertx.core.buffer.Buffer buffer = rxApi.getBuffer();

или

// 4.x
stream.write(io.vertx.reactivex.core.buffer.Buffer.buffer("the-string"));

// 5.0
stream.write(io.vertx.core.buffer.Buffer.buffer("the-string"));

То же самое относится и к другим упомянутым типам.

Метрики Vert.x Micrometer

Обновление до Micrometer 1.14

Micrometer 1.14 следует за версией 1.13, которая является несовместимым релизом, если вы используете API PrometheusMeterRegistry в своём коде.

Пожалуйста, ознакомьтесь с руководством по миграции Micrometer по адресу https://github.com/micrometer-metrics/micrometer/wiki/1.13-Migration-Guide.

Метрики пула HTTP-клиентов

Метрики пула HTTP-клиентов теперь представлены как общие метрики пула с типом пула http

vertx_http_client_queue_pending → vertx_pool_queue_pending
vertx_http_client_queue_time_seconds → vertx_pool_queue_time_seconds

Удаление установки реестра в параметрах

Установка параметров MeterRegistry для Micrometer была удалена в пользу новых VertxBuilder вместе с MicrometerMetricsFactory.

// 4.x
Vertx vertx = Vertx.vertx(new VertxOptions()
 .setMetricsOptions(new MicrometerMetricsOptions()
   .setMicrometerRegistry(myRegistry)
   .setEnabled(true)));

// 5.0
Vertx vertx = Vertx.builder()
  .with(new VertxOptions()
    .setMetricsOptions(new MicrometerMetricsOptions()
    .setEnabled(true)))
  .withMetrics(new MicrometerMetricsFactory(myRegistry))
  .build();

Удаление параметров InfluxDB количества потоков

VertxInfluxDbOptions#getNumThreads и VertxInfluxDbOptions#setNumThreads больше не используются.

// 4.x
influxDbOptions.setNumThreads(numThreads);

// 5.0

Переименование поставщика тегов параметров метрик

VertxMicrometerMetricsOptions#setRequestTagsProvider и VertxMicrometerMetricsOptions#getRequestTagsProvider удалены в пользу VertxMicrometerMetricsOptions#setServerRequestTagsProvider и VertxMicrometerMetricsOptions#getServerRequestTagsProvider.

// 4.x
options.setRequestsTagsProvider(provider);

// 5.0
options.setServerRequestsTagsProvider(provider);

Изменения в метках метрик, включенных по умолчанию

Метка HTTP ROUTE больше не включена по умолчанию из-за высокого риска кардинальности.

Чтобы включить её, необходимо изменить параметры метрик при запуске:

options.addLabels(Label.HTTP_ROUTE);

Метка POOL NAME теперь включена по умолчанию.

Vert.x Dropwizard Метрики

Метрики пула HTTP-клиентов

Метрики пула HTTP-клиентов теперь представлены как общие метрики пула с типом пула http и названы в соответствии с адресом сокета конечной точки.

endpoint.<host:port>.queue-delay → queue-delay
endpoint.<host:port>.queue-size → queue-size

Удаление установки реестра метрик в опциях метрик

Установка параметров MetricsRegistry для Dropwizard была удалена в пользу новых VertxBuilder вместе с DropwizardMetricsFactory.

// 4.x
Vertx vertx = Vertx.vertx(new VertxOptions()
 .setMetricsOptions(new DropwizardMetricsOptions()
   .setMetricsRegistry(myRegistry)
   .setEnabled(true)));

// 5.0
Vertx vertx = Vertx.builder()
  .with(new VertxOptions()
    .setMetricsOptions(new DropwizardMetricsOptions()
    .setEnabled(true)))
  .withMetrics(new DropwizardMetricsFactory(myRegistry))
  .build();

Vert.x Схема JSON

Удаление устаревших API

В Vert.x 5 удалены устаревшие API схем JSON. Раньше для каждого черновика был свой собственный SchemaParser. Теперь у вас есть SchemaRepository, и вы можете установить черновик в опциях.

// 4.x
JsonObject schemaJson = new JsonObject(...);
Schema schema = new Draft7SchemaParser(SchemaRouter.create(vertx, new SchemaRouterOptions())).parse(schemaJson , scope);
JsonObject jsonToValidate = new JsonObject(...);
schema.validateSync(jsonToValidate);

// 5.0
JsonObject schemaJson = new JsonObject(...);
SchemaRepository schemaRepo = SchemaRepository.create(new JsonSchemaOptions().setDraft(DRAFT7));
JsonObject jsonToValidate = new JsonObject(...);
OutputUnit result = schemaRepo.validator(JsonSchema.of(schemaJson)).validate(jsonToValidate);

if (result.getValid()) {
  // Successful validation
}

Дополнительные типы ошибок

В Vert.x 5 добавлены дополнительные базовые типы ошибок для выходных блоков.

Если вы создаёте собственные OutputUnits, вам также необходимо включить OutputErrorType. Это помогает определить причину сбоя.

// 4.x
OutputUnit ou = new OutputUnit("instanceLocation", "absoluteKeywordLocation", "keywordLocation", "error");

// 5.0
// Available error types are current OutputErrorType.NONE, OutputErrorType.INVALID_VALID, OutputErrorType.MISSING_VALUE
OutputUnit ou = new OutputUnit("instanceLocation", "absoluteKeywordLocation", "keywordLocation", "error", OutputErrorType.INVALID_VALUE);

© 2025 Eclipse Vert.x™Eclipse Vert.x™ is open source and dual-licensed under the Eclipse Public License 2.0 and the Apache License 2.0.Website design by Michel Krämer.
https://vertx.io/docs/guides/vertx-5-migration-guide/