Stefan Schmidt added a comment - 19/Aug/10 12:21 AM Commit 57938d2f24b6dfd089d3f4fdda905a84b6ae69f3 adds the new add-on to Roo master. It also integrates with the current MVC scaffolding by exposing the following method signatures: @RequestMapping(value = "/{id}", method = RequestMethod.GET, headers = "Accept=application/json") @ResponseBody public String showJson(@PathVariable("id") Long id) { return MyType.findMyType(id).toJson(); } @RequestMapping(method = RequestMethod.POST, headers = "Accept=application/json") public ResponseEntity<String> createFromJson(@RequestBody String json) { MyType.fromJson(json).persist(); return new ResponseEntity<String>("MyType created", HttpStatus.CREATED); } @RequestMapping(headers = "Accept=application/json") @ResponseBody public String listJson() { return MyType.toJsonArray(MyType.findAllMyTypes()); } @RequestMapping(value = "/jsonArray", method = RequestMethod.POST, headers = "Accept=application/json") public ResponseEntity<String> createFromJsonArray(@RequestBody String json) { for (MyType myType: MyType.fromJsonArray(json)) { myType.persist(); } return new ResponseEntity<String>("MyType created", HttpStatus.CREATED); }

Stefan Schmidt added a comment - 19/Aug/10 7:51 PM On a side note, the exposing of the JSON functionality can be disabled by a new attribute in the @RooWebScaffold annotation 'exposeJson' which can be set to false. I am also adding a sample script which shows how to use the JSON methods exposed through a controller. The script works against the Roo petclinic sample application (clinic.roo).

Keith Donald added a comment - 20/Aug/10 6:44 AM How often do you think this will be used, compared to simply using @[email protected] on a POJO and relying on Jackson's JSON ObjectMapper? I assume you are targeting custom JSON reading/writing scenarios, but it'd be good to clarify exactly when one should be expected to use this feature.

Jim Hazen added a comment - 05/Oct/10 3:23 PM I like this functionality, however I wish that the implementation was consistent with Spring's use of Jackson for @[email protected] I already use Jackson annotations to define the desired codec for my web interface. It's a drag that when I turn around and {to,from} Json() the object returned from @RequestBody the json isn't the same that from Jackson. Not sure why @[email protected] uses Jackson and this plugin uses flexjson. Jackson appears to have richer annotation support and is already the @REST default provider. I suggest keeping this plugin's API and migrating the provider from flexjson to Jackson.