Hi Paul,
For such a bean,
public class AccountBean {
@FormParam("acc.type")
private Integer type;
}
I believe that Jersey should never return an error code 400. Because it is
restricting the usage of Jersey. In my opinion:
1) In case sending a post value like this "acc.type=", it should inject
null to Integer
2) In case sending a post value like this "acc.type=a1b2", it should inject
null to Integer
I think that It might call constructor of Integer with an empty string. And
then if it raises an exception, it should simply inject null value. But in
our case it is returning with 400. This is restricting our validation.
In Jersey Java Doc this part of FormParam is not very clear.
And what If I want to use a custom validation logic such as JSR-303 in this
fields, what is your proposal?
Thanks
Paul Sandoz wrote:
>
>
> On Dec 16, 2009, at 8:07 PM, Cemo Koc wrote:
>
>>
>>
>> Hi,
>>
>> I would like to use FormParam for my bean as it described in jersey
>> documents and mail list. But I have a little problem in usage of non-
>> string
>> fields. It returns (400) for such kind of fields if I use empty
>> string.
>>
>> My simple example like this
>>
>> public class AccountBean {
>>
>> @FormParam("acc.type")
>> private Integer type;
>>
>> }
>>
>>
>>
>> My simple question will be about default behaviour of these fields.
>> IMHO,
>> the request values which can not be injected into fields should not
>> return
>> 400.
>
> It can be considered that the client is in error because it has not
> supplied a correct value that can be converted to an Integer instance.
>
> I presume the client is encoding the form parameter as follows:
>
> "acc.type="
>
> ?
>
> If the client encoded the following it will work:
>
> "acc.type"
>
>
>> Simply null values or @DefaultValue should be injected into fields.
>>
>
> I do not think the rules for injection on fields should be different
> to rules for injection on to parameters.
>
> I am wondering if i should modify Jersey such that instead of adding
> an empty string value to the form map for the case of "acc.type=" a
> null value should be added, since null values are supported in
> HashMap. Then we would be consistent for "acc.type=" and "acc.type"
>
> Although, i am concerned this may break some existing applications if
> i do that.
>
> Thoughts?
>
> Paul.
>
>> Maybe another solution could be making all fields String but I am
>> not sure
>> that it is a good practice.
>>
>> Any thoughts about this?
>>
>> Thanks
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Formparam-for-Non-String-Fields-tp4177365p4177365.html
>> Sent from the Jersey mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://n2.nabble.com/Formparam-for-Non-String-Fields-tp4177365p4180110.html
Sent from the Jersey mailing list archive at Nabble.com.