One thing I couldn’t figure out was why the CustomerDBSpring sample app and the CustomerRestfulService app were producing different JSON. It turns out it was all down to how Jersey was configured to convert Java to JSON. This guy describes the problem well and the first solution that I tried, but clearly that wasn’t a great long term option. The longer term solution was to use Jersey’s POJO support, which basically amounts to sticking this in your web.xml.
<init-param> <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name> <param-value>true</param-value> </init-param>
BTW I don’t usually blog on a Saturday night, not that I’m saying there is anything wrong with that, but its just that my wife is watching the final of Strictly Come Dancing 😦
Awesome find there on the POJO support setting!
Essentially what you are doing with this feature is changing how you are mapping the object to JSON and back. With my example, I am using JAXB, whereas by turning on the POJO support you are using Jackson to map the POJOs ignoring the JAXB annotations. I’m not sure specifically why this lands you more with what you want in this case, but if it works that is great. Interested to hear more about how you are liking Netbeans vs Eclipse – it has been a long time since I looked at Netbeans for development.
Fair point, I was looking for a simple solution where I didn’t have to override each and every Backbone client’s parse method to handle the (valid but apparently unexpected) JSON returned by the Jersey RESTful services. Perhaps the JAXB approach also allows this but I don’t have the time to explore that option.
BTW I’m writing this while waiting for my Sony Entertainment Network accounts to be setup, which is a painfully slow process, so that my wee boy can get a working PSVita with FIFA 13 in the morning. Santa is just is so inconsiderate, he should have sorted this out before now!