Grails render as JSON catch

One of a reasons your controller doesn’t render a proper response in JSON format might be wrong package name that you use. It is easy to overlook. Import are on top of a file, you look at your code and everything seems to be fine. Except response is still not in JSON format. Consider this simple controller: class RestJsonCatchController {def grailsJson() {render([first: 'foo', second: 5] as grails.converters.JSON) }def netSfJson() {render([first: 'foo', second: 5] as net.sf.json.JSON) }} And now, with finger crossed… We have a winner! $ curl localhost:8080/example/restJsonCatch/grailsJson{"first":"foo","second":5}$ curl localhost:8080/example/restJsonCatch/netSfJson{first=foo, second=5} As you can see only grails.converters.JSON converts your response to JSON format. There is no such converter for net.sf.json.JSON, so Grails has no converter to apply and it renders Map normally. Conclusion: always carefully look at your imports if you’re working with JSON in Grails! Edit: Burt suggested that this is a bug. I’ve submitted JIRA issue here: GRAILS-9622 render as class that is not a codec should throw exception

One of a reasons your controller doesn’t render a proper response in JSON format might be wrong package name that you use. It is easy to overlook. Import are on top of a file, you look at your code and everything seems to be fine. Except response is still not in JSON format.

Consider this simple controller:

<span class="keyword">class</span> <span class="class">RestJsonCatchController</span> {<br />    <span class="keyword">def</span> <span class="method">grailsJson</span>() {<br />        <span class="method">render</span>([<span class="field">first</span>: <span class="string">'foo'</span>, <span class="field">second</span>: <span class="number">5</span>] <span class="keyword">as</span> grails.converters.<span class="class">JSON</span>)<br />    }<br /><br />    <span class="keyword">def</span> <span class="method">netSfJson</span>() {<br />        <span class="method">render</span>([<span class="field">first</span>: <span class="string">'foo'</span>, <span class="field">second</span>: <span class="number">5</span>] <span class="keyword">as</span> net.sf.json.<span class="class">JSON</span>)<br />    }<br />}<br />

And now, with finger crossed… We have a winner!

<span class="keyword">$</span> curl localhost:8080/example/restJsonCatch/grailsJson<br />{"first":"foo","second":5}<br /><span class="keyword">$</span> curl localhost:8080/example/restJsonCatch/netSfJson<br />{first=foo, second=5}<br />

As you can see only grails.converters.<span class="class">JSON</span> converts your response to JSON format. There is no such converter for net.sf.json.<span class="class">JSON</span>, so Grails has no converter to apply and it renders Map normally.

Conclusion: always carefully look at your imports if you’re working with JSON in Grails!

Edit: Burt suggested that this is a bug. I’ve submitted JIRA issue here: GRAILS-9622 render as class that is not a codec should throw exception

You May Also Like

Micro services on the JVM part 1 – Clojure

Micro services could be a buzzword of 2014 for me. Few months ago I was curious to try Dropwizard framework as a separate backend, but didn’t get the whole idea yet. But then I watched a mind-blowing “Micro-Services Architecture” talk by Fred George. Also, the 4.0 release notes of Spring covers microservices as an important rising trend as well. After 10 years of having SOA in mind, but still developing monoliths, it’s a really tempting idea to try to decouple systems into a set of independently developed and deployed RESTful services.

Micro services could be a buzzword of 2014 for me. Few months ago I was curious to try Dropwizard framework as a separate backend, but didn’t get the whole idea yet. But then I watched a mind-blowing “Micro-Services Architecture” talk by Fred George. Also, the 4.0 release notes of Spring covers microservices as an important rising trend as well. After 10 years of having SOA in mind, but still developing monoliths, it’s a really tempting idea to try to decouple systems into a set of independently developed and deployed RESTful services.