On Nov 14, 2008, at 8:42 PM, Tim Pesce wrote:
> I agree that for most cases where XML (or JSON) entities are
> expected, a 400 response makes sense. But I would also like to see
> an explicit way to handle the case where an empty entity is also
> expected. One of the first things I tried was this:
>
> // Entity present
> @CUSTOM
> @Consumes("application/xml")
> public Response test(SomeXMLType entity)
>
> // Entity absent
> @CUSTOM
> @Consumes("application/xml")
> public Response test()
>
> But Jersey considers these resource methods to be ambiguous.
>
Could you log an issue?
Thanks,
Paul.
> Thanks for the work-around. I had been using an InputStream and
> unmarshalling the entity directly in my resource method, but I like
> this approach better. :-)
>
> Tim
>
> On Nov 14, 2008, at 2:46 AM, Paul Sandoz wrote:
>
>> Hi Tim,
>>
>> You raise an interesting issue that i am not entirely sure how to
>> resolve. I think it requires some clarification to the
>> specification as well as some consistency from Jersey.
>>
>> Here is a work around (using Jersey specific stuff):
>>
>> @CUSTOM
>> @Consumes("application/xml")
>> public Response test(@HeaderParam("Content-Type") String ct,
>> @Context HttpRequestContext request)
>> {
>> if (ct == null) {
>> ....
>> } else {
>> Entity e = request.getEntity(Entity.class);
>> }
>> }
>>
>> I would expect for the majority of cases when using XML or JSON say
>> that you would want to the runtime to automatically return a 400
>> (Client Error) when there is no entity rather than propagating
>> null. There seems a requirement for the application to explicitly
>> match for the case when there is no request entity.
>>
>> Paul.
>>
>> On Nov 13, 2008, at 9:35 PM, Tim Pesce wrote:
>>
>>> I'm trying to implement something similar to the WebDAV PROPFIND
>>> method. Specifically I'd like to support the case where a request
>>> body is optional, and the absence of a body has implied semantics.
>>>
>>> If I use byte[] or InputStream or one of the other JAX-RS
>>> supported types, requests with an empty body result in an entity
>>> with characteristics I would expect (array w/ length 0,
>>> InputStream w/ no data). However, if my entity is a JAXB annotated
>>> type then requests with an empty body trigger error (400)
>>> responses prior to my resource method being invoked. After doing a
>>> bit of playing w/ an exception mapper, it seems that an
>>> UnmarshalException is being wrapped and bubbled up:
>>>
>>> javax.ws.rs.WebApplicationException:
>>> javax.xml.bind.UnmarshalException
>>> - with linked exception:
>>> [org.xml.sax.SAXParseException: Premature end of file.]
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .impl
>>> .provider
>>> .entity
>>> .AbstractRootElementProvider
>>> .readFrom(AbstractRootElementProvider.java:93)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .spi.container.ContainerRequest.getEntity(ContainerRequest.java:353)
>>>
>>> I'm not sure if this is my own error, a general limitation, or
>>> perhaps a bug. Here's the entity and resource method I'm using for
>>> a simple reproduction case:
>>>
>>> @XmlRootElement(name = "entity")
>>> public class Entity
>>> {
>>> }
>>>
>>> @CUSTOM
>>> @Consumes("application/xml")
>>> public Response test(Entity entity)
>>> {
>>> [...]
>>> }
>>>
>>> I would expect Jersey to be passing a null to my resource method
>>> in these cases, but I'm not sure if my expectations are correct.
>>> Are there other approaches for handling this scenario? I've tried
>>> implementing a resource method specifically for the empty case,
>>> but I haven't found anything that works.
>>>
>>> Tim
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>