quarkus-rest-jackson doesn't support @JsonManagedReference/@JsonBackReference
#45753
Comments
|
/cc @geoand (jackson), @gsmet (jackson), @mariofusco (jackson) |
|
Have tried to replace Not sure where this |
|
Thanks a lot for the reproducer! I could indeed reproduce the quarkus issue (which is also present if you replace That said, I have zero clue what is causing the original problem... |
The Docker image built during the But anyway, the Wildfly tests are only meant to show that that's probably not RESTeasy responsible of the issue but its Quarkus extension.
IMHO what's causing the issue is that, as the exception is saying, the Jackson extension doesn't support |
There is nothing specific that Quarkus does to support any Jackson features - we just configure and use
Quarkus doesn't provide anything OOTB for supporting serialization / deserialization of ORM entities with Jackson, but I know this topic has come up before. Perhaps @yrodiere remember where. |
The main recommendation is not to do it at all, because of this infinite recursion problem, but also because that's unsafe (implies database access outside of transactions). Instead, you should map your entities to DTOs before returning them from your REST endpoint, either explicitly (e.g. with mapstruct) or by leveraging "projection" features (e.g. |
|
What I'm trying to say is that the same test case that fails when run with Quarkus, succeeds when run with Jakarta EE and Wildfly. Meaning that used with |
Sure, if you don't do it, you don't have the issue. :-)
That's not the issue here.
Not sure where din you see something like this in the reproducer but this isn't at all the case.
Doing things differently and working around an issue doesn't fix the issue. While using DTOs is recommended, this isn't an option in this case, for reasons that I won't develop here. And anyway, using JPA entities is perfectly legal, DTOs aren't mandatory. |
Indeed it isn't, I jumped to conclusions because using entities as parameters / return type on REST endpoint methods is the only use case that's ever been presented to me.
Indeed. In that case I'll just say I don't know how to address this use case, as I've never seen it. Not a single bit helpful either, but maybe less annoying. That being said, looking at your reproducer, the Jakarta one is cheating, as it serializes the customer of an order manually: https://github.com/nicolasduminil/orms/blob/647584734eaed170abdc4b34220bf9529f681457/jakarta-orm/src/main/java/fr/simplex_software/workshop/jakarta/orm/data/serializers/OrderListSerializer.java EDIT: Though that class doesn't seem referenced anywhere... Some Jakarta EE magic? 🤔 |
No, it doesn't. You might be thinking that because you've seen this And you may be sure that I wouldn't provide a cheating reproducer. |
|
I wasn't accusing you 🙄 Anyway, I'll get of your way, since it doesn't look like these concerns are really Hibernate-related, and I know next to nothing about Jackson. All the best to you. |
|
Just a short update to let you know that the same Quarkus test, using XML instead of JSON serialization, i.e. using I updated the reproducer as well. |
There is a 2nd concern mentioned above as I replaced, in the Quarkus test, IMHO, this one seems to be related to Hibernate, right ? I'm not saying it's a bug but I think that we should try to understand how come that most of Jackson specific annotations don't seem to be supported by the Quarkus Jackson RESTeasy extension, while they are supported by the Wildfly RESTeasy Jackson binder ? |
Would be interesting to see the rest of the stack trace. It looks like some Hibernate ORM internals are used to retrieve an entity identifier, but they get passed a |
|
If I had one thing to recommend to understand the initial issue, it would be to decompile the bytecode for the entities in both cases (Quarkus and WildFly) and compare them. I wouldn't be surprised if Quarkus was applying some magic that makes Jackson unhappy, either via the Hibernate bytecode enhancement or something Quarkus-specific. |
|
My suggestion would be to debug the working Wldfly tests vs the non working Quarkus one and see why Jackson is behaving differently. |
|
FWIW, I applied this change: diff --git a/quarkus-orm/src/main/java/fr/simplex_software/workshop/quarkus/orm/data/Customer.java b/quarkus-orm/src/main/java/fr/simplex_software/workshop/quarkus/orm/data/Customer.java
index 4bfebea..cac6bad 100644
--- a/quarkus-orm/src/main/java/fr/simplex_software/workshop/quarkus/orm/data/Customer.java
+++ b/quarkus-orm/src/main/java/fr/simplex_software/workshop/quarkus/orm/data/Customer.java
@@ -52,7 +52,7 @@ public class Customer
@JsonManagedReference
@XmlTransient
@JsonProperty
- public List<Order> orders = new ArrayList<>();
+ private List<Order> orders = new ArrayList<>();
public Customer() {}
and I have a different error: |
|
@gsmet : this is already much clearer and I need to check as it seems to be just an unique field duplicate error. However, I'm surprised that by simply changing the visibility of that property, the behavior changes dramatically as well. |
|
@gsmet: yeah, this was it, changing to Is it expected that such an insignificant modification affects the whole behavior of the test case ? In any case, I'm closing the issue as fixed. Many thanks again for your help and support. |
Describe the bug
Hello,
I'm facing a strange behavior with Quarkus 3.17.6 and
quarkus-rest-jacksonextension. A REST service CRUDs a couple of JPA entities. These entities maintain a bi-directional one-to-many relationship. In order to avoid infinite recursion, the Jackson@JsonManagedReference/@JsonBackReferenceannotation are used.Trying to serialize payloads containing these entities, the following exception is raised:
Expected behavior
I expect that
quarkus-rest-jacksonbe able to use@JsonManagedReference/@JsonBackReferenceand to successfuly serialize the entities.In order to make sure that this should work, I implemented exactly the same test case using Jakarta EE 10 and it works as expected.
Actual behavior
The Quarkus implementation doesn't work and raises the mentioned exception, as opposed to the Jakarta EE implemntation, whichworks as expected.
How to Reproduce?
Reproducer: https://github.com/nicolasduminil/orms.git
The repository has two projects: quarkus-orm which reproduces the issue and jakarta-orm which works as expected.
The README.md file in the repository contains instructions of how to reproduce.
Output of
uname -aorverLinux nicolas-XPS-15-9570 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -versionjava version "21.0.3" 2024-04-16 LTS Java(TM) SE Runtime Environment (build 21.0.3+7-LTS-152) Java HotSpot(TM) 64-Bit Server VM (build 21.0.3+7-LTS-152, mixed mode, sharing)
Quarkus version or git rev
3.17.6
Build tool (ie. output of
mvnw --versionorgradlew --version)Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Maven home: /opt/apache-maven-3.9.5 Java version: 21.0.3, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-21-oracle-x64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.8.0-51-generic", arch: "amd64", family: "unix"
Additional information
N/A
The text was updated successfully, but these errors were encountered: