Jakarta - EE 10 - RestAssured not supporting JSON-B 3.0 #29225
Assignees
Labels
area/jakarta
kind/bug-thirdparty
Bugs that are caused by third-party components and not causing a major dysfunction of core Quarkus.
Comments
|
/cc @gsmet, @manovotn, @maxandersen, @radcortez, @Sanne |
|
Yeah. We will have to live with it until REST Assured provides a Jakarta-compatible version. I will document it but I think we can close it. We will update REST Assured when available. |
|
@gsmet if we close these is there another way to find list of dependencies/blockers we have identified thus far that are still open? |
|
Not really. Let's keep it open then. I wouldn't call it a blocker really but yeah better have it in mind. |
|
Is this still an issue? |
|
AFAIK, yes. |
|
kk, thanks |
|
Yes, still happening in Quarkus 3 Alpha 2 as nothing has changed on the RestAssured side |
|
I started working on that upstream and I will see if I can come up with an acceptable solution. |
|
possible workaround which I tested: using quarkus-resteasy-reactive-jackson instead of quarkus-resteasy-reactive-jsonb (the jackson plugin can handle jsonb annotations). But it would be nice if the jsonb plugin is working again with restassured, because otherwise it can quickly happen that a mixture of jackson and jsonb annotations is used in an application. |
|
What is the impact of implementing that workaround? Does it means that |
|
We have a fairly large amount of JSON-B adapters and really need the tests to use JSON-B, which I solved in #13459 (comment). Now, when we are upgrading to 3.2, this hits us hard. I would be fairly uncomfortable running a different JSON library in test than in the released version and we originally switched from Jackson to JSON-B because Jackson lacked features we need. Any idea how we can fix or work around this? I might help with coding if needed, though I have no experience with the Quarkus code base. |
|
I believe the change should be done in RestAssured (rest-assured/rest-assured#1651) Not sure if it's only to update the import references, or if there is anything else that should be done. I tried to contribute, but wasn't able to compile the project (I'm not versed on Groovy) and couldn't give much time to solve my environment issue. |
|
It’s more complex than that. I have a branch somewhere with some preliminary work but didn’t have time to finish it yet. |
|
Right. I think we will pick a few tests and rewrite them without RestAssured to see if we can get them to work and how much effort it takes. |
|
Given that Quarkus 2.x EoL is going to be soon (this year as far as I've read), is there any official/recommended action to take when migrating to Quarkus 3.0? |
|
As far as I understand this is still an issue for version 3.4.3 because in my test case, I am getting the error. |
This is a major blocker for my team since all our RestAssured-tests use JSON-B. We have so far resisted to migrate to Quarkus 3 because of this, and I dread when we will have to do anyway. If this can't be fixed, I would also request a migration guide in this case. |
|
This issue depends on: |
|
+1 having the same issue |
|
Question: Given that JSONB is still not supported, is this a valid workaround with Jackson?
Should I consider something else? What's the difference between |
|
There RestAssured library can work with multiple JSON libraries. When you do not specify anything it tries in that order:
Source: JsonObjectDeserializer.java lines 52 to 62 For an unknown reason to me, the jackson lib v2 that is on the classpath, is not correctly detected (see the classpath at the bottom of my message). As discussed in this issue, if Yasson is used it is failing with quarkus 3: So one option is to try to influence RestAssured, with tricks like: @BeforeAll
static void configureRestAssured() {
RestAssured.config = RestAssured.config().objectMapperConfig(
ObjectMapperConfig.objectMapperConfig().defaultObjectMapperType(ObjectMapperType.GSON)
);
JsonPath.config = new JsonPathConfig().defaultParserType(JsonParserType.GSON);
}And also when accessing the response.jsonPath(JsonPath.config)instead of response.jsonPath()--> So this means a lot of changes to me. Note that the configuration Right now I decided to prevent usage of Yasson in RestAssured (broken until rest-assured/rest-assured#1651 is fixed) by just adding Test runtime classpath Before adding gson to the classpath in my project, output the command: testRuntimeClasspath
|
gsmet
added
kind/bug-thirdparty
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
With Quarkus 3.0.0.Alpha1, when we use the
ObjectMapperType.JSONBin a RestAssured test, we get aNoClassDefFoundErrorbecause it looks for the oldjavax/json/bind/Jsonbpackage and not the new onejakarta/json/bind.RestAssured 5.2.0 still does not support it. See: rest-assured/rest-assured#1651
Relates to #13459
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
No response
Output of
uname -aorverNo response
Output of
java -versionNo response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.0.0.Alpha1
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: