On Mar 8, 2010, at 1:07 PM, shan25 wrote:
>
> Thanks for the responses and sorry abt getting back late..
>
> When I removed the @Consumes from @Get method the exception that I
> mentioned
> went away and both the techniques as suggested by Paul (using
> @Provider or
> conversion based on rules ) seems fine except that I will have to do
> the
> deserialization myself either in the provider class or in the String
> argument constructor. right ?
Yes, and use a JSON API like Jackson, if you do not want to use
JSONObject which should work directly (because there is a String
constructor).
> Wouldn't it be possible to have a support
> where the deserialization of the parameter (from json to java custom
> type)
> happens automatically (if i specify using some annotation what is
> the type
> of data-json,xml.. that is excepted in as QueryParam) much like what
> happens
> when I annotate the return object to produce json using @Produces?
If you add a specific annotation to the parameter, then yes such a
generic solution could be supported. In fact you can implement exactly
that using StringReaderProvider and plugin generic Jackson support. As
the StringReaderProvider has access to the parameter annotations.
> Infact
> that i what i thought would happen when i annotated @GET with
> @Consumes("application/json").. let me know if my question isn't
> making
> sense, but i was thinking since the conversion of java to json can
> happen
> the reverse should also be possible and having to write a provider
> etc where
> you have to deserialize and set the data back to the object can be
> eliminated.
>
No @Consumes/_at_Produces on resource methods (or inherited from the
resource class) are only associated with the entity body of a request
or response and not associated with one or more parameters (path,
query, header, cookie).
Paul.