True, that's certainly less code then the MessageBodyReader approach.
-Noah
On Fri, Mar 18, 2011 at 3:13 PM, Martin Matula <martin.matula_at_oracle.com>wrote:
> You can do what Jakub suggested - for your API users it still looks the
> same and you can minimize duplication of code by calling the JSON method
> from the String one (once your String one constructs the FooBean which it
> would pass as a parameter).
> Martin
>
>
> On 18.3.2011 20:05, NBW wrote:
>
> So yes, I was trying to consolidate things into one endpoint. Originally, I
> thought I could do something like this:
>
> @POST
> @Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN})
> @Produces(MediaType.APPLICATION_JSON)
> public Response test1(@FormParam("foo") String foo, FooBean fooBeanJsonDO)
> {
> ...
> }
>
> And I had hoped that Jersey would be able to infer which method parameter
> to unmarshall into based on the Resquest type. Per request the client is
> only going to send one type of data, it can't send both Json AND form data
> in the same request for example. So based on this restriction I had hoped
> that Jersey would be able to unmarshal into the proper parameter, eg. use
> the FormParam when receiving form data and use the bean when receiving Json
> data that matched the resource path and HTTP method for this endpoint.
>
> Looking back, I suppose that capability might be a bit ugly though
> because then the method would have to test to see if the String was null and
> the bean wasn't and vice versa. A cleaner solution would be to have Jersey
> be able to simply unmarshall into the bean with both media types so then the
> method would simply look like this:
>
> @POST
> @Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN})
> @Produces(MediaType.APPLICATION_JSON)
> public Response test1(FooBean fooBeanJsonDO) {
> ...
> }
>
> It sounds like from Martin's response I would need to create my own
> MessageBodyReader for this. I probably won't invest in this approach in the
> short term because of higher priorities but I think it would be a useful
> capability to see in Jersey.
>
> Thanks for all you feedback on this.
>
> -Noah
>
> On Fri, Mar 18, 2011 at 2:37 PM, Martin Matula <martin.matula_at_oracle.com>wrote:
>
>> Oh, I see what you mean. You are right.
>> Martin
>>
>>
>> On 18.3.2011 19:29, Tatu Saloranta wrote:
>>
>>> On Fri, Mar 18, 2011 at 10:47 AM, Martin Matula
>>> <martin.matula_at_oracle.com> wrote:
>>>
>>>> Noah said: "I suppose I could break this into two resources, one
>>>> consuming
>>>> JSON and one consuming FormData but I'd rather not - seems like it
>>>> defeats
>>>> the purpose."
>>>> So, I was assuming he knows about breaking it up into two methods and
>>>> was
>>>> wondering how to avoid it.
>>>>
>>> Right right, agreed, he was trying to do it this way. I was just
>>> pointing out that plain text String was not meant to be bound to
>>> object; rather it would be (I thought) alternative representation. And
>>> then the question of how to support alternatives is an interesting
>>> one, given that they are structurally different (not just different
>>> formats).
>>> But maybe difference here is that just having 2 methods does not
>>> create 2 separate resources (iff paths are the same), but just 2
>>> physical end points.
>>>
>>> Of course it is possible to get by with just a single method, taking a
>>> String or byte[], and call binders manually based on incoming type.
>>> Just couple more lines of code.
>>>
>>> -+ Tatu +-
>>>
>>
>