Skip to content

Incompatibilities between Quarkus >= 3.15 and vertx extensions #3716

@sophokles73

Description

@sophokles73

Quarkus 3.15 has updated its dependency to the MongoDB Java driver to major version 5 which is not compatible with the previous version 4.

The MongoDB based device registry component uses vertx-mongo-client to interact with MongoDB. Quarkus 3.15 depends on vert.x 4.5.21 which uses the MongoDB Java Reactive Streams Driver in major version 4 and is incompatible with version 5. Therefore, the device registry now explicitly defines a corresponding dependency on the MongoDB Java Reactive Streams driver instead of using the dependency defined by the Quarkus platform BOM.

Unfortunately, this also means that we only can connect to MongoDB server major versions <= 7 because. With 8.0 and 8.1 already being available, I believe that we will need to make sure that we can leverage these more recent versions as well.

I see two separate ways forward here:

Create a PR for vert.x to upgrade its MongoDB driver dependency to version 5. This might require some code changes in the vertx-mongodb module but should allow us to continue to use the vertx-mongodb API in our code.
Migrate our MongoDB based registry to use one of the APIs provided by the Quarkus MongoDB client extension:
    the native reactive API that the MongoDB Java Reactive driver provides, or
    the [Mutiny based API](https://quarkus.io/version/3.27/guides/mongodb#reactive) that Quarkus provides as an async wrapper around the MongoDB driver, or
    Panache with MongoDB as described by the [Quarkus Mongo tutorial](https://quarkus.io/version/3.27/guides/mongodb#simplifying-mongodb-client-usage-using-bson-codec).

Personally, I would indeed prefer one of the (sub-)options under 2 in order to be able to take advantage of Quarkus support for it, in particular when it comes to building native images. Figuring out the correct configuration for the native image builder is quite annoying and takes time that I would rather spend on the functionality.

The same is true for other areas in the code base where we basically roll our own implementation even if Quarkus provides generic support for the problem at hand by means of an extension. We deliberately chose to not use those extensions at some point in the past, but I think we need to review those choices and reconsider the circumstances.

WDYT @calohmn @mattkaem ?

Metadata

Metadata

Assignees

No one assigned

    Labels

    MongoDB Device Registryissues related to the Device Registry implementation based on MongoDBQuarkusissues with the (experimental) Quarkus based componentsdependenciesPull requests that update a dependency file

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions