Date fields rendered as objects with 'content' field [DATAREST-888]

[spring-projects-issues]

Rob Moore opened DATAREST-888 and commented

Previously date fields rendered as a string (eg, "2016-07-12T17:58:43.643Z") in 1.3.7. With the 1.4.0 release, they now are rendered as an object with a content field (eg, { content: "2016-07-12T17:58:43.643Z" }).

I have created an example project (modified from the Spring example project) demonstrating this behavior:

https://github.com/robmoore/gs-accessing-mongodb-data-rest

The main branch has the 1.4.0 version with a supporting test and the spring-1.3.7 branch has an example of the previous behavior with a supporting test.

It seems like the date property is being treated as a resource by mistake.

---

Reference URL: http://stackoverflow.com/questions/39172792/how-do-i-avoid-content-fields-in-joda-objects

Issue Links:

• DATAREST-893 Problem serializing JSR-310 types (e.g. LocalDate) ("is duplicated by")

2 votes, 5 watchers

[spring-projects-issues]

Oyku Gencay commented

This is exactly what I've experienced. I've created DATAREST-893 without seeing this one and gave explanation of the root cause and how to work around. I've patched my local repo accordingly until it gets fixed. Maybe it helps

[spring-projects-issues]

Oliver Drotbohm commented

That seems to be a consequence of Spring Boot not setting up MongoMappingContext correctly. I've filed a ticket with Boot, hopefully to be fixed for the upcoming 1.4.1 release

[spring-projects-issues]

Marc Tarin commented

Though the pull request for the mentionned ticket has been shipped with the 1.4.1 release, the issue with joda time objects remains

[spring-projects-issues]

Oliver Drotbohm commented

Can you provide a sample project that reproduces the error against 1.4.1?

[spring-projects-issues]

Rob Moore commented

I updated my sample project to use 1.4.1 and Joda instead of Java native LocalDate and it is behaving as it did with 1.3.7

[spring-projects-issues]

Oliver Drotbohm commented

Thanks, I'll have a look

[spring-projects-issues]

Rob Moore commented

Just to be clear, I mean the fix works with Joda Time

[spring-projects-issues]

Marc Tarin commented

Upgrading to Spring Boot 1.4.1 indeed solved the issue that I described here. Regarding my first comment, I need to double-check the configuration of a project at work, I'll get back to you if the issue still shows.

In the mean time, another user mentioned a similar problem on stackoverflow, even though he uses SB 1.4.1

[spring-projects-issues]

Oliver Drotbohm commented

There was an example provided for DATAREST-907 which actually works as expected. Also, I can't get your example to fail. I can run ./gradlew test on the complete module and the build succeeds. Can you clarify?

[spring-projects-issues]

Rob Moore commented

Not sure who that comment was meant for but if I'm the intended recipient my apologies for the confusion. I was trying to indicate that upgrading to 1.4.1 fixed the issue for me. It seems like that's the case for Marc as well. I believe we can close this ticket

[spring-projects-issues]

Marc Tarin commented

It took me some time to figure out why I still had the issue, but after tweaking my project in many ways, I discovered that if you simply add the @EnableMongoAudit annotation to the main application class (the one annotated with @SpringBootApplication), it breaks the datetime serialization again (the "content" field shows again).

[spring-projects-issues]

Marc Tarin commented

I do agree that this ticket should be closed (I'll open another ticket for the annotation issue)

[spring-projects-issues]

Marc Tarin commented

FYI, the problem I had when annotating the application with @EnableMongoAudit has somehow been solved in Spring Boot 1.4.2