-
Notifications
You must be signed in to change notification settings - Fork 40.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spring Data REST ignoring @JsonUnwrapped annotation #6722
Comments
This looks like a Spring Data REST bug. Spring Boot 1.3.x uses Spring Data Gosling and Can you please open a DATAREST Jira ticket? /cc @olivergierke |
@gjoris have you created a ticket for this issue? Otherwise, I can do it since it's affecting our project too but I don't want to create a duplicate ticket. |
@polysantiago Hey there, my colleague @gjoris isn't in the office for the next couple of days, but from what he told me about it, he couldn't create an issue ticket in Jira. If you have the possibility to create a ticket, that would be awesome! |
@larsvanherk I've created DATAREST-880 and linked it to this issue. Hope it's enough information! I'll try to debug and find out where the issue lies so as to make it easier for @olivergierke |
Using Spring Boot 1.4.0, Spring Data REST no longer seems to take the @JsonUnwrapped annotation into account to unwrap entities in the JSON responses. The previous Spring Boot versions (i.c. 1.3.7) does not have this problem.
It can be easily reproduced on the master branch of the RestBucks project. When you PUT a payment for an order, the credit card number should be unwrapped, since it is annotated with @JsonUnwrapped, but it is not:
The expected output would be (if the @JsonUnwrapped annotation was parsed correctly):
We have written tests for the @JsonUnwrapped annotation specifically, not using the Spring Data REST infrastructure, and it does work correctly, which makes us believe that the problem lies somewhere in the framework. I haven't been able to pinpoint where exactly thus far, though.
As said: workaround (for us, at least) at this point is downgrading to 1.3.7.
The text was updated successfully, but these errors were encountered: