GenericType unmarshalling fails in spring restful

Question

Given below is the scenario in which I am facing difficulty, I am using Restful based webservice in spring MVC where I am ineracting with JSON.

I have a class : RegexObject and another class RegexObjectDME extends RegexObject. RegexObject is in one common project, which is being used as it is in webservice consumer and RegexObjectDME in webservice provider.

Now, There is another bean in the same common project, Say HDTaskInfoBean , There are two child beans extending HDTaskInfoBean as

HDTaskInfoBeanClient extends HDTaskInfoBean<RegexObject>

and HDTaskInfoBeanAgent extends HDTaskInfoBean<RegexObjectDME> .

The RegexObjectDME and RegexObject have same properties except a few methods.

HDTaskInfoBeanClient and HDTaskInfoBeanAgent too have same properties and there is generic setter getters for regexObject and regexObjectDME. The T type property name is regexArray.

HDTaskInfoBeanClient is used while making request and HDTaskInfoBeanAgent is used on webservice side.

I am getting the following exception: Syntactical Error.

Another Scenario I used string as requestbody and tried to unmarshall it into Java Object using Gson() , It gave error:

Request processing failed; nested exception is java.lang.UnsupportedOperationException: Expecting parameterized type, got class com.*. Are you missing the use of TypeToken idiom?

Please help, I want to use **HDTaskInfoBeanClient ** in Request and HDTaskInfoBeanAgent on webservice provider side. If there is any alternative to it, Kindly suggest.

Thanks in advance :)

Answer 1

I am not sure that why did this weird behavior was shown by default message converter which Comes with Spring Framework. I found that one of the very good message converter from JSON to Object and back is GSON(A utility by Google) . One reliable approach to handle such a problem is write your own Custom Message Converter by overriding a class and Using GSON in that. Here is the link for such a solution. I hope it helps you as a solution and would be more reliable.

Regards, Rahul