rhomobile / rhoconnect-java Goto Github PK

If occure exception in source adapter,should return error(500) .In RhoconnectController.java is always return HttpStatus.OK.

Using the rhoconnect java plugin, I did encountered major issue with the json conversion of objects. Using the JSONObject API, the plugin fails to handle properly nested objects/list/arrays/map/wrappers. It seems that the whole plugin uses JSONObject API extensively both in the two jar files. In our current Spring application, we are using Jackson ObjectMapper API and it pretty much excel in converting various objects and even inner classes and nested objects. Unlike JSONObject, it doesn't convert everything to String quoted element, especially arrays/list and nested object, I am hoping if I could request the rhoconnect team to fix this issue or better I suggest to switch from simple-json to jackson objectmapper api for json handling matters.

To provide a concrete scenario, for example a Map with these object

public class Form{  
  Long id;  
  List<Schedule> schedules;  
  //getters and setters...  
}  

public class Schedule{  
  private Timestamp startDate;  
  private Timestamp endDate;  
 //getters and setters...  
}  

This will lead to json string converted by JSONObject

{  
  "schedules" : "[  
        {  
           \"startDate\" : \"Feb 8, 2013 11:00 AM\",   
           \"endDate\" : \"Feb 8, 2013 2:00 PM\"  
        }  
    ]",  
  "id"  : "1108"  
}  

Which is wrong, the id value must stay as unquoted, and the array value for schedule must also be unquoted to be able to read properly by json parser as array. In the local database of the device, its hard to read such nested object without manually parsing the specific element of schedules and doing the dirty work arounds which is not scalable and fragile.

Hoping the rhoconnect team would consider this report, should i post this on github? Please tell me what to do?

And also, in our current Spring application, using ObjectMapper in doing the json transport on http did not give us any issues like this, so I think for rhoconnect API to be able to produce better JSON communication, ObjectMapper is the way to go, plus it is more popular and still improving.

But since my company can't wait for the rhoconnect team to apply the changes requested, we will be forking the project and change the implementation of json conversion from simple json's JSONObject API to jackson's ObjectMapper API. I could try to upload the changes and let the rhoconnect team to decide whether to adopt it.