quarkus-bot[bot]
commented
12 months ago /cc @evanchooly (mongodb), @loicmathieu (mongodb)
Open GregJohnStewart opened 12 months ago
quarkus-bot[bot]
commented
12 months ago /cc @evanchooly (mongodb), @loicmathieu (mongodb)
loicmathieu
commented
11 months ago Hi, Reading the ticket at MongoDB side you dissect the issue being the update of the MongoDB driver from 4.9.1 to 4.10.1. So the issue seems to be on the MongoDB driver and not on the Quarkus MongoDB client extension. You can confirm that by forcing on your test application an older version of the driver.
GregJohnStewart
commented
11 months ago That was my assumption, that it was the updated driver. However, it looks like (from that mongodb ticket) that not much has changed to the pojo codec.
My assumption at this point (hence this ticket) is not that the codec is at fault, but how it is setup within Quarkus. Setting the quarkus version back to 3.2.4.Final, and running the tests show that they passed on earlier quarkus versions. Thanks for the check on the codec version though!
(If you are using the same POC code to test again, do a pull, I made some tweaks to pass once it got past the error reported here)
loicmathieu
commented
11 months ago What changed between 3.2 and 3.3 is the version of the MongoDB driver (from 4.9 to 4.10), as far as I remember (but I didn't check) nothing more changed.
That's why I ask if you can try with Quarkus 3.3 or 3.4 by downgrading the MongoDB driver to 4.9 as I think the issue is in the driver. If it proves to not be the case I'll be happy to dig deeper.
GregJohnStewart
commented
11 months ago Ah apologies, trying now. Happen to know how to do this without having to rebuild the Quarkus plugin? Even when looking at the plugin though, where are library versions defined? There are no versions listed for dependencies under extensions/mongodb-client/runtime. Poking around, looks like versions are centrally managed somewhere, but not seeing where.
loicmathieu
commented
11 months ago You must use dependency management to force a different version of MongoDB of the one coming from the Quarkus BOM.
I'm not familiar with Gradle but there is some strategy explained here: https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html
GregJohnStewart
commented
11 months ago I made several attempts, but no joy on getting past a gradle verification step on forcing the lib version.. (various libs that use the core versions were disliking the change)
I just pushed the addition of a pom and wrapper so should be good to go as a Maven project. I don't know offhand how to force the versioning here though. I can do some googling, but if @loicmathieu, you know offhand the dive would be appreciated
loicmathieu
commented
11 months ago On the pom.xml you add a the dependency inside <dependencyManagement> with the forced version.
If I remember correctly this should be before the Quarkus BOM so it is taken into consideration.
GregJohnStewart
commented
11 months ago Alright, after much tweaking, I think I finally have the Mongo dependency forced to 4.9.1 (on Gradle)(I'm willing to be proven that I did this wrong, but I think I am right with it). The changes have been pushed.
Alas, the issue still occurs with the driver version forced back to 4.9.1, and using Quarkus 3.5.0.
Sorry for the lateness, @loicmathieu life has been busy
loicmathieu
commented
11 months ago @GregJohnStewart thanks for making the verification, we need to investigate what's going on.
loicmathieu
commented
11 months ago I can reproduce it.
For the record, in Gradle, the easiest way to force a dependency version is the following:
configurations.all {
resolutionStrategy {
force('org.mongodb:mongodb-driver-sync:4.9.1')
force('org.mongodb:mongodb-driver-reactivestreams:4.9.1')
force('org.mongodb:mongodb-driver-core:4.9.1')
}
}@loicmathieu :wave: Happen to dive into this? Been a hot second. Still an issue as of 3.6.6.
GregJohnStewart
commented
6 months ago Still an issue moving to 3.9.2
ashni-mongodb
commented
4 days ago Hi folks, we've included a fix for this regression in a recent release of the MongoDB Java Drivers (PR: https://github.com/mongodb/mongo-java-driver/pull/1423). Please have a look, and let me know if you have feedback or thoughts. Thank you!
loicmathieu
commented
1 day ago @ashni-mongodb thanks for the information, I'll check our reproducer with the latest MongoDB driver and give feedback
Describe the bug
The more recent versions of Quarkus have seemed to break how the PojoCodec handles classes with generics (even only when being passed instantiated classes with fully realized generics). This was supported and works fine in
3.2.4.Final.However, when moving to
3.4.2, the following error occurs:org.bson.codecs.configuration.CodecConfigurationException: Animal contains generic types that have not been specialised. Top level classes with generic types are not supported by the PojoCodec.As I assumed first that this was a codec issue, I have a ticket out on Mongo's jira, but they claim not a ton has changed: https://jira.mongodb.org/browse/JAVA-5173
This prevents me moving to newer Quarkus versions, and also breaks a super handy feature of Mongodb being able to easily handle polymorphism
Expected behavior
the POJO Codec should be able a class with generics, with a
@BsonDiscriminatorto manage the concrete class handlingActual behavior
The POJO Codec fails with the following error:
How to Reproduce?
https://github.com/GregJohnStewart/quarkus-proofs/tree/main/mongo-codec-issue
./gradlew testSwitch to see the tests working under
3.2.4.Finalingradle.propertiesOutput of
uname -aorverNo response
Output of
java -versionopenjdk 17.0.8.1 2023-08-24 OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu120.04) OpenJDK 64-Bit Server VM (build 17.0.8.1+1-Ubuntu-0ubuntu120.04, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.2.4.Final
Build tool (ie. output of
mvnw --versionorgradlew --version)Gradle
Additional information
On a side note, I have noticed a few other issues with the codec (even in the older versions), from not properly deserializing (returning classes of the wrong type)(haven't seen this consistently reproducibly enough to report), as well as the codec not being able to reconcile and deserialize classes after a restart in dev mode (reproducible, more minor, if highly annoying). Can provide additional details, or another issue if needed. Just throwing it out there the latest iterations of the mongo client seem off.