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.
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
>