On Sep 23, 2009, at 8:26 PM, Craig McClanahan wrote:
> 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
I agree.
> -- 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.
Agreed.
Paul.