users@jersey.java.net

Re: [Jersey] 400 Bad Request (bug?)

From: Craig McClanahan <Craig.McClanahan_at_Sun.COM>
Date: Wed, 23 Sep 2009 11:26:55 -0700

Paul Sandoz wrote:
>
> On Sep 23, 2009, at 3:51 AM, Jordi Domingo wrote:
>
>> I know what happens with Java :)
>>
>> What I expected is Jersey check the value before doing the conversion
>> and then setting the value to null. Tomorrow i will think the best
>> approach to solve this.
>>
>
> The value will be null if and only if the parameter is not declared in
> the request.
>
> If the parameter is declared then the value of that parameter will be
> converted accordingly and errors may result if the value cannot be
> converted, and the error is reported back to the client.
>
> What null means is *absence* of the parameter and not absence of a
> parameter value.
>
> IIUC what you want is the ability to consider the following cases
> semantically equivalent:
>
> 1) absence of a parameter; and
>
> 2) absence of a parameter value;
>
>
> There are a number of approaches you can utilize:
>
> 1) Use a type of List<Long>, check if there is one or more entries,
> and use the first entry if not null.
> A null entry value in a list declares that the parameter was
> present but the value was absent.
>
> 2) Implement is to support a request filter that obtains the form
> parameters, removes all parameters that have
> empty values, then re-serializes the form contents.
>
> 3) Implement support for a StringReaderProvider [1] that supports the
> known concrete types that extend Number,
> such that an empty String value will return null. This could be
> generalized to support the type, say,
> ParamValue<T> where the T is deferred to by StringReaderWorkers.
> A value of ParamValue<T> that holds
> null declared the parameter was present but has no value.
>
> If people think that ParamValue<T> then i can implement support for that.
It would be nice to have the *option* to configure conversion of empty
strings to null values (via ParamValue<T>), but this should not be the
default behavior -- it will trigger no end of head scratching "how in
the world did I get a null pointer exception *there*" type questions
otherwise. And, as Jordi pointed out originally, an empty string is
semantically different from a null. (Oh, I guess not if you're using an
Oracle database, but that's a different story :-).

If the client doesn't want to send a value for a field, it should not
send that field at all.
>
> Hope this helps,
> Paul.
>
> [1]
> https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/spi/StringReaderProvider.html
> [2] https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/spi/StringReaderWorkers.html

Craig