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

Wicket form submit not safe for redirecting to intercept page

The problem When you have a form, that anybody can see, but only logged on users can POST, you may want to redirect the user to the login page, and back to the form after login Using wicket 1.3/1.4, if you do that using redirectToInterceptPage(loginP...The problem When you have a form, that anybody can see, but only logged on users can POST, you may want to redirect the user to the login page, and back to the form after login Using wicket 1.3/1.4, if you do that using redirectToInterceptPage(loginP...

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.

Scrum w Polsce – TouK

Nasi koledzy z Fluidcircle opublikowali właśnie studium przypadku opisujące doświadczenia TouK z wykorzystania metodyki Scrum. Wszystko w ramach programu “Scrum…